One Domain; Multiple IPs.

[Kevin Darcy]

Brad Knowles wrote:

> At 6:00 PM -0400 7/16/01, Kevin Darcy wrote:
>
> >  I agree. The protocol purists appear to be out of touch with the way DNS is
> >  evolving in the real world.
>
>         No, generally speaking, I believe that they've got the right
> idea.  The things that they say are protocol violations do tend to
> cause problems.  The issue is whether they cause worse problems than
> the other problems that they're trying to solve, and in many cases I
> would submit that this could well be true.

What problems are caused by this alleged violation? If I get two different
answers for the same question in quick succession, even though the serial number
for the containing zone hasn't changed, am I, as a resolver implementation, going
to blow up? Hardly. 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. 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. With respect to "leaf" nodes like address records, stubs are really
no different than any other resolver.

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.

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, at that particular time, so that the client would, if it cares about such
things, know explicitly that the answer might change without warning (and without
a change to the serial number), or that the answer might be different if queried
from another address. It might also be useful to extend NOTIFY to *all* record
types, not just for slaves, and allow properly-signed NOTIFYs to actually contain
the data they are NOTIFYing about, e.g. "A record foo.example.com changed and
here's the new value". If *all* resolvers could get updated whenever a piece of
data they cached changed, maybe these load-balancers could use reasonable
TTL values instead of the tiny, inefficient ones they typically use today. (The
resource costs associated with keeping track of who all needs to be NOTIFYed, and
actually sending out all of those NOTIFYs, would have to be figured into the
load-balancing equation, of course).


- Kevin