- Test - lists.nanog.org

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> It's too bad that namedroppers can't be referred to as a free and open forum > to discuss such issues (see http://cr.yp.to/djbdns/namedroppers.html) Oh god, not that again. Listen, if you want a forum where anybody can say anything to anybody about anything at any time, then start one, go read alt.flame. In neither case will you find me there. In the real life of nominal grownups, some things are limited in some places at some times.

2 1

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> Is 'behaviour not intended by the original rfc' your definition of 'broken'? Nope. > But the main question is, if this is "broken.", please elaborate what > exactly "breaks." I take it that unless I can point to some specific situation in which some specific application or user community is negatively impacted by this, you'll go on assuming that this deviant behaviour is merely an exercise in creativity. In that case, discussion would be pointless. If that's not the case, though, consider that a correct implementation of DNS would be within its rights to take note of the "same serial number but incoherent answers" condition and declare the zone unreachable. I'm not saying that BIND will ever do this (nor that it won't!), but I will say that I wish it had done this all along, since this is not by far the only erroneous configuration that such logic would have detected. It's possible that DNSSEC, if deployed, will cause these erroneous configurations to be detected and properly dealt with. If you're doing something that a correct implementation (which merely happens not to exist yet) could correctly treat as an error, then what you're doing fits my definition of "broken." If you think that the protocol specification is simply out of date and needs to take account of this kind of intentional incoherence, then you are welcome to try updating it. DNS is a distributed, autonomous, reliable, coherent database -- not a mapping service. DNS is about fact, not value -- it's about mechanism, not policy. No matter how you slice it, intentionally incoherent DNS zones are "broken."

4 3

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> The way to go about this is to see if breaking existing practice will break > current implementations and plausible future implementations. Allow me to apologize, once again, to Microsoft. In the NT 3.5.1 resource kit they shipped a DNS server which had to do its zone transfers one record per message since "existing practice" and "current implementations" meant BIND4 which knew no other way. Fortunately we didn't write a BCP describing BIND4's deviant behaviour, but rather, fixed it in BIND8 and beyond. > > If that's not the case, though, consider that a correct implementation of > > DNS would be within its rights to take note of the "same serial number but > > incoherent answers" condition and declare the zone unreachable. I'm not > > Would be pretty silly, and overstepping the robustness principle. Whether behaviour is robust enough to be called a BCP or not is fodder for a detailed analysis amongst people who *want* to study and debate such things. That mailing list, for DNS, is called namedroppers(a)ops.ietf.org. (Not NANOG.) > So by your logic, by making sure that the serial numbers never match, we > would 'unbreak' the situation? Seems like a step in the wrong direction. There is, simply is and we're not going to argue about it, an identity mapping between a zone's contents and a zone's serial number. If you don't like that then you should find a way to change it. Which direction is "wrong" is better discussed on namedroppers(a)ops.ietf.org than here.

1 0

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> Hrmm, no, that is called "Akamai", isn't it? :-) I wouldn't presume to speak about Akamai's methods. Perhaps Avi's listening. > ... still collecting Heirloom-Quality Specimens of Pre-Owned Mirror-Image > Cache Routers for our Museum of Internet Treasures, drop us a line if you > still have any available.... How many have you located so far?

3 2

Re: sub-basement multihoming (Re: Verio Peering Question)
by smd＠clock.org 07 Oct '01

07 Oct '01

| The "BGP uninformed" ask, "Why can't traffic just choose one of | two paths? The "BGP informed" ask that too. However, they know the technology isn't quite up to this worthy trick: | magic behind the scenes ... "just works", and all traffic should | be able to use all of their connections. ... except where that is not desired for policy reasons (e.g., don't use the volume-charged connection when the flat-rate connection isn't full). These are *hard problems*, unfortunately, and are still in the land of blue-sky research. Meanwhile, the problem is that the demand to do fancy routing things outstrips the Internet's current collective ability to supply it. As a result, we have to say "no" (or more $ than you can afford) to alot of things that seem worthwhile. One of those things is "low-value prefixes", independent of who announces them to the world. | I think that the demand is there -- current products just don't allow it. That's the crux of the problem, independent of whose "fault" it is that current products are not up to the task. Sean.

8 9

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> There obviously is a need for an 'official' method to do global load > balancing using DNS. Ouch! No, there isn't. Not "obvious" to me, that is. > Let's face it, people are doing it now on a not so large scale but that > is rapidly changing because of the introduction of both hardware and > software solutions that (mis)use DNS to overcome it's current limitation. DNS has no current limitation that is relaxed by making it less coherent. People abuse DNS due to limitations in other parts of the TCP/IP stack, but DNS coherency introduces no problems of this kind on its own behalf. > I'm not very interested in the discussion why this behaviour would be > broken. It's for more interesting to talk about improving DNS so that > there will be room for things like load balancing or dynamic DNS. In > such a way that people will not start screaming when they see TTLs of > 30 seconds or non-linear behaviour of load balancers. If your goal is to arrange for global content mirroring, and binding of content clients to whichever content server will give them the best measured performance for any given transaction, then using DNS qualifies for a "you're digging in the wrong place" award. (You won't find what you're looking for but you will make a hell of a mess everyplace else.) Note that if you'd like to debate fine points of DNS, there's a mailing list (namedroppers(a)ops.ietf.org) for it, and that such traffic would be off-topic for this (nanog@) list.

2 1

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> > or any other criteria, then the name for this is: "broken." > > I suppose you don't do split-horizon DNS, then? Of course I do. With a NAT or firewall box between the different sets of users so that no DNS data can leak between the deviant worldviews.

1 0

Re: dns based loadbalancing/failover
by Paul A Vixie 07 Oct '01

07 Oct '01

> Better tell that to those that have built successful businesses on what > you call "broken." if having a product be "broken" kept folks from making money at it, quite a few companies we can each think of(*) wouldn't exist today. (*) no i'm not going to name names

1 0

Re: dns based loadbalancing/failover
by rs＠seastrom.com 07 Oct '01

07 Oct '01

Paul Vixie <vixie(a)vix.com> writes: > > Hrmm, no, that is called "Akamai", isn't it? :-) > > I wouldn't presume to speak about Akamai's methods. Perhaps Avi's listening. It's reasonable to assume that Akamai is deterministic, and is not dependent on the "Jeopardy Method" (who's-quicker-on-the-buzzer) that Bert Hubert asked in an earlier message. Stating more than that is above my pay grade. If you insist on deploying the Jeopardy Method, please remember to phrase your reply to a DNS query in the form of a question: rs@bifrost [2] % dig @192.148.252.10 19.252.148.192.in-addr.arpa. any ... ;; ANSWER SECTION: 19.252.148.192.in-addr.arpa. 5M IN PTR what.is.dhcp-19.seastrom.com. ... ---Rob

1 0

32 Old Slip
by Sean Donelan 06 Oct '01

06 Oct '01

I'm trying to put together a timeline of events post September 11, and am having a bit of trouble figuring out what happened with 32 Old Slip. There were a several messages about generators not starting, running out of fuel, etc Tuesday evening. If anyone has good first, second or third-hand knowledge about the details, could you send me a note.

1 0