FQDNs in masters-list (was: Help: Secondary for...)

[Brad Knowles]

At 10:58 AM +0100 3/5/01, Andreas S. Oesterhelt wrote:

>  Maybe it's just my ignorance of the technical details, but I fail to
>  see how
>   a) Allowing masters to be specified by name and
>   b) having the slave do, if necessary, lookups for the master's
>      address before zone transfers,
>  could possibly require a change in the protocol or standard.

	There are people on this list far more qualified to answer this 
question than me, however I will try to give it a go.


	I haven't yet confirmed this by checking the RFCs, but I think 
that the way secondaries are handled is outside of the scope of the 
standard.  It's primarily an implementation detail of BIND, but if 
done wrong it could obviously cause very grave harm.

	I can imagine that many zones (in fact probably most of them) 
would be seriously broken by doing something like this.  First off, 
the secondary/ies wouldn't be able to start serving the zone until 
it's done the DNS queries to resolve the name of the primary/ies, and 
until the release of BINDv9 we didn't have a multi-threaded server 
that could serve some zones while it was in the process of loading 
others.

	Secondly, it is still quite easy for someone to poison the cache 
of a nameserver, and lie to it about what the IP address is for a 
particular server.  It's getting harder and harder to do this (as 
people install more and more up-to-date software), but it is still 
easy enough to do that virtually any zone this way could be hi-jacked 
with ease.  The only way to solve this problem would be to force 
everyone around the world to upgrade to BINDv9 immediately, and that 
would still be only a partial solution (I understand that cache 
pollution in BINDv9 is more difficult, but still possible).

	Thirdly, if people screwed up their zones by doing stupid stuff 
like having CNAMEs exist for nodes that also have other data (e.g., 
giving the zone itself a CNAME alias to another zone or node 
somewhere else), then since this would cause SERVFAIL errors, this 
would result in the zone being totally unserveable by the secondaries.


	I've heard some statistics quoted that around 25% of all zones 
registered with well-managed TLD nameservers (e.g., those where the 
registrar actually checks to confirm you really do have two separate 
nameservers for the zone you're registering, and they appear to be 
properly set up according to tools similar to "doc") are actually 
lame delegations, and in excess of 50% of all zones registered at 
less well-managed TLD nameservers are lame delegations.

	If people can't get something correct that is this fundamentally 
basic to the nature of DNS, how can you expect them to get something 
more complex right at all?


	No, I submit that we should be doing things that force them to 
fix the more basic things (or simply prevent them from being able to 
get them wrong in the first place), and once that is done, we can 
consider what future extensions we may be able to make.

--
======================================================================
Brad Knowles, <brad.knowles at skynet.be>