- NANOG - lists.nanog.org

Re: whois broke again?
by Danny McPherson 20 Feb '00

20 Feb '00

> While it would probably not be an accurate assessment, it could be assumed > that they are doing nothing at all to fix problems ever; how would we > know? Considering that we (as in ISP's) are the primary source of thier > income, don't they owe this information to us, at least in a watered-down > version? Absolutely, unless assumming "us" == NANOG. But that's between each NSI customer and NSI, not NANOG and NSI. And as an NSI customer, once escalated to this level, it's something that I'd address directly and formally with those NSI folks, the ones that have that ve$ted interest in the success of NSI. I assure you that if you're able to demonstrate that all reasonable steps have been taken to follow the formal trouble reporting process, but to no avail, they'll be interested. and if not, well, sufficient documentation would then be in place to more formally address the problem. -danny

3 2

Re: whois broke again?
by Danny McPherson 20 Feb '00

20 Feb '00

> A) Do you happen to have proof that people *arent* reporting the > problems to NSI as well as posting here? I'd guess he doesn't, though yet another glean of the entire thread also doesn't reveal anything suggesting that an attempt to contact, or even a simple cc NSI has occurred to this point. Perhaps denoting a failed attempt in the initial post would have made sense. I assure you that the NSI folks are indeed concerned with the accuracy and availability of the services they provide, especially considering they've a ve$ted interest in the integrity of their services, as somewhat mis-representedly pointed out a few messages back. Assuredly, the folks that have the most at stake to this regard are also the most concerned with their performance, and are the ones in a position to make things happen. However, while NANOG posts are amazingly very far-reaching, I doubt these folks read NANOG directly, and I especially doubt they'll be posting here any time soon. Given, seemingly with every service-oriented provider on the Internet, they have their share of problems, but, as with most service providers, they must be made aware of the problem(s) before they can correct them .. and IMO, NANOG isn't the appropriate _initial step towards making folks aware of a problem. I'd also guess that the solution(s) to these problems reside a bit beyond a spare server and a couple of hours, though I'd not be overly surprised if the solution was trivial. > B) Considering how important NSI has been to keeping the net > going, I'm surprised we haven't seen a CNN soundbite of Wolf Blitzer > standing in front of NSI's corporate headquarters, talking about > NSI executives preparing to explain to a Congressional subcommittee > exactly why there are so many problems... Between this and VoIP, I'm sure someone will be testifying soon :-) > A few days ago a total of 13 sites got DOS'ed, for an average of > a few hours each, and that got MAJOR press coverage. It's surprising > there wasn't a similar fuss the time that 30% of the .com's were > dropped on the floor due to a undetected disk-full condition, and > sites were having sporadic problems for several DAYS till all the DNS > caches timed out, or the time a few days later there was ANOTHER > problem, or the time..... > > Let's face it guys, taken on the "number of sites times outage time" > basis, NSI operational issues have screwed a *LOT* more of the 4 > million .COM's out there than trin00 has.... Though far less visible, and less interesting to the folks looking for a story. -danny

2 1

RE: Funk *that* (was Re: whois broke again?)
by Leonard, Jason M. 20 Feb '00

20 Feb '00

Understood, that's why I'm looking for input. I'd like to come up with a reliable system, even though it's necessarily going to be a hair or two behind the 'live' databases. -----Original Message----- From: Valdis.Kletnieks(a)vt.edu To: Leonard, Jason M. Cc: 'nanog(a)merit.edu' Sent: 2/20/00 1:41 AM Subject: Re: Funk *that* (was Re: whois broke again?) On Sun, 20 Feb 2000 01:32:35 EST, "Leonard, Jason M." <Jason.Leonard(a)wcom.net> said: > How hard could it be to maintain a mirror or something close to a mirror? > I'm willing to donate a box and a few hours a week. Email me off list with > your input and I'll post the results. A mirror would help if the primary server was unreachable. The problem being reported NOW is the spewage of data that claims to be correct. Unless you run your mirror in a "pull, wait 8 hours for verification, and THEN commit" mode, the mirror will be spewing the same broken data. Valdis Kletnieks Operating Systems Analyst Virginia Tech

1 0

Re: whois broke again?
by Bohdan Tashchuk 20 Feb '00

20 Feb '00

> Whats amazing to me is that there is not one peep from NSI about this, no > news service picked up on it, and it will go unnoticed, in general. > Isn't it amazing that a company as significant on the 'net as NSI can have > such repetitive, continual database problems, and no one cares? It's even worse than that. NSI just sold approx $500 million of new stock. SAIC just sold $1.6 billion of their stock in NSI. If the market continually rewards NSI so richly despite continuing problems, why should they get better? Why should they care about little things like broken databases? After all, it could conceivably cost them upwards of 1% of their newly acquired cash to fix the problems. There is an operational point in the above and here it is: There is no incentive at all for NSI to do any better. They don't care. They don't have to. They're a rich monopoly. Maybe they will improve, and maybe they won't. In the meantime, the members of NANOG have to keep the Net working in spite of NSI foulups. Figure out how to live with NSI or figure out how to work around NSI. But don't bitch about NSI in this forum because it won't do any good. The sooner everyone accepts this reality, the better off everyone will be. That's the bottom line, plain and simple.

