also sprach George Karaolides <email@example.com> [2002.01.02.1423 +0100]: > # 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? i find this horrible. BIND zonefiles at least allow for usage of tabs to organize your zone into tabular data. sure, it requires a little thought at first, but in the end, you have aligned columns that are easy to search and modify. with djbdns, you are left with /bin/ls unless you provide a new tool that sort of abstracts above that structure... > You don't have to worry about keeping A and PTR records in sync. how often do you worry about that in a productive environment? how often do you move your subnets around??? and aside, there are many tools that write BIND config files for you. i wrote one myself, which really just allows me to have 120 byte config files for a complete zone, and it's all in sync. i still maintain that BIND's zonefiles are much easier to read and understand than a directory with inode entries named in such a way so as to represent the most information in the least amount of space, and making sure that noone can understand what's going on by glancing at it. > 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 areet, 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. why does the DNS protocol even allow this? keeping them in sync is really what you should do, but there are cases, where they may need to be out of sync. for instance, domain.com and mail.domain.com for small domains usually get the same A record on my servers, if what i delegate to mydomain.com is a single IP address. that's not a CNAME, that's an A record. but what does the IP map to? *not* mail.domain.com. i find it very handy to have explicit control over the mappings. > 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. priorities or preferences. i find BIND does it's job. it might not be optimal, but it's free, and it works. djbdns might even be better, smaller, faster, more secure. but my nameservers are not going to be running a piece of software because of either of two reasons: (a) the author is braindead in many aspects; and (b) it's non-free. > 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. well, as opposed to postfix, for instance, you are right. wietse dared to put RBL support into postfix. djb simply writes another program and then tells you how to integrate that. sure, it's unix philosophy... nevertheless, between postfix and qmail, i'd say i'll install postfix from source in a fifth of the time as i'd need for qmail with all it's features. and i can't really see how that could change for BIND/djbdns... > 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. we'd like to package it, not require the end-user to download the -source package, which includes voodoo magic to compile djbdns without the user ever knowing what gcc is. the problem is that this is an aweful job for the maintainer, and that it requires some -dev libraries on the target system, as well as the entire gcc family, which might not be needed otherwise... let's take this discussion somewhere else. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck the only real advantage to punk music is that nobody can whistle it.
Description: PGP signature