axfrdns requires tcpserver from ucspi-tcp #3
Comments
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. |
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. |
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. |
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. :) |
Hello Jason, -> https://fedorahosted.org/setup/ticket/3 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
|
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. |
after endlessly screwing around, i looked at the sourcecode, and axfrdns seems hopelessly broken in several ways:
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 Use the following xinetd config: 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. :) to summarize:
will that do? if you need more info or help let me know. :) |
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! :) |
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. :) |
Hi, Did you have chance to look at these updates? |
nope sorry..its a bit of a choas this week. its on my list, dont worry :) -----Oorspronkelijk bericht-----
|
Ah okay, no problem. Thank you for an update. |
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. |
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" 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. Thank you. :) |
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. :) Thank you. |
ah thats probably the case :) thx -----Oorspronkelijk bericht-----
|
New release is out now -> http://pjp.dgplug.org/ndjbdns/ Thank you. |
The axfrdns service is broken in its current form. Axfrdns is made to be dispatched under tcpserver from djb's ucspi-tcp tools.
The text was updated successfully, but these errors were encountered: