Hi, On Tue, 1 Jan 2002, Craig Sanders wrote:
> someday soon, someone's going to take the good ideas from djbdns, > combine it with the good stuff from bind (including backwards > compatibility with bind config & zonefile formats), add a few useful new > ideas (e.g. an "RXFR" protocol that embedded the rsync protocol > directly) to produce a fast, secure DNS daemon, and release it with a > GPL-compatible license. this will blow both bind & djbdns out of the > water. Roll on the day! When such a godsend appears, I'll grab it with both hands, provided of course that besides reverse compatibility with BIND config. files, it also gives you a new, simpler config. scheme. In the meantime, I submit that djbdns is OK unless you really, really want to stick to the BIND zonefile format, though I seem to recall hearing it can be made to read BIND zone files. IMHO once you're used to it, the djbdns data file format is actually quite nice. I've worked on both BIND and djbdns and I find the latter easier to use. For example, the following ten entries would require four entries in named.conf and four zone files: # Nameserver for my network addesses... .my-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for addresses in my other network... .my-other-network-in-reverse-order.in-addr.arpa:my-nameserver-ip-address:TTL # ... and for names in my domain... .my-domain:my-nameserver-ip-address:TTL # ... and for names in my other domain... .my-other-domain:my-nameserver-ip-address:TTL # Now to get on with mapping names to addresses, and vice versa =i-want-this-to-map-both-reverse-and-forward.my-domain:ipaddress1:TTL +i-only-want-this-to-map-forward-cos-its-an-alias.my-domain:ipaddess1:TTL =another-bothways-map.my-domain:ipaddress2:TTL +and-this-too-has-an-alias.my-domain:ipaddress2:TTL =a-bothways-map.my-other-domain:ipaddress3:TTL +an-alias.my-other-domain:ipaddress3:TTL Surely that's not all bad? You don't have to worry about keeping A and PTR records in sync. In fact, you don't have to worry about subdomains of in-addr.arpa at all, beyond making sure that your clients are querying the right servers (which you'd do anyway), that any delegations to your server are done correctly by your parent (ditto) and that your data includes a nameserver entry for the appropriate in-addr.arpa subdomains (again ditto). I know there are management tools that automate synchronisation of forward and reverse mappings in BIND zone files, but why should the reverse-mapping information be in a file separate from the forward information? Once the three conditions above are met, why should we need to administer the forward and reverse mappings separately? BTW these are not rhetorical questions; I'd love to hear input on this. Myself, I haven't thought about any subdomain of in-addr.arpa since installing djbdns, besides the three points mentioned above. In the end, it's all a question of priorities. If compatibility with existing config. and zone files is an issue, then djbdns may well be a non-starter, my recall that there's a way to get it to read BIND zone files notwithstanding. If managing a DNS name space painlessly, securely and reliably is, then it could well be. It was for me. For all the arguments against djb's attitude re. development and licensing, it must be acknowledged that his keeping tight control of the software has prevented it from suffering from feature bloat. And since it's open-source and you can distribute patches to it, there's no shortage of patches to get it to do what you want. Heppy new year, | George Karaolides 8, Costakis Pantelides St., | | tel: +357 99 68 08 86 Strovolos, | | email: [EMAIL PROTECTED] Nicosia CY 2057, | | web: www.karaolides.com Republic of Cyprus |
