October 2001 - Test - lists.nanog.org

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

08 Oct '01

> You've conveniently failed to address the issue where the list moderator > of namedroppers took it upon himself to edit the content of posts before > forwarding them to the list. I'm ignoring that claim, yes. I'm not sure how "convenient" it is for me. > ... The messages that were sent clearly fell within the list's charter, > yet they were rejected and/or edited by the moderator for what appear to > be entirely personal reasons. Randy can be hard to take sometimes (unlike, say, me) but I completely trust his judgement as to what is, and is not, topical for the namedroppers@ list. Remember, if you wanted to start a nam3dr0pp3rs@ list someplace else and post introductions to it on ietf@ and namedroppers@, noone could stop you. So if you or anyone else is thinking of claiming to be experiencing censorship, I hope you've got evidence of prior restraint to back that claim up. Your iron, your lists, your rules. Go for it. Best of luck, and all that.

3 2

BGP noise tonight?
by cowie＠renesys.com 08 Oct '01

08 Oct '01

Say, our alarms went off tonight when we saw a roughly tenfold spike in BGP prefix announcement and withdrawal rates at RIPE's rrc00 and rrc03 collection points in Amsterdam. The trouble started around 20:00 GMT, hit its peak by about 21:00 GMT, and has trailed off slowly since then. Looking at the worst-behaved prefixes and AS paths led me to put in a call to the tech support center of an unnamed Major Provider, who confirmed that there had been a major BGP event but would provide no specifics. So, what's going on out there in the NOCs tonight? Inquiring minds want to know. --jim

4 3

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

08 Oct '01

> Most mailing lists I am on seem to get by fine without overt > moderation - including this one. you have your facts wrong. the operators of this mailing list are perfectly capable of sending private mail to people like me who keep posting off-topic drivel like the message i am now typing. > Most moderated lists I am on seem to get by with thread killing - an > argument is allowed to run for a few posts, then the moderator posts that > he is officially killing the thread, and further posts on that will be > rejected (and should be taken to email). sure. namedroppers(a)ops.ietf.org works that way, as an example of one such. > Prefiltering to suit *any* one individuals opinion of what is or isn't on > topic seems highly suspect for any list, and unacceptable on a list > supposedly to define policy. so in order for a policy-defining forum to be considered representative, it must be open to all posts on all topics from all parties at all times? that does not match not my intuition on the matter. > Note I have never read the list in question, so am arguing on general > principles here, not this specific instance..... perhaps a parallel list > setup (with $listname and $listname-filtered) could be set up with posts > making it to the second list only with moderator approval? i'm sure that if one were set up it would be used by many people. (not me.)

3 2

Re: brainstorms (Re: dns based loadbalancing/failover)
by E.B. Dreger 07 Oct '01

07 Oct '01

> Date: Sat, 6 Oct 2001 22:52:05 -0400 > From: dsr(a)akamai.com > > If heavily enough distributed, congestion should be highly > > localized... if present at all. Let's assume that a "basic > > server" can service 10 Mbps of traffic. Install servers in > > various points, a la Akamai... any traffic sinks here ever manage > > to overload your Akamai boxen? If so, how often compared to a > > random traffic source. > > Please don't start attacking your local Akamai box to prove > this, though. Brute-force is so inelegant. !!! My intended point was that Akamaized sites are less likely to be overloaded than non-Akamaized sites. Traffic spikes from incidents such as the release of the Starr report and the bombings last month have demonstrated this. Given enough hosting points, overloading becomes rare; I used Akamai as a real-life example. Given that overloading is rare, we can focus on failover, and worry less about load-balancing. Given that we need only to focus on failover, the problem (and hopefully the solution) becomes much simpler. I'd hope that the average NANOG reader knows better than to try any "let's see how much traffic before this breaks" stupidity... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

2 1

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

07 Oct '01

> The really neat thing is that you can do this with any nameserver. Install > N nameservers and connect each of them to one of your ISPs. These > nameservers are all masters, and all contain different data. If you have several nameservers all pretending to be masters for some zone but offering different responses based on IP locality, predictive performance, or any other criteria, then the name for this is: "broken."

10 9

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