Re: Securing bind..
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: george@karaolides.com Nicosia CY 2057, |
| web: www.karaolides.com Republic of Cyprus |
Reply to: