- NANOG - lists.nanog.org

Re: Incease in latency to TLD servers
by Paul Vixie 26 Jan '01

26 Jan '01

http://f.root-servers.org/ looks normal to me, for whatever that's worth. additionally, http://f.root-servers.org/drew-pkts.html and http://f.root-servers.org/jason-pkts.html both show yesterday's microsoft.com problem clearly, but don't look whacky for today. (tuesday and friday show some reboots due to software upgrades.)

1 0

Re: Incease in latency to TLD servers
by Steven M. Bellovin 25 Jan '01

25 Jan '01

In message <0127E258EE29D3118A0F00609765B44847D0DC(a)dhcp-gateway.sitestream.net> , Karyn Ulriksen writes: > >Sean, > > The seven day map at http://average.miq.net/Weekly/markMM.html shows it >as even more dramatic. When I looked at the daily one, I wonder if perhaps >the demand of all those DNS servers re-querying for Microsoft was the >cause... but if that was the case, I assume (yuk!) we would have seen it >yesterday, too. The word I've heard is that there's a *large* amount of traffic at least one root server for assorted Microsoft domains. No idea what caused the other spikes... --Steve Bellovin, http://www.research.att.com/~smb

1 0

RE: Incease in latency to TLD servers
by Karyn Ulriksen 25 Jan '01

25 Jan '01

Sean, The seven day map at http://average.miq.net/Weekly/markMM.html shows it as even more dramatic. When I looked at the daily one, I wonder if perhaps the demand of all those DNS servers re-querying for Microsoft was the cause... but if that was the case, I assume (yuk!) we would have seen it yesterday, too. Have you ever seen spikes like this before? Any theories? K > -----Original Message----- > From: Sean Donelan [mailto:sean@donelan.com] > Sent: Thursday, January 25, 2001 1:19 PM > To: nanog(a)merit.edu > Subject: Incease in latency to TLD servers > > > > The Matrix (http://average.miq.net/Daily/markMM.html) is showing a > remarkable rise in latency to many DNS servers. Has someone found > a nifty new use for DNS servers? > > > >

2 1

RE: Incease in latency to TLD servers
by Scott Madley 25 Jan '01

25 Jan '01

As I try and normally stay away from the fluff that is Slashdot. I remember reading an article there some months ago about this. Further searching leads me to what you where talking about. Apparently it actually works. http://slashdot.org/articles/00/09/10/2230242.shtml -Scott -----Original Message----- From: M. David Leonard [mailto:mdl@equinox.shaysnet.com] Sent: Thursday, January 25, 2001 4:35 PM To: Sean Donelan Cc: nanog(a)merit.edu Subject: Re: Incease in latency to TLD servers Sean- Did I have a bad dream or wasn't someone trying to exploit some sort of tunneling via DNS connections to avoid firewalls blocking napster traffic? If I'm 'way off in left field just ignore me...... David Leonard ShaysNet On 25 Jan 2001, Sean Donelan wrote: > > The Matrix (http://average.miq.net/Daily/markMM.html) is showing a > remarkable rise in latency to many DNS servers. Has someone found > a nifty new use for DNS servers? > > > > >

1 0

Re: History: lengthy outages
by Sean Donelan 25 Jan '01

25 Jan '01

On Thu, 25 January 2001, Randy Bush wrote: > >> UUNET cisco/bay router problems: November 7 1997 lasted 5 hours > > /vijay "remembering entirely too well" gill > > if this is 129/8, then i believe that major providers were down for almost > two days. That was a different one, but I didn't have that data readily available. The cisco/bay bug I was thinking of was when Cisco's kept reseting all their BGP sessions when they saw a particular announcement from Bay routers. There are a whole bunch of interesting problems I remember, but can't find the date. There was the Sprint "0.0.0.0" route problem. There was the 129/8 which happened shortly after AS7007. There was an ANS bug in the ENSSs which knocked them out. I tried not to include "malicious" acts, such as DDOS since I think they should be considered separately. Although I recognize often the underlying cause of the security issue may be related to operational error or bugs.

2 1

Incease in latency to TLD servers
by Sean Donelan 25 Jan '01

25 Jan '01

The Matrix (http://average.miq.net/Daily/markMM.html) is showing a remarkable rise in latency to many DNS servers. Has someone found a nifty new use for DNS servers?

2 1

Re: Microsoft spokesperson blames ICANN
by Patrick W. Gilmore 25 Jan '01

25 Jan '01

At 02:08 AM 1/25/2001 -0600, poptix(a)sleepybox.poptix.net wrote: > >www.microsoft.com is already a CNAME for www.microsoft.akadns.net, aka, >Akamai =) (Didn't I hear microsoft touting it's wonderful clustering/load >balancing features in W2k?) <simple statement of fact which everyone prolly already knows> Please note that if you cannot get a reply from the authoritative name server for [domain].[foo], you cannot be given the CNAME for a host. </simple statement of fact which everyone prolly already knows> (No comment on the reliability of Windows is intended.) > -poptix TTFN, patrick

2 1

RE: Tenure (was Re: MS explains)
by Scott Madley 25 Jan '01

