One Domain; Multiple IPs.

[Kevin Darcy]

Brad Knowles wrote:

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

Again, we seem to be drifting off on a tangent. The original claim was that giving
different answers to the same question (let's call this answer-differentiation for
short) without incrementing the zone serial number is a protocol violation. My
response was that about the only thing which cared about serial numbers was
AXFR/IXFR. This didn't start as a complaint about AXFR/IXFR; AXFR/IXFR got dragged
into the discussion purely from the serial-number-increment angle. I'm just
pointing out that AXFR/IXFR is not an indispensable part of the protocol or any
implementation thereof, and there are compelling reasons to use more sophisticated
replication mechanisms. For the increasing number of folks who go that route,
serial numbers are often meaningless.

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

That's a self-fulfilling prophecy. If people are warned away from using
load-balancing DNS servers, then that software will never get a chance to mature to
the level of BIND. Why stifle an emerging technology just because of unfounded
fear, uncertainty and dread? 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!)

>         Secondly, you're using the DNS for something it was not designed
> to do, [...]

Volatile and/or inconsistent DNS data were *always* anticipated:


>  - Most of the data in the system will change very slowly (e.g.,
>      mailbox bindings, host addresses), but that the system should
>      be able to deal with subsets that change more rapidly (on the
>      order of seconds or minutes).
>


> [...]
>
>    - Access to information is more critical than instantaneous
>      updates or guarantees of consistency.
>

(RFC 1034, Section 2.3, "Assumptions about usage").


> [...] and in a role it serves particularly poorly.
>

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

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

FUD.

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

Chapter and verse, please. Where does it say that any of these things are mandatory
to implement?

BTW, if I'm living on another planet, then I'm in good company -- kre concurred
that AXFR was optional, and nobody else on namedroppers challenged the claim. We
call our planet "Earth". What do you call yours?

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

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. It would only be if someone tried to layer something really fancy,
i.e. too smart for its own good, on top of DNS, assuming global consistency of
answers to different clients -- "complete knowledge" -- that answer-differentiation
might pose a problem. No-one's doing that.

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

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.

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

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? That's bogus. If
someone can cite an interoperability problem with answer-differentiation, then let
them step forward and identify the problem. 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. Does this
absence-of-problems-to-date prove conclusively that no interoperability problems
are in store? Nope. It's circumstantial evidence, to be sure, but it's the only
concrete evidence we have. Everything else is just FUD, or armchair interpretations
of what the "intent" was of various specifications, or personal opinions about how
DNS "should" work. I'll take concrete evidence over those any day.

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

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. For many organizations with less
stringent load-balancing requirements and/or low budgets, I think DNS-based
load-balancing is a good fit. And if minor extensions to the protocol can make
load-balancing available to thousands of organizations that wouldn't otherwise have
it, and more palatable to the Internet as a whole, then it's probably worth
enacting them.

BTW, try querying www.jeepunpaved.com on the Internet and tell me if your client
blows up. Sure, neither of its nameservers can answer non-A queries intelligently,
but why do they *need* to? (Amusingly, Rob Austein's insistence about serial-number
increment tends to become rather moot when there *isn't* an SOA record, at least
not any that anyone can successfully query...)

(And no, I didn't have any say in the selection of that particular load-balancing
technology for our public web infrastructure. In fact, I didn't even know they were
considering a DNS-based load-balancing solution until after we'd already bought it.
Sometimes these things happen in large organizations).


- Kevin