DNS wizard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux