- Test - lists.nanog.org

RE: Root zone change -- d.gtld-servers.net
by rdobbins＠netmore.net 20 Sep '00

20 Sep '00

I know the difference, it's just been common practice for a long time to refer to them as the 'root' servers. You and Mr. Bush are right about that, of course - but I still think it was nice of NSI to actually let us know about the TLD server change. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: woods(a)weird.com [mailto:woods@weird.com] Sent: Tuesday, September 19, 2000 7:41 PM To: nanog(a)merit.edu Subject: RE: Root zone change -- d.gtld-servers.net [ On Tuesday, September 19, 2000 at 18:58:21 (-0700), rdobbins(a)netmore.net wrote: ] > Subject: RE: Root zone change -- d.gtld-servers.net > > Yes, in the common parlance, they're referred to as the 'root' servers. > Most technical people, including myself (unless we're being pedantic) refer > to them in the same way. It would appear that at least some technical people need to learn to mind their p's and q's a with a little more care and attention! There is, and can ony be, one ``root'' in the DNS. Everything else is a subdomain. Just because once upon a time the root nameservers and the most common Top-Level-Domain nameservers were one in the same doesn't mean you can freely refer to the TLD servers as "root" servers! -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

RE: Root zone change -- d.gtld-servers.net
by rdobbins＠netmore.net 20 Sep '00

20 Sep '00

Since we've all complained loudly and longly at one time or another about the dearth of any operational information at all coming from NSI, I don't think it's necessarily polite or prudent to slap them down just when they're becoming open with us. I'm grateful to Mr. Verd for making the effort to inform network operators of changes in the DNS infrastructure, and hope that he continues to do so. The more information we have, the better we're able to react to changes, troubleshoot problems, etc. In this particular case, I can see where information about root nameserver changes might be of use in figuring out broken name resolution due to caching issues, etc. Kudos to NSI for letting us know about changes -before- they occur - keep up the good work! ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: John Hawkinson [mailto:jhawk@bbnplanet.com] Sent: Tuesday, September 19, 2000 1:31 PM To: Randy Bush Cc: Verd, Brad; 'nanog(a)merit.edu' Subject: Re: Root zone change -- d.gtld-servers.net > while i appreciate you folk trying to be open and give us all some info, it > is not clear to me what you expect us to do with this info and therefore why > you post it. Randy, I appreciate knowing when the authoritative nameservers for the root zone, and for zones like .COM, .NET, .ORG, and .EDU change. > the only change that could occur that would require thought on my part would > seem to be if the iana announced a change of the ip address of one of the > root servers. am i not understanding something? Even in that case, thought would be pretty limited. I think this is more useful than most of the mail to nanog. On some level, it serves as a "be on the lookout for problems that might inadvertantly result," as well. --jhawk

3 2

S-BGP (some operational content)
by Timothy Brown 19 Sep '00

19 Sep '00

Hi NANOG folks, I read an IEEE(?) draft on Secure BGP a short time ago, a draft which discussed using a PKI to prove that a netblock was reachable through a give provider. There were several other concepts in the document relating to actual vulnerabilities in BGP. Most of them looked valid. My questions become: a) Has there ever been a published man-in-the-middle attack of someone using BGP to affect someone else's network? b) Does anyone know of other groups that are focusing on developing new ways of combating the vulnerabilities? Brgds, T

4 3

Re: (O-T)
by Dave McKay 19 Sep '00

19 Sep '00

Agreed, Please excuse my previous statement about level3 engineers. It was ment to be a private reply. (damn group reply!!) Its a personal opinion, and should be taken as such. (Its possible, and most likely true that l3 is a good provider, I just happened to speak with a not-so-bright engineer.) dan(a)netrail.net (dan(a)netrail.net) wrote: > I've found that the vast majority of very large ISPs have clueful > engineers. Hoever, like many routing problems, it's not a question that a > host exists, it's a question of reachability. Many times there are clueful > engineers, but there are so many layers between them and customers, they > are very hard to access. > > Daniel Golding > Director of R&D "I'm not evil. I'm just drawn that way" > NetRail, Inc. > 1-888-NetRail > > On Tue, 19 Sep 2000, Dave McKay wrote: > > > > > Good connectivity, but clueless engineers. Problem solving is not their > > strong point. > > > > Stephen Burd (sburd(a)tm.net) wrote: > > > > > > hey, can someone tell me what they know about Level 3 Communications please? > > > > > > rsvp privately > > > > > > thank you > > > > > > -Stephen > > > > > > > -- > > Dave McKay > > dave(a)sneakerz.org > > Network Engineer - Google Inc. > > > -- Dave McKay dave(a)sneakerz.org Network Engineer - Google Inc.

