One Domain; Multiple IPs.

[Brad Knowles]

At 12:31 AM -0400 7/17/01, Kevin Darcy wrote:

>  Don't get me wrong; I use AXFR exclusively for zone data replication. But
>  I happen to agree with DJB that it's a fairly crude replication mechanism, as
>  replication mechanisms go.

	Fine.  Then join the necessary IETF groups and work with them to 
help specify a method within the protocol to replace AXFR/IXFR.

>  Ah, the slippery-slope argument. But in this case it's a _non_sequitur_. The
>  reason for giving out different *address*records* for application-level
>  servers like webservers, etc. is to dynamically load-balance 
>accesses to those
>  servers, and provide quick recovery in the event of a node failure.

	No, it does make sense.

	First off, you are obviously not using well-used and relatively 
trust-worthy code like BIND for this application, you're instead 
using some bizarre custom hacked-up code to do it.  This means that 
the code is inherently less trustworthy than BIND, and there's 
${DEITY}-only-knows how many different ways that the code could 
easily muck things up and hand out wrong answers for the wrong types 
of records.

	Secondly, you're using the DNS for something it was not designed 
to do, and in a role it serves particularly poorly.  Any attempt to 
go down this road is a mistake, and once you start going down this 
road, you're only going to start piling more mistakes on top of 
previous ones.

>  And what would that break? AXFR/IXFR and certain forms of Dynamic Update
>  synchronization. All of which are *optional* parts of the protocol. 
>Nothing in
>  the core protocol cares about serial numbers.

	I don't know what planet you come from, but AXFR is *NOT* an 
optional part of the protocol, nor would I consider IXFR or dynamic 
updates to be optional.

>                                       I don't think there's much of a danger
>  that they'll start dynamically-load-balancing NS records, since the
>  dynamic-load-balancing is usually driven, I believe, by some sort of
>  backchannel continually updating the load-balancer with performance-metric
>  data, and if they know enough to monitor nameserver performance in any
>  meaningful way, they probably know enough to realize that
>  dynamically-load-balancing NS records is a really stupid idea.

	It's a pretty stupid idea to mis-use and abuse the DNS to try to 
implement load-balancing in the first place, so once you've made that 
mistake, I don't see how it's any less likely that they're not going 
to do other kinds of stupidity.

>  But you haven't identified any "damage" or even potential damage here. One
>  only needs to exercise "control" to be "safe" if there's actually a risk
>  present.

	That assumes complete knowledge from the client-side, which you 
inherently do not have on a public Internet, and which you can 
presumably have on an internal intranet.  Therefore, you base your 
argument on an inherently false assumption.

	Fundamentally, you cannot make any assumptions about what the 
client will or will not do with the information you give it, 
especially since there are so very many broken nameserver 
implementations out there.

>             My suggestion above was just an example of something the Protocol
>  Gods could do to assuage their own (IMO ill-founded) fears of 
>interoperability
>  problems. I'm not about to put together a detailed proposal for something
>  I think is totally unnecessary. They can take or leave the suggestion as they
>  see fit.

	This is a case where the so-called "Protocol Gods" are right, and 
do not need to do anything to defend their statements.  If you want 
to make contrary claims, you need to come up with a provably safe 
mechanism for doing so.  Bitching about "the Protocol Gods" does not 
solve the problem.

>  As for my _other_ suggestion, which you deleted, my biggest gripe with the
>  load balancers is the tiny TTL values they use to achieve the volatility that
>  they require, and the ripple effect that these tiny TTLs have on the Internet
>  DNS infrastructure.

	Right.  As I said in another message, they are abusing the 
client-side caching nameservers because of a problem that they 
themselves *caused*, as a side-effect to their so-called "solution" 
to a different problem.

	In reality, they should not be making any attempt whatsoever to 
"solve" this problem by using the DNS, they should instead be solving 
this problem at a lower level in the protocol and providing the same 
answers to everyone regarding the IP address(es) of the machines 
which will provide whatever the service 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,$_)}'