25 Jan '01

I highly agree.. the Internet in purpose was founded for this dissemination of information, and gathering of knowledge. It's a shame that these days you normally can't find detailed evualuations of outage causes and resolutions unless behind the thick vail of an NDA. It's amazing some of the bugs that one finds in the course of work, that will probably never be brought into the light of the smaller networking public (small ISP's, small tech firms). =Scott On Thu, 25 January 2001, "Steven M. Bellovin" wrote: > In message <E14LpXc-0000ET-00(a)roam.psg.com>, Randy Bush writes: > >> I'd love to see a detailed description of what went wrong, and I hope > >> that those in the know will be allowed to post it or present it in > >> Atlanta. > > > >was it not don knuth's turing aware lecture which consisted of a detailed > >analysys of some recent bugs in his code? > > > We all learn much more from failures than from successes. To quote > Alfred E. Neuman, "Learn from the mistakes of others; you'll never live > long enough to make them all yourself." Donald Knuth has tenure. He can give all the lectures he wants about his greatest mistakes. Although all the "experts" say honesty is the best policy, the PR people at publically traded companies feel less is more. When the net was mostly operated and managed by academics, there was a reward in publishing the resultes of your mistakes. In today's net, you are likely to be punished or fired for publically discussing what happened. Ebay has never publically explained what went wrong with their equipment, Abovenet has never publically explained what went wrong with their router configuration, Worldcom has never publically explained what went wrong with their switches. Juniper and Cisco have been trading router interoperability bugs for a while, but they aren't publically discussed. Sometimes you might get a little information under NDA, but publish a "white paper?" Never! Admitly, there are exceptions. AT&T did release a fairly detailed analysis when they lost most of their 5ESSs switches due to a software bug. But it is so rare, we remember them because they are so rare.

1 0

Re: MS explains
by Steven M. Bellovin 25 Jan '01

25 Jan '01

In message <Pine.LNX.4.30.0101242038380.5951-100000(a)anime.net>, Dan Hollis writ es: > >On Wed, 24 Jan 2001, Eric A. Hall wrote: >> At 6:30 p.m. Tuesday (PST), a Microsoft technician made a configuration >> change to the routers on the edge of Microsoft's Domain Name Server >> network. >> At approximately 5 p.m. Wednesday (PST), Microsoft removed the changes to >> the router configuration and immediately saw a massive improvement in the >> DNS network. > >So basically, it took microsoft 23 hours to fix a router configuration. There's a story (possibly apocryphal) about the time that Steinmetz was called in as a consultant to repair problems with some massive piece of electrical machinery. After poking around for a while, some staring, and much thinking, he adjust one screw, and solved the problem. He then proceeded to write out a bill for $1000. The company was outraged. "$1000 for adjusting one screw? You're crazy!" Steinmetz agreed, took back the bill, and tore it up. He then wrote out a new bill: Adjust one screw $1 Knowing which screw to adjust $999 Remember the other half of Jim Duncan's post from last night: There were clearly some mistakes made, but it is also the case that there were a _lot_ of different things going on that contributed to the problem or complicated its resolution. He *worked* this problem; this is a first-hand statement, not conjecture by those who weren't there. Let me put forth a blatant generalization of my own: *all* major failures are due to complex causes. The proof is simple: if you're small and hence presumably clueless (the "mom and pop" ISPs another poster sneeringly referred to), your problems don't cause major failures for the rest of the net. If you're big (and hence presumably clueful), you solve the simple problems quickly and they don't become major failures. Finding and fixing *the* root cause is hard, when you're in the midst of a swamp full of other alligators, and you don't know which one is (currently) biting you in the rear. I'd love to see a detailed description of what went wrong, and I hope that those in the know will be allowed to post it or present it in Atlanta. But I'm willing to wager that it wasn't just (a) a single router configuration change, (b) brain-damage in Microsoft's DNS code, (c) malicious activity aimed at Microsoft, (d) RAMEN-induced misbehavior, or (e) any other single cause. --Steve Bellovin, http://www.research.att.com/~smb

3 2

Re: charitable organization for the shrinkage of the global routing table
by smd＠clock.org 25 Jan '01

25 Jan '01

So I have a bunch of replies, some of which suggest targetting the ISPs directly (phone bank of educated volunteers), some of which wondered why ISPs would care since non-aggregation is seen as good business sense in some cases. A couple replies asked if they could operate the cameras; one myopic confused soul suggested *I* model instead of Vint. And then there were a couple replies that indicated that we are *already* running into problems with some combination of numbers of routes, numbers of paths and numbers of implementation bugs (leaks in one implementation, pointer woes in another). That last point is serious. I humbly suggest that it's time to spam all the end users the NLANR cache researchers can identify as porn browsers with a simple message: Hot sexy babes want YOU to choose a provider who's a good aggregator! [With a URL pointing to someone's CIDR page, with an obligatory link to t&a or c&a or or s&m or s&g or ipv6 or whatever perverted stuff people spend alot of time reading about. Indeed, maybe we can enlist Betty Bowers and the folks at http://www.landoverbaptist.org so that we cover all the bases]. Sean.

1 0