1 0

NSI/Whois broke, for the 2093802nd time
by Alex Rubenstein 19 Feb '00

19 Feb '00

[root@netflow local]# whois -h whois.networksolutions.com nac.net The Data in Network Solutions' WHOIS database is provided by Network Solutions for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. Network Solutions does not guarantee its accuracy. By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems). Network Solutions reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. [No name] (MM2425 ) ORG [root@netflow local]# whois -h whois.networksolutions.com yahoo.com The Data in Network Solutions' WHOIS database is provided by Network Solutions for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. Network Solutions does not guarantee its accuracy. By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to Network Solutions (or its systems). Network Solutions reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. [No name] (ID?) Is it really that hard to operate a domain registry!? They've only been doing it for about 10 years..

2 1

Re: Divergence Between NSI And Registry Database
by bmanning＠vacation.karoshi.com 19 Feb '00

19 Feb '00

GTEi has been revamping/consolidating its DNS servers from the M&A activity over the past decade. I recevied a notice to this effect and responded that I had dropped their service in favor of other slaves. They continue to insist that they will be turning in changes to reflect their new servers. I'm watching my zones to ensure that GTEi does not relink their servers to my zones. I really don't want that service from them. -------------------------------------------- > > > This is the second time in one week where I have seen this occur. We > called NSI and corrected the last one and I believe the quote from our > contact was "I've never seen this happen before." Well now I have seen it > twice. > > Domain Name: doers.org > > 1) First a query off NSI reveals: > > Registrant: > INTELLIGENT COMM CO (DOERS-DOM) > 5206 MARKEL RD STE 102 > RICHMOND, VA 23230-3044 > US > > Domain Name: DOERS.ORG > > Administrative Contact: > Bird II, Lloyd C (LCB33) lbird(a)URO.COM > 804-282-7600 (FAX) 804-288-3529 > Technical Contact, Zone Contact: > Cavalier Telephone LLC Network Operations Center (CT1242-ORG) > noc(a)CAVTEL.NET > 804-422-4000 > Fax- 804-422-4392 > Billing Contact: > Bird II, Lloyd C (LCB33) lbird(a)URO.COM > 804-282-7600 (FAX) 804-288-3529 > > Record last updated on 12-Feb-2000. > Record created on 28-Apr-1997. > Database last updated on 18-Feb-2000 12:56:46 EST. > > Domain servers in listed order: > > DNS01.CAVTEL.NET 205.160.16.10 > DNS02.CAVTEL.NET 205.160.17.10 > > This query shows the correct way, the way we requested. > > 2) This is a query off the registry, revealing: > > [rs.internic.net] > > Whois Server Version 1.1 > > Domain names in the .com, .net, and .org domains can now be registered > with many different competing registrars. Go to http://www.internic.net > for detailed information. > > Domain Name: DOERS.ORG > Registrar: NETWORK SOLUTIONS, INC. > Whois Server: whois.networksolutions.com > Referral URL: www.networksolutions.com > Name Server: DNSAUTH3.SYS.GTEI.NET > Name Server: DNS01.CAVTEL.NET > Name Server: DNS02.CAVTEL.NET > Updated Date: 12-feb-2000 > > As you can see there is an extraneous nameserver listed at the top, which > is not making life happy for the customer. Any ideas? As you can see this > not a matter of time, as the nameserver change occured on Feb-12-2000. Is > anyone else seeing this? > > ---- > Justin M. Wilson > justin(a)justin.net > justin(a)cavtel.net > justin.wilson(a)vcu.edu > >

1 0

interesting breakdown .
by John R. Sosebee 19 Feb '00

19 Feb '00

http://socrates.berkeley.edu/~zook/domain_names/ Overview of Current Geography of Domains As of January 2000 there were 10,008,475 com, org, net and edu domains registered worldwide. There are another 3,344,305 country code TLDs (.uk or .de) domains registered as well. That's about 2.2 Intenet domains per 1000 people worldwide. In the US, the figure is 25.2 domains per 1000 people. CONCENTRATIONS OF DOMAIN NAMES Combined (com, org, net, edu and country code TLDs) there are 13.35 million domains. They are distributed as follows. The US has 50.0 percent California has 11.5 percent Los Angeles (CMSA) has 5.6 percent San Francisco (CMSA) has 3.9 percent New York State has 4.3 percent New York (CMSA includes NJ and CT) has 5.9 percent Germany has 8.6 percent The UK has 8.5 percent John sosebee(a)bellsouth.net Network Engineering (770) 522-4000

2 1

The Cidr Report
by Tony Bates 18 Feb '00

18 Feb '00

