One Domain; Multiple IPs.

[Brad Knowles]

At 7:23 PM -0400 7/16/01, Kevin Darcy wrote:

>                      Zone data gets out-of-synch all the time in the
>  normal course of replication, and the only thing that cares about
>  serial numbers, AFAIK, are slaves and stubs. AXFR/IXFR is optional,
>  so if you have an alternative replication method to synch your data
>  between the master(s) and/or the slaves, this is a moot point.

	Dependance on mechanisms outside of AXFR/IXFR to synchronize 
masters and slaves is just about the worst possible idea I have ever 
heard of.  IMO, this is certainly one of the worst mis-features of 
djbdns.

>                                                                 As
>  for stubs, they only really care specially about NS records, which
>  aren't typically part of this same-question-different-answer
>  phenomenon, since the RTT-based adaptive algorithm is widely
>  deployed and usually sufficient.

	Once you start casually handing out different answers without 
updating the SOA serial number, handing out different NS records is 
surely soon to follow.  Once you have that little concern for the 
information in the DNS, you might as well start changing everything 
all the time, and without ever changing the serial numbers.

	And sadly, the RTT-based algorithm is *NOT* nearly as widely 
deployed as you seem to think it is.  It seems every moron and his 
dog thinks that he can write a replacement for the resolver routines 
or the nameserver programs, and do a better job than BIND.  Well, in 
generaly they botch up the job in a whole host of ways, because they 
don't understand the intricacies of how the DNS works.


	Not everything out there is a nice, new, shiny, BIND server.  You 
can't casually apply the rules to the world that you may have learned 
in this sheltered environment.

>  Not to mention, a lot of these schemes arrange to always give the *same*
>  answer to a given client. In that case, I can't see any possibility of
>  problems. It's really no different in practical terms than BIND 9's
>  "view"s or an old-fashioned "run split DNS with multiple nameserver
>  instances" setup.

	The problem is that with a "views" mechanism, or split DNS with 
multiple nameservers, you presumably have fairly complete control 
over everything that you use internally, and you can ensure that 
relatively minimal damage is done as a result of handing out 
different answers to the same queries but from different sources.

	That statement is fundamentally untrue when applied to the 
Internet as a whole, and therefore the things that you *may* be able 
to safely apply on a local level are almost certainly going to be 
totally inappropriate on a global basis.

>  Really, instead of whining about violations, perhaps the Protocol Gods
>  should be trying to figure out a way to mark an answer as "customized"
>  for that particular client,

	Instead of you bitching about things like this and what other 
people should do to solve the problems, why don't *you* start working 
on ways to "fix" the DNS protocol and the programs that serve it?

	Maybe once you get started on this process, you will discover 
that it's not nearly so easy as you think it is....

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

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'