One Domain; Multiple IPs.

[Kevin Darcy]

Brad Knowles wrote:

> 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.

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. I think its lifetime is limited. I'm not sure what
will fill that void, but "we can't think of anything better" is a poor excuse
for using something that's outdated. IXFR is a little better, but still rather
crude. There should be *real* compression, and a way to send
implementation-specific-yet-structured "metadata" in the transfer. It would be
nice to have an encrypted-transfer option as well, for situations in which the
most cost-effective way to replicate zone data is over a relatively-untrusted
link. Given some time, I'm sure I could come up with other missing features.

(Oh, and just for the record, djbdns does provide an AXFR client and server
for interoperability with other DNS implementations, e.g. BIND. You probably
_could_ build a djbdns infrastructure which used only AXFR for replication,
but I think you'd probably have to use virtual interfaces or strange port
numbers for the replication part, since his AXFR server probably can't
co-exist on the same address/port combination as the regular DNS server. It
would doubtless be quite painful to set up and maintain.).

> >                                                                 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.

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. But since
DNS traffic is a small fraction of overall traffic, and since many if not most
DNS implementations spread out DNS query load between nameservers anyway
(whether they use RTT or just randomization/round-robin) and
nameserver-failover is mandatory, there is little to no incentive to play
these games with NS records. (And don't forget that, due to the indirect
nature of NS resolution, if one _really_ felt the need to
dynamically-load-balance DNS traffic, one could always leave the NS RRset
static and just load-balance the A records associated with the NS names).

> 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 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.

>         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.

Hmmm... I'm not sure why we're going off on this "load-balancing
NS records" tangent. My only point is that there has been very little push (if
any) to dynamically-load-balance NS records. Is there any *evidence* for your
argument that if A records can be legally load-balanced "handing out different
NS records is surely soon to follow"? Dynamic load-balancing has been around a
while now, and while I see plenty of products that mess around with A records,
so far none that attempt to load-balance NSes. In fact, as Mark pointed out,
some of these load-balancing products can *only* deal with A records, and
don't know about NS records at all. 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.

> >  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.

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. If client A resolves a name to X and client B resolves the same name
to Y, then client A (or a client that is using client A as its
nameserver) connects to X and client B (or a client that uses it) connects to
Y, and unless they compare notes with each other somehow (which typically
clients *don't*), they'll never know they're getting different answers for the
same query. Where is the damage potential here? The two clients are just being
treated as if they are on two different logical/virtual networks.

> >  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?

If I thought there was breakage here, maybe I would. In my opinion, the
load-balancers aren't violating anything in the core (i.e.
mandatory-to-implement) DNS protocol, and not causing any interoperability
problems. 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.

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. This is not an interoperability problem, _per_se_, just an
inefficiency. I'm hatching an idea to deal with that (an embryonic form of
which I described in my previous message), and even written some code to that
effect. Unfortunately, I don't have much time to spend on this _and_ I'm
certainly not a professional programmer, so it's pretty slow going. You'll
probably hear about it if I come up with anything useful.


- Kevin