One Domain; Multiple IPs.

[Brad Knowles]

At 8:22 PM -0400 7/17/01, Kevin Darcy wrote:

>                      Why stifle an emerging technology just because
>  of unfounded fear, uncertainty and dread?

	Because it's an inherently bad idea, and mis-uses and abuses the 
DNS in the wrong ways to solve problems that can be much better 
solved with other techniques?

>                                             I'm sure there were
>  naysayers and/or fearmongers about DNS when it first started being
>  implemented.  See, for example, RFC 1401 (apparently DISA still had
>  to be convinced of the value of migrating from HOSTS.TXT to DNS as
>  late as 1992!)

	DISA's problem with DNS was that they didn't have anyone with a 
clue as to how to implement it.  This is why I did it for DISA, as 
part of the "SMTP Tiger Team" work that I was drafted into.

	It wasn't until a few years later that I managed to force them to 
transfer me to the branch where the Internet mail gateways for the 
Agency were maintained, and which also maintained the DNS for all of 
DISA.mil, at which point in time I naturally became the DISA.mil 
Technical POC.

	Now, wanna talk to me about how the original domain for the DOD 
CERT was set up in one week, going from idea, to hand-carrying the 
paperwork through all the necessary channels, and then through 
multiple iterations of telling them what they needed to have on their 
servers and then doing remote debugging with just dig (because I 
wasn't allowed on the server), and at a time when there was just the 
one NIC and there was only one root zone update per week?

	Or how I finally managed to convince the guys setting up the 
classified SIPRnet that they really did need to use real network 
numbers assigned by the NIC, even if they weren't going to be 
connected to the Internet?  Or how I finally convinced them to use 
the DNS as well, instead of depending on the HOSTS.TXT files that 
they were *still* planning on using in 1995?


	Trust me, the problems at DISA were not technical in nature.  I 
have serious technical issues with load-balancing nameservers.

>  If it serves it poorly, then that's the fault of the protocol, not
>  the implementors or users, and it should be extended/enhanced.

	Or it's the fault of the abusers, and the abuse should be 
stopped, so that those problems can be solved the *right* way.

>  Huh? "Complete knowledge"? Complete knowledge of *what*? My whole point
>  is that a client *doesn't* typically need to know that the answers they
>  are getting for a particular query are different than the answers some
>  other client is getting for the same query.

	The idea behind giving different clients different answers based 
on where they are located in the network topology relative to the 
servers providing the answers is predicated on the servers having 
fairly complete knowledge of what target systems are located where 
relative to the clients, and which target servers have less load on 
them so that they are more likely to be able to respond quicker.

	Both of these assumptions are invalid, because the network 
topological location of the server asking the question via the DNS of 
your server may have little or nothing to do with the network 
topological location of the *client* who originally asked the 
question.

	Moreover, it is difficult in the extreme to have sufficient 
global knowledge of which servers have more or less load and/or are 
performing better than others, and to use this knowledge 
intelligently to modify the answers you provide.  If nothing else, by 
the time the client gets the answer, the situation may very well have 
changed.


	All of this becomes a non-problem if you hand out the same answer 
to everyone, and use routing protocols to automatically find the 
closest server farm that can handle the actual data request (as 
opposed to the DNS query that tells the client the address of the 
server to handle the request), and then use localized load-balancing 
switches to automatically hand that request off to the least-loaded 
server *at that very moment*.

	There is essentially no time lag between the load-balancing 
decision being made, and that information being made use of, because 
you're making the load-balancing decision later in the process, as 
opposed to hacking a way to do it in the DNS.

>  The only assumptions I'm making are that the client is robust enough to
>  handle volatility and/or inconsistencies (both of which were anticipated
>  in the earliest days of DNS), and that it doesn't care about serial
>  numbers (which it doesn't have any business caring about unless it's an
>  AXFR/IXFR or Dynamic Update client). These are very conservative
>  assumptions.

	Regardless of what you may consider "conservative assumptions", 
the truth is that most Microsoft clients do some incredibly stupid 
things, and it is not at all unlikely that they will *not* be able to 
handle volatility or inconsistencies, even if the DNS protocol itself 
is supposed to be able to do so.

	If you honestly believe in the "be liberal in what you accept and 
conservative in what you generate" theory, then you fundamentally 
*CANNOT* support load-balancing nameservers.  It's that simple.

>  So, I have to prove a negative, is that it? I have to prove that
>  nothing *possibly* could go wrong as a result of answer-differentiation?

	No, you don't.  The reason is that we know damn good and well 
that Microsoft will give us a perfect example of how clients can 
seriously screw up as a result of answer differentiation, above and 
beyond all of the other problems I've pointed out with regards to 
load-balancing nameservers.

	Therefore, the point is moot.

>            The truth of the matter is, load-balancers have been around
>  for years and nothing particularly bad has happened, except for some
>  superfluous traffic because of the low TTLs.

	Funny that the only software implementation I can find is an 
ancient Perl program that (so far as I can tell) is no longer even 
supported by the original authors.  I wonder why they stopped?

	If this was a really good idea, we'd have more software 
implementations of it.  Just because some companies have decided to 
do something incredibly stupid and give us proprietary hardware-based 
solutions along these lines doesn't necessarily mean that we should 
all jump off the bridge with them.

>  I agree that lower-level, e.g. L4 solutions are technologically preferable
>  to DNS-based load-balancing. They're also typically more expensive,
>  requiring a dedicated computer and/or network device.

	Hmm.  It seems to me that cisco GlobalDirector is a pretty 
expensive piece of hardware to suggest people to use.

	Alternatively, I don't think I'd want to bet an entire enterprise 
that would need some sort of load-balancing solution on an old Perl 
hack that was not particularly well supported when it was originally 
written, and has gone absolutely nowhere since then (at least, so far 
as I can tell).


	No, it still seems to me that distributing the servers and using 
router techniques to allow clients to naturally find the "closest" 
server farm (maybe you might want to put a dedicated cluster of 
machines at AOL's TerraPOP in Sterling, just to serve their customers 
alone?), and then allowing each cluster of machines to use relatively 
inexpensive L4 load-balancing solutions (they've got to be cheaper 
than cisco GlobalDirector) to deal with HA, dealing with queries 
quickly, etc... is a much better idea.

-- 
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,$_)}'