1 0

Root zone change -- d.gtld-servers.net
by Verd, Brad 19 Sep '00

19 Sep '00

Informational message: Effective zone serial number 2000091901, f.root-servers.net (192.5.5.241) will no longer be in the list as authoritative for com, net, org. In its place d.gtld-servers.net (208.206.240.5) will be added as an authoritative server for com, net, org. The new set of servers authoritative for these TLDs will be: A.ROOT-SERVERS.NET. 198.41.0.4 G.GTLD-SERVERS.NET. 198.41.3.101 E.GTLD-SERVERS.NET. 207.200.81.69 F.GTLD-SERVERS.NET. 198.17.208.67 D.GTLD-SERVERS.NET. 208.206.240.5 J.GTLD-SERVERS.NET. 198.41.0.21 K.GTLD-SERVERS.NET. 195.8.99.11 A.GTLD-SERVERS.NET. 198.41.3.38 M.GTLD-SERVERS.NET. 210.176.152.18 C.GTLD-SERVERS.NET. 205.188.185.18 I.GTLD-SERVERS.NET. 192.36.144.133 B.GTLD-SERVERS.NET. 203.181.106.5 This will not require any change to the root.cache file and f.root-servers.net will provide answers for com, net, and org in parallel for enough time to accommodate the zone's TTLs. -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

3 2

problems with uunet/worldcom/whoever-they-bought-this-week
by Jim Mercer 19 Sep '00

19 Sep '00

ok, this is getting ludicrous. [ cut to the chase, if you are a non-US uunet/worldcom/mci customer, you can skip my diatribe and jump down to the bottom ] this is the third monday night when we have had a major BGP/connectivity outage with uunet.ca. two mondays ago, (ie 3 weeks), we had an 11 hour combined outage of either connectivity and/or BGP routing. this was topped off by them restoring the config from an old backup, including a slew of old static routes. last monday we had a 4 hour outage, similar issues. tonight, we got: 18:30 me -> uunet.ca: so, what's the problem uunet.ca: not sure, US-NOC is looking into it 19:15 me -> uunet.ca: any ETA? uunet.ca: problem solved, although the CPU on the router is 100% due to BGP recalc. should be OK soon. 21:30 me -> uunet.ca: so, what's the problem? uunet.ca: bad ATM card, been replaced, back up, although the CPU is 100% due to BGP recalc. should be OK soon. 01:30 me -> uunet.ca: so, what's the problem? uunet.ca: US-NOC is saving the configs customer-by-customer and will be rebooting the router RSN. no ETA. i'm not sure, but a lot of major problems seem to have cropped up since uunet.ca dumped their local technicians and went dependent on the US-NOC. are other non-US uunet customers getting the same treatment? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

6 5

RE: problems with uunet/worldcom/whoever-they-bought-this-week
by rdobbins＠netmore.net 19 Sep '00

19 Sep '00