This is an auto-generated mail on Fri Feb 18 12:00:01 PST 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 18Feb00 0) General Status Table History ------------- Date Prefixes 110200 71788 120200 71855 130200 71752 140200 71950 150200 73959 160200 72163 170200 72085 180200 72321 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6713 Number of ASes announcing only one prefix: 3650 (1988 cidr, 1662 classful) Largest number of cidr routes: 766 announced by AS701 Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 18Feb00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 154 283 64.8% BCnet Backbone AS7046 453 293 160 35.3% UUNET-CUSTOMER AS1221 658 522 136 20.7% TELSTRA-AS AS9269 147 24 123 83.7% Hong Kong CTI AS9706 147 30 117 79.6% Pusan Metropolitan City Office of AS2609 123 22 101 82.1% EUnet-TN AS7657 282 183 99 35.1% The Internet Group Limited AS4293 273 176 97 35.5% Internal ASN for C&W AS7545 153 60 93 60.8% TPG Internet Pty Ltd AS2715 153 61 92 60.1% REDERIO-AS AS6429 205 118 87 42.4% RDC-INTERNET AS7496 122 39 83 68.0% Power Up AS174 557 474 83 14.9% Performance Systems International AS705 297 216 81 27.3% ALTERNET-AS AS816 392 314 78 19.9% UUNET Canada (ASN-UUNETCA-AS4) AS3749 137 61 76 55.5% TECNET AS9304 99 24 75 75.8% Hutchcity AS577 246 173 73 29.7% Bell Backbone AS3602 325 252 73 22.5% Sprint Canada Inc. AS4200 168 105 63 37.5% AGIS (Apex Global Information Ser AS7029 111 50 61 55.0% ALLTELNET AS4740 338 280 58 17.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS7260 103 46 57 55.3% NORLIGHT AS1727 134 79 55 41.0% MRMS-WEST AS209 384 333 51 13.3% Qwest Communications AS4151 100 50 50 50.0% USDA Internet Access Network AS701 1002 956 46 4.6% Alternet AS9557 66 21 45 68.2% Pakistan Telecommunication Compan AS2652 126 81 45 35.7% Government of Canada Telecommunic AS7568 60 16 44 73.3% C.S. Communications Co., Ltd. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

private RFC-1918 addresses on public routers
by William Allen Simpson 18 Feb '00

18 Feb '00

Usually, when a "private" address hits the bogon filters, a quiet note to the perpetrator gets the problem fixed promptly. This time, the fellow seems to want to argue. Since he's been on this list for awhile (posted here about 8 months ago), perhaps he's educable. His characterization isn't what I remember from the previous discussion(s). Moreover, with the recent emphasis on filtering bogus source addresses, maybe it's time to take a stronger stand on the practice. The facts: - a not-insignificant regional public backbone. - a private class B (172.19) on public backbone router interfaces, contrary to the guidelines in RFC-1918 (p 3). - a congested link that generates a significant number of ICMP messages. - the private source address is not being properly filtered by the ISP from reaching the public network, as required (RFC-1918 p 5). - upstream links with non-maintained (missing) in-addr entries. - traceroute downstream, after this private address, on the way to a medium-sized university, disappears into a black hole, although the university itself is certainly not in private address space. While not of earth-shaking consequence, it clearly isn't helpful for debugging the network. What kind of actions should we take? Complain to a supervisor? Construct a web page of infamy? #(name removed to protect the guilty) # I have followed and participated in several of the lively NANOG discussions. # As I recall the usual conclusion on NANOG is - let's agree to disagree. That # seems to me to leave it open to interpretation on whether this practice is # good - it saves public IP space, or bad - you can see it on a traceroute. # # I am aware of the MTU problem but how does it break ICMP? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

5 5

Re: Robustness principle considered harmful
by Forrest W. Christian 18 Feb '00

18 Feb '00

On Fri, 18 Feb 2000, Jon Ribbens wrote: > Not a particularly good rule anyway, if you ask me. (Which you didn't.) > > It should be "be conservative in what you send, and conservative in what > you accept". Actually, my REAL opinion on this (based on several years of process control - which MUST be reliable lest someone get killed) is this: "Be conservative in what you send, and don't be surprised if someone else sends you something you don't expect, and be prepared to deal with it". or, in the process control world: "Be very consistent (safe) in what you do, even when presented with bogus data." I think that was really the intent of the robustness principle. But lest we get in to an argument and reduce the S/N ratio of nanog (if that is possible)... The real point of my message was this: Using RFC1918 space in a net-visible manner is being liberal in what you send and being liberal in what you send is not a good idea. ESPECIALLY when people are being conservative in what they accept. Off-topic note: It seemed like every chuck of process control code I wrote ended up being something like "If it fails this way do this, if it fails this other way, do this, if it fails in yet another bizzare way, do this, and, if by chance it actually worked, do this." 90% of the code was dealing with failure modes. From my experience CGI scripting/network programming tends to be about the same. - Forrest W. Christian (forrestc(a)imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

1 0