Feature #403
closed
tinydns/dnscache drop in replacement for dnsmasq in pfSense
0%
Description
I'm taking one more time on an older ticket back from last year:
http://redmine.pfsense.org/issues/show/129#note-1
Scott Ullrich wrote:
Thanks but we cannot migrate to the new version of DNSMASQ until someone writes a replacement for the isc log scanning option that they removed in haste.
I'm sort of uncomfortable with the current situation, that is dnsmasq stuck on an old unsupported version. Because djbs tinydns is already the core of pfDNS i tried to come up with a setup which allows to replace dnsmasq in pfSense completely with tinydns and dnsmasq. I think it should work if its implemented like this:
Cache only operation, no hosted zone:- One dnscache instance listening on the LAN-IP (or an ip alias on the lan interface).
- /etc/resolv.conf points to the ip address of dnscache.
- One tinydns instance is started listening on an ip alias on the same interface where dnscache is bound to.
- Configure one (or more) DNS zone (example.com. / x.y.z.in-addr.arpa. pairs) with NS, A and SOA records.
- Provide a simple interface allowing the user to enter host and alias records. In tinydns-terms a host record consists of two DNS records: A and corresponding PTR while an alias is just an additional A record.
- Run an isc dhcp server on the same interface where dnscache is bound to.
- Derive domain option from tinydns config, NS record from dnscache config.
- Run a script watching /var/log/dhcp3/dhcpd.leases for changes. Whenever the file was altered the script parses the dhcp leases file and generates tinydns host entries for each hostname-ip pair found. The ttl parameter is derived from the lease time.
- Signal the pfsense configuration system to regenerate the tinydns database and reload the dns server process.
- For clients with fixed IP-MAC mapping the host record should not get overwritten by the leases script.
- It might be interesting to start the leases watcher script using daemon-tools, just like tinydns and dnscache.
- There are PHP interfaces for FAM and libevent. Both of them use kqueue to watch a path or file descriptor for changes. This could be usefull to avoid a poll-loop which stats the leases file on a regular basis.
- One could run several instances of tinydns and dnscache to serve different isolated LAN zones (on different interfaces). That's currently not possible.
I've attached some early proof-of-concept code for the dhcp-parsing and leasfile watching stuff. I'm willing to contribute to the lowlevel stuff aka lease-file parsing, daemontools and stuff like that if someone goes for the webinterface part.
Files
Updated by znerol znerol about 15 years ago
Reply to myself... I see that allmost anything is already done in the tinydns package. Registration of DHCP leases does not seem to work tough. I may try to get that working.
Updated by Scott Ullrich about 15 years ago
This sounds good. Let me know if you get the registration of DHCP leases working.
We also need to add the other features of dnsmassq such as forwarding of subdomain lookups to another server, etc.
Updated by znerol znerol about 15 years ago
I think its necessary to change the way the configuration is handled beforehand. In my opinion its not acceptable that everytime the dhcpd lease-file changes, the configuration slice has to be remounted rw in order to update the data.cdb file. Additionally daemontools do not work when the service-directory is read-only (embedded). I see two solutions for that problem:
- Recreate
/services/{tinydns,dnscache,axfrdns}under/var/run(e.g./var/run/services/tinydns) everytime pfsense is started. - Start tinydns manually from a php-script (like dnsmasq and all the other services).
At the moment I'd prefer the first solution because the change seems reasonable easy and save. In both cases the dns database needs to reside in the ramdisk. Do you think this is a problem?
We also need to add the other features of dnsmassq such as forwarding of subdomain lookups to another server, etc.
I guess you mean the delegation of zones to other nameservers. This should be perfectly possible wth the &-rows in the data file. These look like glue-records to me. Do you think this should be handled seperately in the gui?
Updated by znerol znerol about 15 years ago
Ok, here is a first bunch of patches. The changes contain:
- Move /etc/{tinydns,axfrdns,dnscache} to /var/etc and /services to /var/run/services in order to get svscan running on the embedded platform (service directory needs to be writable).
- Allow tinydns_create_zone_files to operate without rw-remounting the configuration.
- Seperate svscan service from tinydns service.
- Run a script watching /var/dhcpd/var/db/dhcpd.leases and trigger tinydns_create_zone_files whenever the file changes.
- Some minor fixes for the service management.
There are still some more open issues:
- The service management (svscan/supervise stuff) is sometimes started several times. I suggest to extract daemontools from tinydns and pack it up seperately including a nice php api (or get rid completely of the svscan architecture).
- There is a bug in tinydns.inc:tinydns_create_zone_file causing inactive leases to end up in the tinydns data file, I'll open up another ticket for that.
I'll clone the packages repository on gitorius if you want me to stop submitting patches on the tracker. Should I?
Updated by znerol znerol about 15 years ago
Could someone please review/apply those patches in order that I can continue the work on the new basis? Thanks.
Updated by Ermal Luçi about 15 years ago
- Status changed from New to Feedback
I committed part of these patches with some differences.
Check them out and do your comments.
Thanks.
Updated by znerol znerol about 15 years ago
- File 0001-tinydns-replace-redundant-g-varetc_path-etc-with.patch 0001-tinydns-replace-redundant-g-varetc_path-etc-with.patch added
Patch attached replacing $g['varetc_path']}/etc with $g['varetc_path']}
Updated by znerol znerol about 15 years ago
Ermal Luçi wrote:
I committed part of these patches with some differences.
Check them out and do your comments.
Thanks.
Thanks for applying the patches. Interface selection for dnscache is sure enough a good thing. I had plans to do that exactly like in DHCP Server administration, i.e. one tab per interface and separate this page from the DNS Server page. I'd also put the checkboxes related to the registration of DHCP leases on those tabs as well as a table where additional dns servers may be specified for whole (sub-)domains. That will duplicate the functionality of the bottommost table in services_dnsmasq.php.
I'm a bit surprised that you removed the dhcp-leases-update script as well as that you reintroduced conf_mount_rw() in tinydns_create_zone_file. I'm pretty sure that the remount-stuff is not necessary anymore because i removed the need for write access to ro-partitions completely by migrating /service to /var/run/service. Security reasons?
Updated by znerol znerol about 15 years ago
Ok, I see that it is not possible to have more than one menu-entry per package. Also it seems that the xml-based config interface does not support a variable number of tabs. Some core-member cares to comment on that and on my previous post? Don't hurry, I'll put my plans for tinydns on pfsense on ice if it is not a priority for 2.0.
Updated by Chris Buechler over 10 years ago
- Status changed from Feedback to Resolved