I just spent 80 hours over four days trying to get a DS3 to uu.net fixed - turns out the circuit goes from their POP to WorldCom, from WorldCom to MFS, and -then- to PacBell. Only problem is, they didn't tell me that, and so we started troubleshooting from the far side of the PacBell end, thinking that it was PacBell all the way through, and only finding out after 2 days what the toplogy really looked like. Of course, they'd just assumed that there was no way that -their- portion of the circuit could have problems. PacBell even replaced a module in a DACS 3, thinking -that- was the problem. So it was a bad card or something in an MFS OC-48 mux . . . fine, MFS replaced it. Then they started doing intrusive testing on some OC-3 bundles they were having problems with, of which bundles my DS3 was apparently caught up in, so the circuit kept pogoing for another 8 hours. Since uu.net bought WorldCom and MFS, you'd think they'd have better coordination, no? All that, combined with the fact that MFS and WorldCom apparently have zero remote diags capability and will only dispatch techs when you threaten to sue them (literally), made for a great weekend. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Jim Mercer [mailto:jim@reptiles.org] Sent: Monday, September 18, 2000 10:53 PM To: nanog(a)merit.edu Subject: problems with uunet/worldcom/whoever-they-bought-this-week ok, this is getting ludicrous. [ cut to the chase, if you are a non-US uunet/worldcom/mci customer, you can skip my diatribe and jump down to the bottom ] this is the third monday night when we have had a major BGP/connectivity outage with uunet.ca. two mondays ago, (ie 3 weeks), we had an 11 hour combined outage of either connectivity and/or BGP routing. this was topped off by them restoring the config from an old backup, including a slew of old static routes. last monday we had a 4 hour outage, similar issues. tonight, we got: 18:30 me -> uunet.ca: so, what's the problem uunet.ca: not sure, US-NOC is looking into it 19:15 me -> uunet.ca: any ETA? uunet.ca: problem solved, although the CPU on the router is 100% due to BGP recalc. should be OK soon. 21:30 me -> uunet.ca: so, what's the problem? uunet.ca: bad ATM card, been replaced, back up, although the CPU is 100% due to BGP recalc. should be OK soon. 01:30 me -> uunet.ca: so, what's the problem? uunet.ca: US-NOC is saving the configs customer-by-customer and will be rebooting the router RSN. no ETA. i'm not sure, but a lot of major problems seem to have cropped up since uunet.ca dumped their local technicians and went dependent on the US-NOC. are other non-US uunet customers getting the same treatment? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

CAISO expects to have a stage-three energy shortage this week
by Sean Donelan 18 Sep '00

18 Sep '00

California is sweating through another hot spell this week. CAISO's web page http://www.caiso.com/ is very slow today. CAISO has already called for a mandatory load reduction of 1700 megawatts today. Today's peak is predicted to reach 44537 Megawatts at 4pm. Tomorrow's load is predicted to be 44827 Megawatts. http://dailynews.yahoo.com/h/cn/20000918/tc/silicon_valley_sweats_as_heat_w… ISO spokeswoman Stephanie McCorkle said today that the region is likely to experience the year's first stage-three energy emergency this week, causing power to shut off in "rotating blackouts." Typically, businesses and residential consumers get no warning before power is turned off in a stage-three emergency. "At the most," McCorkle said, "there could be up to a half-hour notice."

1 0

HR 4445 Reciprocal Compensation
by Robert Cannon 18 Sep '00

18 Sep '00

I would note that the FCC has an open proceeding to consider what compensation mechanism should apply to ISP bound traffic. The FCC originally concluded that ISP Bound traffic is interstate - normally recprical compensation applies only to local calls. Instead of saying reciprocal compensation does not apply, the FCC (a) affirmed all existing agreements and (b) said no rule exists for ISP bound traffic and therefore opened an inquiry to make a rule. The DC Circuit Vacated the FCC's conclusion that it was interstate traffic. In response, the FCC released a further notice requesting comments on what to do about ISP bound telecommunications in light of the Court's decision. This is an open administrative proceeding. Anyone can file comments. Comments can be filed online on the FCC's electronic comment filing system as easily as writing an e-mail. The Formal Comment period has closed - all that means is that when you file your comments, you need to check off the box that says this is an "ex parte" filing. The FCC generally continues to accept comments until the very last minute. The FCC is required by law to consider your opinion in its decision. More information on the proceeding can be found at http://www.cybertelecom.org/rcomp.htm#fcc Robert Cannon www.cybertelecom.org ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

1 0

IS-IS/OSPF Comparison
by ccie10 18 Sep '00

18 Sep '00

Looking for some information, advantages, disadvantages of utilizing either OSPF or IS-IS as an IGP. I need some head to head comparisons or case studies, links would be helpful. thanks

2 1