axfrdns requires tcpserver from ucspi-tcp

[elmerfud]

The axfrdns service is broken in its current form. Axfrdns is made to be dispatched under tcpserver from djb's ucspi-tcp tools.

[pjps]

Hello Jason,

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.

Thank you.

[elmerfud]

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

1.2.3.4:allow,AXFR="heaven.af.mil/3.2.1.in-addr.arpa"

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.

[pjps]

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. :)

[elmerfud]

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.

[pjps]

Hey Jason,

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??

Thank you. :)

[pjps]

Hello Jason,

    -> https://fedorahosted.org/setup/ticket/3
    -> http://0pointer.de/blog/projects/inetd.html

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
[Unit]
Description=Stream socket for axfrdns(8) zone transfer server

[Socket]
ListenStream=53
Accept=yes

[Install]
WantedBy=sockets.target

$ cat /etc/xinetd.d/axfrdns
# default: off
# description: The axfrdns(8) zone transfer server is part of the ndjbdns \
#              project.
service axfrdns
{
        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
}

[pjps]

Hello Jason,

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.

Thank you.

[psy0rz]

after endlessly screwing around, i looked at the sourcecode, and axfrdns seems hopelessly broken in several ways:

1. If you run a service from a internetserver like xinetd, you should NOT let it deamonize by itself. So you should remove the -D.
2. 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.
3. 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)
4. 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.

[psy0rz]

I created an ugly workaround:

Create a script: like /usr/local/sbin/axfrdns.run
#!/bin/sh
exec /usr/local/sbin/axfrdns 2>/dev/null

Use the following xinetd config:
service axfrdns
{
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. :)

[pjps]

Hello Edwin,

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! :)

[psy0rz]

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. :)

to summarize:

• 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       1.2.3.4
...............(etc).........

will that do? if you need more info or help let me know. :)

[pjps]

Hello Edwin,

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.

Thank you! :)

[pjps]

Hello Edwin, Jason

    -> https://github.com/pjps/ndjbdns/commits/master

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.

Thank you. :)

[pjps]

Hi,

Did you have chance to look at these updates?

[psy0rz]

nope sorry..its a bit of a choas this week. its on my list, dont worry :)

-----Oorspronkelijk bericht-----
Van: P J P notifications@github.com
Verzonden: wo 11-12-2013 08:44
Onderwerp: Re: [ndjbdns] axfrdns requires tcpserver from ucspi-tcp (#3)
Aan: pjps/ndjbdns ndjbdns@noreply.github.com;
CC: Edwin Eefting edwin@datux.nl;

Hi,

Did you have chance to look at these updates?

Reply to this email directly or view it on GitHub.

[pjps]

Ah okay, no problem. Thank you for an update.

[pjps]

Hello Edwin,

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.

Thank you.

[elmerfud]

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.

1.1.1.1:allow,AXFR="mydomain.com/alsomydomain.com"
2.2.2.2:allow,AXFR="othersdomain.com/anotherdomain.com"

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.

[pjps]

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.

Thank you. :)

[psy0rz]

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?

[pjps]

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. :)

Thank you.

[psy0rz]

ah thats probably the case :)

thx

-----Oorspronkelijk bericht-----
Van: P J P notifications@github.com
Verzonden: ma 16-12-2013 13:53
Onderwerp: Re: [ndjbdns] axfrdns requires tcpserver from ucspi-tcp (#3)
Aan: pjps/ndjbdns ndjbdns@noreply.github.com;
CC: Edwin Eefting edwin@datux.nl;

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. :)

Thank you.

—
Reply to this email directly or view it on GitHub.

[pjps]

New release is out now -> http://pjp.dgplug.org/ndjbdns/

Thank you.