You can clone with
HTTPS or Subversion.
The axfrdns service is broken in its current form. Axfrdns is made to be dispatched under tcpserver from djb's ucspi-tcp tools.
Couldn't it be used with Xinetd or Systemd servers? It currently lacks configurations for either of them, but that'll be better solution than packaging/using tcpserver, IMO.
I don't believe it would be possible to use those. tcpserver is similar in many ways to xinetd, but it has the djb twist to it.
For axfrdns, tcpserver references a complied tcprules file that contains the IP's and domain names that allowed to request AXFR. Like this
tcpserver sets the environment variables AXFR, TCPREMOTEIP, & TCPREMOTEPORT and then calls axfrdns to do the work. I'm not sure how, or if there is a way to make xinetd work in a similar fashion.
The ideal scenario would be for axfrdns to run daemonized like tinydns, but that would be a fairly large change as well.
I was able to find a packaged version of ucspi-tcp here http://www6.atomicorp.com/channels/source/ucspi-tcp/ but there are conflicts installing with tcprules.
I see. True, it'll be a big change to make axfrdns run as daemon. I'll try to figure out how to fix it best. Thanks so much for the ucspi-tcp package link.
Thank you. :)
Let me know if there's anything I can do to assist, or to test. I'm not very strong at programming but I can tweak spec files, and do some bash scripting.
Sure, that'll be great. May be we could divide the task? I'll investigate if xinetd(8) & init(5) could be used to listen on behalf of axfrdns(8) server, while you try to find out how systemd(1) could be used for the same. Based on our findings we'll see how to proceed forward. For the environment variables you mentioned above, I'll add those to the axfrdns.conf file and make required changes to the server to read them from the file.
Also, let's share our findings over email? That'll be convenient for the followup discussion too, no??
The following configuration should help to run axfrdns(8) server using xinetd(8) or Systemd services. I'm currently testing these configurations, it'll be helpful if you could also take a look at it. Environment variables: AXFR, TCPREMOTEIP, etc. required by axfrdns(8) server can be set in the configuration file -> /etc/ndjbdns/axfrdns.conf
$ cat axfrdns.sock
Description=Stream socket for axfrdns(8) zone transfer server
$ cat /etc/xinetd.d/axfrdns
# default: off
# description: The axfrdns(8) zone transfer server is part of the ndjbdns \
port = 53
protocol = tcp
socket_type = stream
bind = 127.0.0.1
wait = yes
user = daemon
group = daemon
server = /usr/sbin/axfrdns
server_args = -D
disable = yes
flags = IPv4
New Systemd(1) & Xinetd(8) configurations have been pushed to the repository now -> 145d89d. It still has few glitches, I hope to fix those soon. I'd appreciate if you could also take a look at it.
after endlessly screwing around, i looked at the sourcecode, and axfrdns seems hopelessly broken in several ways:
If you run a service from a internetserver like xinetd, you should NOT let it deamonize by itself. So you should remove the -D.
the service works by accepting data from stdin and sending it to std out. however: it seems that xinetd also forwards error-output to the client. Therefore all the 'warnx' messages are sent to the client, therefore corrupting the axfr protocol. (e.g. not workable) ucspi handles this much better: it actually logs the error output, and only forwards real out.
after looking a bit closer: this whole module shouldnt have a -D option at all! it seems to fork itself, but its not able to do actual network listening and handling. (e.g. it needs to be started from xinetd or tcpserver)
the -D option (which shouldnt be there in the first place) seems to redirect the output to a logfile, therefore completely breaking it. (remember: the OUTPUT contains the actual data that should go to a client instead of a logfile)
i dont know what happend here, but it seemed someone just added forking and deamonizing options without knowing what they are doing.
thanks for the effort of porting this package guys..but geesh. :)
I think DJB will be pretty pissed off that the kids ruined his perfectly constructed garden.
I created an ugly workaround:
Create a script: like /usr/local/sbin/axfrdns.run
exec /usr/local/sbin/axfrdns 2>/dev/null
Use the following xinetd config:
port = 53
protocol = tcp
socket_type = stream
bind = 0.0.0.0
only_from = 0.0.0.0
wait = no
user = root
server = /usr/local/sbin/axfrdns.run
#server_args = ""
disable = no
flags = IPv4
type = UNLISTED
Now it does work, but this is obviously an ugly hack. :)
Thanks so much for the comprehensive review and an updated xinetd(8) configuration. I appreciate it.
I agree, axfrdns(8) is broken in lot of ways. Partly because I've never had to play with DNS zone transfer myself, so don't know how to test it.
The -D option was added initially for consistent interface across all servers. It's meant to be used only if required. I used it in xinetd(8) configuration only as experimentation.
I'll fix the server by removing the -D option and redirection of STDOUT to a log file. It'll be nice if you could share a sample axfrdns(8) test, which I could try locally to ensure that it's working good.
Thank you! :)
ah it indeed seemed it was something like that. well usually there is nothing wrong with constancy. :)
if you could do those changes it would be awesome. :)
remove the systemd and init.d scripts for axfrdns, since it only works from a internetserver like xinetd or systemd.
remove the daemonisation, like you said.
if you telnet to port 53 you should see no headers or other stuff like errors. (its a binary protocol) you can get that done by only redirecting stderr to the log, and not stdout.
after that, you can use the dig command of bind tools to test if it works. make sure you have an existing tinydns zone in data.cdb. after that its something like this:
psy@psysamsungtop:~$ dig somedomain.com AXFR @yourserver
; <<>> DiG 9.8.1-P1 <<>> somedomain.com axfr @yourserver
;; global options: +cmd
somedomain.com. 2560 IN SOA a.ns.somedomain.com. hostmaster.somedomain.com. 1386259999 16384 2048 1048576 2560
somedomain.com. 3600 IN NS a.ns.somedomain.com.
www.somedomain.com. 60 IN A 22.214.171.124
will that do? if you need more info or help let me know. :)
Thank you so much for helping with this test; I really appreciate it.
First note about removing init.d script & updating Systemd(1) unit files for axfrdns(8) is already done -> 1ff1547. I'll fix the rest as discussed above and will ping you once it is done.
Hello Edwin, Jason
I have fixed the axfrdns(8) server and its configuration files. The server seems to be working good with both Xinetd(8) & Systemd(1) services.
Could you please review these latest changes? In case if you find anything amiss, I'll fix it before making a new release.
Did you have chance to look at these updates?
Ah okay, no problem. Thank you for an update.
Just to let you know, a new release 1.05.9 of 'ndjbdns' is ready. Once you confirm about axfrdns(8) configurations, I'll build a new package. Hope you get chance to review axfrdns(8) changes soon.
Sorry for my delay in getting back to this. I just tested this and it does work responding to the AXFR request, but see how to restrict the AXFR requests so only specific ip's can retrieve specific zones.
With djb's tcpserver for axfrdns you'd specify a series of configurations to restrict which ip's are allowed to transfer which zones, like so.
Running as it is now, you can specify the domains allowed for transfer and an IP address, but it doesn't look like there's a way to specify multiple such entries.
Hello Jason, thanks so much for the review.
Well, Xinetd(8) & Systemd(1) could restrict incoming connections based on the 'only_from' and combination of ListenStream, BindToDevice configuration parameters respectively.
Support for restricting AXFR requests from specific IP's to specific domains/zones could be added in future.
i can confim that this bug is fixed now. thanks :)
what happend with the versions btw: one of my boxes already had 1.05.9, and i had to use killall -SIGUSR1 tinydns to update it.
now it seems we reverted back to 1.05.8? or did i miss something?
Hello Edwin, thank you so much for the confirmation.
Version 1.05.9 is not released yet; But the changes are pushed to the git repository all the same. Did you by any chance, cloned repo, built and installed N-DJBDNS from source?
In that case you'd see version as 1.05.8 and yet still have all the latest updates running. :)
New release is out now -> http://pjp.dgplug.org/ndjbdns/