On Mon, 2006-01-02 at 12:04, Maciej Żenczykowski wrote: > >> 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos