- Test - lists.nanog.org

ANS?
by James Sanford 04 Jul '97

04 Jul '97

Anyone know what's going on? Packets to ANS are going to EU.Net, and I wouldn't doubt it if other networks are screwy too. Digex MAE-East Looking Glass shows: BGP routing table entry for 145.225.0.0/16, version 532087 Paths: (3 available, best #2, advertised over IBGP) 701 286 286 517 198.32.186.249 from 198.32.186.249 (137.39.3.58) Origin IGP, metric 0, valid, external Community: 2548:668 286 517 192.41.177.120 from 192.41.177.120 (134.222.86.34) Origin IGP, valid, external, best Community: 2548:668 1800 1755 517 192.41.177.240 from 192.41.177.240 (198.67.131.49) Origin IGP, metric 16, valid, external Community: 2548:668 AS 517 is University of Karlsruhe, Germany. -- James Sanford - jsanford(a)iaxs.net Infinity AccessNET - 612-944-7123

3 3

Re: Root Servers not updated
by George Herbert 04 Jul '97

04 Jul '97

David Holtzman wrote: >There's a lot of smoke going around this list and others about the root >servers. The internic generated a corrupt zone file on Tuesday which Bind >did not load and prevented XFERs to the secondaries. We became aware of it >last night and it is currently fixed. New zones will be ready for XFER >within the next hour. Thank you for the information. >The issue with requiring a login for retrieving the zone files was designed >to help reduce spamming. We are currently experiencing a huge system load >due to several individuals who are trying to register recently deleted >domain names. The requests are being repeated and fired off every few >milliseconds. One individual has over 50,000 templates in the system as we >speak. We believe that by requiring an identity to download the zone >files we will better protect the community. > >Note that this ftp policy has not yet gone into effect. Also thank you for the information... >Lastly, it appears irresponsible to fan the flames of "the internic is >trying to get over" via lists like these. How about giving us the benefit >of the doubt? We generally stay silent on these issues, but feel that it >is important to explain what we are doing and why. No, we are not trying >to take over the net. Sorry for the confusion. I had some long conversations with Chuck Gomes there following the great PR debacle of the InterNIC billing cleanup earlier this year. One of the aspects of this covered the need for more proactive information releases by InterNIC when things go wrong. InterNIC, being a singular and critical resource, is in a particularly touchy situation with regards to the general question of trust on the internet. What with all the policy issues that are also flying, as well as a moderately bad history (some of which was bad PR/info release rather than actual problems), InterNIC suffers from an ongoing problem that large segments of the network operator community fear you. That is, obviously, not a good thing to have. The only solution is that InterNIC has to become actively proactive about informing the community when things go wrong. I don't think it's too much of a stretch to say that at the very least the operators of all the root nameservers should have had the problem report mailed to them on Tuesday, if not made more publically available via the nanog mailing list, etc. Again, I urge InterNIC to understand how important it is that you push this information out to people rather than have us get flustered and come looking for it when things go wrong. -george william herbert gherbert(a)crl.com

1 0

RE: URGENT! Root Servers not updated
by Rodney Joffe 03 Jul '97

03 Jul '97

Slow downn a little... Apparently Mark Kosters is on vacation... so they're trying to track him down to get this cleared up (this info gleaned as a result of trying to deal with Genieweb claiming .com authority :-) Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Jesse Caulfield [SMTP:jesse@netthink.com] > Sent: Thursday, July 03, 1997 10:17 AM > To: Gordon Cook > Cc: nanog(a)merit.edu > Subject: Re: URGENT! Root Servers not updated > > As I understand it (and I really don't so you should stop reading > now...) > the purpose of locking down the zone files (or whatever) is not > necessarily a power grab by NSI, but rather a move to protect the > people > and information who appear in that database (or whatever) from > otherwise > nefarious miscreants. Folks who want the file will simply have to > register > for it. > > I believe information generally wants to be free, but there may be a > good > business, technical and socially acceptable case for asking users of > the > database to identify themselves. > > Also, it's possible NSI got ahead of themselves and locked stuff up > before handing out the keys. What with the move and power grid > failures in > Herndon, anything's possible. > > -- > JMC > > > On Thu, 3 Jul 1997, Gordon Cook wrote: > > has the basic problem that paul vixie complained about been solved? > > > > I called a knowledgable source last night. That person was aware of > the > > change and said that the proper IANA people had been informed in > advance > > and had (he thought) not disagreed. the change he believed was not > for any > > of the reasons that paul feared. > > > On Wed, 2 Jul 1997, Paul A Vixie wrote: > > The message below was one of several that came to me today. > Apparently, > > when NSI changed the FTP access controls recently for the COM, ORG, > EDU, > > and NET zones, they also disallowed zone transfers from the "A" name > > server to most of the other name servers.

2 1

genieweb.com answering for COM
by seanl＠literati.org 03 Jul '97

03 Jul '97

com. 304 SOA genieweb.com. root.genieweb.com. ( 11 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (7 days) This was cached on one our name servers. Sure enough, dig any com @genieweb.com shows: ;; ANSWERS: com. 86400 SOA genieweb.com. root.genieweb.com. ( 11 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) com. 86400 NS genieweb.com. ;; AUTHORITY RECORDS: com. 86400 NS genieweb.com. ;; ADDITIONAL RECORDS: genieweb.com. 86400 A 198.147.97.23 I wonder if this is what has been causing random COM domain lookups to fail for random people at random places. The time I can see this affecting a name server is if it does a lookup for a domain that's lamely delegated to genieweb.com, and then caches the 'com' reply. I've already left voicemail for the genieweb people. -- Sean R. Lynch <seanl(a)literati.org>

3 2

Re: URGENT! Root Servers not updated
by Marc Slemko 03 Jul '97

03 Jul '97

On Thu, 3 Jul 1997, John Hawkinson wrote: > > Erm... most routing databases use asxxxx, but the NIC uses xxxx. eg. > > whois -h whois.internic.net 6171 > > Doesn't anybody read the instructions around here? MY GOODNESS! > > whois nnnn > > will return all records that match "nnnn", be they people, domains, > AS numbers, networks, or what-have-you. No need to get snarky. You can do it the way you suggest to get only ASes. Or you can skip that to get a list of all records and, in the rare case that there is more than one, do another lookup on that one. On Thu, 3 Jul 1997, Christian Nielsen wrote: > On Wed, 2 Jul 1997, Marc Slemko wrote: > > > Note, however, that just because an AS shows as not existing in the > > InterNIC's database doesn't mean it doesn't exist. From what the InterNIC > > has told me, they have no policy of having pointer records for AS blocks > > allocated to regional registries; it happens sometimes, it doesn't happen > > sometimes, all depending on what they feel like doing. That means that to > > find the owner of an AS you may need to query every regional registery in > > the world. Right now there are few enough such registries to make it > > possible, but it is certainly an annoyance. > > But if you were to go to > > ftp://rs.internic.net/netinfo/asn.txt > > You can see who they belong to. Really? As I said, they do it if they feel like and don't if they don't meaning that some they do. Some, such as the one that as8221 is out of, they don't. For the ones that they do, there are pointers in the whois database saying "oh, go look there" just like there are for netblocks. > PS. I also know that the above file is out of date and needs to be When I asked the InterNIC about it, the response I got for the above block was not that it had not yet been updated, but that it just hadn't been done, no reason for it.

5 4

Re: FW: genieweb.com answering for COM
by Joseph C. Pistritto 03 Jul '97

03 Jul '97

At 10:32 AM 7/3/97 -0700, Rodney Joffe wrote: Yeah it is. Wait till someone steals your network numbers by broadcasting them and their ISP isn't filtering. It's Happened Before. This is one of the things we don't want the press writing about. How darned easy it is for some person making a silly mistake to introduce a big transient problem until it gets killed. Fortunately, people pay attention and kill these things off reasonably quickly, but it makes managing the net a much more "active" thing than one would think at first inspection. A lot of management at a lot of companies (even ISPs), doesn't realize this. The problem of course is that we can't scale the number of people who know how to fix things like this nearly as fast as we can (and are) scaling the network. The whole thing needs to be a lot more insensitive to minor screwups. The fact that most of our protocols (like especially DNS and even to an extent BGP) were designed when the universe of people who would be managing them was much smaller. The problem gets worse when people use old protocols (like DNS) that were intended for one thing (nameing) to implement something different (like load balancing) "because it works". Kind of. On the other hand, with the installed base, replacing old protocols is getting really difficult. As an industry, we need to move this process forward. The network grows while you sleep... -jcp- PS: Personal note: This is my last week at PointCast, hence the 'jcphome' address. That's my permanent address. -jcp- >This has been corrected temporarily. With brute force ;-) > >Genieweb is a downstream customer of Los Nettos, one of our customers. >No-one has been able to reach the company or the contact, so their T1 >was just taken down. I expect a call rather soon, so we can get them to >fix their mistake. > >But it does bring up an interesting point.... is it that easy to create >chaos? They are so far down the food chain, and yet.... > > > >Rodney Joffe >Chief Technology Officer >Genuity Inc., a Bechtel company >http://www.genuity.net > > > >> -----Original Message----- >> From: seanl(a)literati.org [SMTP:seanl@literati.org] >> Sent: Thursday, July 03, 1997 9:59 AM >> To: nanog(a)merit.edu >> Subject: genieweb.com answering for COM >> >> com. 304 SOA genieweb.com. root.genieweb.com. ( >> 11 ; serial >> 10800 ; refresh (3 hours) >> 3600 ; retry (1 hour) >> 604800 ; expire (7 days) >> >> This was cached on one our name servers. Sure enough, dig any com >> @genieweb.com shows: >> >> ;; ANSWERS: >> com. 86400 SOA genieweb.com. root.genieweb.com. ( >> 11 ; serial >> 10800 ; refresh (3 hours) >> 3600 ; retry (1 hour) >> 604800 ; expire (7 days) >> 86400 ) ; minimum (1 day) >> com. 86400 NS genieweb.com. >> >> ;; AUTHORITY RECORDS: >> com. 86400 NS genieweb.com. >> >> ;; ADDITIONAL RECORDS: >> genieweb.com. 86400 A 198.147.97.23 >> >> I wonder if this is what has been causing random COM domain lookups to >> fail for random people at random places. >> >> The time I can see this affecting a name server is if it does a lookup >> for a domain that's lamely delegated to genieweb.com, and then caches >> the 'com' reply. >> >> I've already left voicemail for the genieweb people. >> >> >> -- >> Sean R. Lynch <seanl(a)literati.org> > >Attachment Converted: "D:\PCNMAIL\ATT16935.ATT" >

