This place isn't the place to get into a DNS discussion (the protocol has big flaws in it anyway), but I will comment one last time. >> we could decide that bind is screwed anyway and DNS servers and cache's >> are two fundamentally different animals and shouldn't be mixed anyway (ie. >> no DNS server should ever be a cache and vice versa) > > Except that decision doen't make a lot of sense. It does from a security standpoint - take a look at how many bugs there are/were in BIND - how many breakins have happened through BIND. And consider that having server and cache running as the same servers makes it a good deal harder to implement both correctly and to prevent cross-poisoning and other attacks - it's a matter of simplicity giving bug-freeness and security. >> The reason why CNAME's are used for reverse delegation is because >> administrators are lazy and BIND makes the proper non-CNAME using solution >> tiresome to implement. It's a breeze with tinydns/djbdns (once you get to >> know the program, but that's normal). > > If there is some advantage to delegating NS's for individual > addresses instead of using CNAME's I think you forgot to > mention it. CNAME's inherit the robustness of the referenced > domain. If you do it by delegation, you'll have to provide > multiple NS records for every address, and the admin of the > delegating zone must track any changes. The point of using > CNAMEs is for the delegating zone to not need to track anything > about the real names - if they did they could just supply the > correct PTR address in the first place. I don't see where your argument lies. Using CNAME's require specifying NS'es for the domain you CNAME too - using NS'es requires exactly the same amount of entries at the delegating server - indeed using CNAMEs requires more entries at the delegating server (1 line per NS for CNAME domain + 1 line for generating the CNAMEs, versus, 1 line per NS for generating NS'es). As for what happens at the client domain nameserver (the one being delegated too) - this is indeed where CNAME's are easier - but that's due to BIND and not integral to the DNS protocol at all (in tinydns it's far easier to set up zones, etc. and indeed CNAME's cause all sorts of extra headaches since automatic reverse-IP delegation doesn't (and can't) work for them...). As for robustness - I see no difference either way - in both cases there's exactly one NS referring line per nameserver. And the second half of your paragraph (about tracking changes) makes no sense whatsoever - are you sure you've understood what I've written? There's no need to track any changes once it's set up -- all changes are made by wherever the stuff has been delegated to (unless you want to change the nameservers but that's EXACTLY the same with CNAMEs). Cheers, MaZe. PS. I won't be replying on-list to this thread anymore - it's not CentOS'ish enough.