1 0

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by randy＠psg.com 03 Jul '97

03 Jul '97

I rerecommended the study Ben Black first recommended because it was ingeniously end to end. And real end to end, not end to web. randy

1 0

Re: Root Servers not updated
by Sean Donelan 03 Jul '97

03 Jul '97

>Lastly, it appears irresponsible to fan the flames of "the internic is >trying to get over" via lists like these. How about giving us the benefit >of the doubt? We generally stay silent on these issues, but feel that it >is important to explain what we are doing and why. No, we are not trying >to take over the net. Sorry for the confusion. I'm sorry, I must have missed a message somewhere. On which list did NSI post the announcement about the corrupt zone files preventing the other root servers from updating or the announcement about the changes for those FTPing the zone files prior to Mr. Vixie's message? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Root Servers not updated
by David H. Holtzman 03 Jul '97

03 Jul '97

There's a lot of smoke going around this list and others about the root servers. The internic generated a corrupt zone file on Tuesday which Bind did not load and prevented XFERs to the secondaries. We became aware of it last night and it is currently fixed. New zones will be ready for XFER within the next hour. The issue with requiring a login for retrieving the zone files was designed to help reduce spamming. We are currently experiencing a huge system load due to several individuals who are trying to register recently deleted domain names. The requests are being repeated and fired off every few milliseconds. One individual has over 50,000 templates in the system as we speak. We believe that by requiring an identity to download the zone files we will better protect the community. Note that this ftp policy has not yet gone into effect. Lastly, it appears irresponsible to fan the flames of "the internic is trying to get over" via lists like these. How about giving us the benefit of the doubt? We generally stay silent on these issues, but feel that it is important to explain what we are doing and why. No, we are not trying to take over the net. Sorry for the confusion. David H. Holtzman Senior VP Engineering, NSI dholtz(a)internic.net

3 2

FW: genieweb.com answering for COM
by Rodney Joffe 03 Jul '97

03 Jul '97

This has been corrected temporarily. With brute force ;-) Genieweb is a downstream customer of Los Nettos, one of our customers. No-one has been able to reach the company or the contact, so their T1 was just taken down. I expect a call rather soon, so we can get them to fix their mistake. But it does bring up an interesting point.... is it that easy to create chaos? They are so far down the food chain, and yet.... Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: seanl(a)literati.org [SMTP:seanl@literati.org] > Sent: Thursday, July 03, 1997 9:59 AM > To: nanog(a)merit.edu > Subject: genieweb.com answering for COM > > com. 304 SOA genieweb.com. root.genieweb.com. ( > 11 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > 604800 ; expire (7 days) > > This was cached on one our name servers. Sure enough, dig any com > @genieweb.com shows: > > ;; ANSWERS: > com. 86400 SOA genieweb.com. root.genieweb.com. ( > 11 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > 604800 ; expire (7 days) > 86400 ) ; minimum (1 day) > com. 86400 NS genieweb.com. > > ;; AUTHORITY RECORDS: > com. 86400 NS genieweb.com. > > ;; ADDITIONAL RECORDS: > genieweb.com. 86400 A 198.147.97.23 > > I wonder if this is what has been causing random COM domain lookups to > fail for random people at random places. > > The time I can see this affecting a name server is if it does a lookup > for a domain that's lamely delegated to genieweb.com, and then caches > the 'com' reply. > > I've already left voicemail for the genieweb people. > > > -- > Sean R. Lynch <seanl(a)literati.org>

2 1