- Test - lists.nanog.org

Re: Question about strain on the A root server
by Andrew Brown 23 Apr '00

23 Apr '00

>> binfo.c = Bind Version Checker >> 'binfo' is a quick little script to pull back the version >> of named running on a remote nameserver. This is handy >> for >> comparing it to a list of known vulnerable versions of >> named/bind. Previous to this, it took a few commands to >> extract out the version. > >It seems to have been written more of not as a DNS admin convenience, >but more as for inclusion into rootkit type packages, IMO. perhaps, but it's certainly (a) not malicious or (b) gonna swamp the root servers. >A few commands? More like one :) > >$ nslookup -q=txt -class=chaos version.bind <nameserver> or dig version.bind chaos txt @nameserver :) >And here's how to disable giving out that information to untrusted hosts >or networks: > >in named.conf, set up something like this (*NOT* in the options section): >... >Now, create a file called 'chaos' (in same directory where your zone >files lives) with something like: >... been there, done that. and it's interesting to see all the people who are checking out your name server after their addresses get logged for hitting the acl. -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" andrew(a)crossbar.com * "information is power -- share the wealth."

1 0

name servers
by Dana Hudes 23 Apr '00

23 Apr '00

I have a name server for the few domains I host and my little local LAN. with reverse DNS lookup on for incoming e-mail and for web server logging, it does a fair bit of ns queries. I considered making it forward to concentric (my DSL ISP) name server but the result would be degraded performance of my network (or possibly no improvement over concentric, depending on which root is queried): PING hudson.concentric.net (207.155.183.72): 56 data bytes 64 bytes from hudson.concentric.net (207.155.183.72): seq=0 ttl=247 time=85.1 ms . 64 bytes from hudson.concentric.net (207.155.183.72): seq=1 ttl=247 time=85.9 ms . 64 bytes from hudson.concentric.net (207.155.183.72): seq=2 ttl=247 time=86.3 ms . ---- hudson.concentric.net (207.155.183.72) PING Statistics ---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 85.1/85.8/86.3 (std = 0.475) PING a.root-servers.net (198.41.0.4): 56 data bytes 64 bytes from a.root-servers.net (198.41.0.4): seq=0 ttl=249 time=28.9 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=1 ttl=249 time=19.2 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=2 ttl=249 time=18.0 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=3 ttl=249 time=48.6 ms. PING b.root-servers.net (128.9.0.107): 56 data bytes 64 bytes from b.root-servers.net (128.9.0.107): seq=0 ttl=248 time=73.1 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=1 ttl=248 time=72.5 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=2 ttl=248 time=73.7 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=3 ttl=248 time=73.3 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=4 ttl=248 time=76.9 ms. ò ---- b.root-servers.net (128.9.0.107) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 72.5/73.9/76.9 (std = 1.54) PING c.root-servers.net (192.33.4.12): 56 data bytes 64 bytes from c.root-servers.net (192.33.4.12): seq=0 ttl=247 time=23.4 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=1 ttl=247 time=20.8 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=2 ttl=247 time=22.7 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=3 ttl=247 time=20.2 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=4 ttl=247 time=20.6 ms. ò ---- c.root-servers.net (192.33.4.12) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 20.2/21.5/23.4 (std = 1.25) PING d.root-servers.net (128.8.10.90): 56 data bytes 64 bytes from d.root-servers.net (128.8.10.90): seq=0 ttl=246 time=91.7 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=1 ttl=246 time=109 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=2 ttl=246 time=109 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=3 ttl=246 time=111 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=4 ttl=246 time=99.6 ms. ò ---- d.root-servers.net (128.8.10.90) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 91.7/104/111 (std = 7.34) PING E.ROOT-SERVERS.NET (192.203.230.10): 56 data bytes 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=0 ttl=56 time=75.1 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=1 ttl=56 time=78.3 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=2 ttl=56 time=75.0 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=3 ttl=56 time=75.9 ms. ò ---- E.ROOT-SERVERS.NET (192.203.230.10) PING Statistics ---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 75.0/76.0/78.3 (std = 1.35) Clearly BTW I'm not getting what I'm paying for (1.1Mb SDSL via Covad) from Concentric. 85ms is ridiculously bad to a name server.

2 1

Question about strain on the A root server
by Nick Patience 23 Apr '00

23 Apr '00

Hi all, Disclosure: I'm a journalist with a company called the451.com (details in sig file). Anyhow, that said, I was talking to Network Solutions about their decision to swap out the Sun box that is the A root server and change it for a more powerful RS/6000 S80. Also it is using IBM servers for its new network of name servers - it has already deployed 8 of the intended 12 according to the company, including one brought on stream two days ago in Hong Kong. As most on this list probably already know, it is separating the root servers from the name servers. Anyhow, NSI claims that the strain on the A root server has jumped from 220 million 'hits' to 420 million during Q1 alone. I haven't managed to define what hit is yet but intend to at some point. NSI seems slightly unsure as to the main reason for the increase in hits, but speculates that one of the reasons may be says the main reason for this is that ISP's are using different caching techniques and more & more searches are going right to the top of the tree than before. What do people on this list feel about this as a reason? It seems a little woolly to me. Cheers, Nick -- Nick Patience Internet Editor & NY Dep. Bureau Chief the451.com | wap.the451.com T: 212 460 7131 M: 917 312 5712 F: 413 826 8217 nick.patience(a)the451.com

8 9

Win, win...
by Dennis Targa 23 Apr '00

23 Apr '00

*Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:perr89@populus.net?subject=more_info ////////////////////////////////////////////////////////////////// If you would like to be removed from our list reply to: mailto:vvxx76@yahoo.com?subject=remove //////////////////////////////////////////////////////////////////

1 0

Anyone encountered Cisco ATM PVC large delay bug?
by Yu Ning 23 Apr '00

23 Apr '00

Hi nanog, I'm not sure how many percentage of global NSP/ISP use ATM PVC to provide links between their Cisco routers. It seems there is some large delay bugs in Cisco ATM interface, esp on GSR level routers. In more detail, our situation is: if we get a high bandwidth PVC, say 51M(or 80M), and if the bandwidth utilization reaches 80% percent, the ATM link will encounter a 1500~2000 ms delay - just point to point ping across the link. We have found this situation is associated with "sar txpool" setting in Cisco GSR, and a manipulation of the "sar txpool" together with bandwidth increasing has solved the problem now. But I still wonder if any of you ever encounter this situation(bug), and how did you overcome it? If you are still puzzled by this bug, I'd like share our temp solution with you. regards, Yu Ning ------------------------------------------- (Mr.) Yu Ning ChinaNet Backbone Operation Networking Dep.,Datacom Bureau China Telecom.,Beijing(100088),P.R.C +86-10-66418121/66418122/66418123(fax) -------------------------------------------

3 3

April 2000 COVAD dsl problems
by Sean Donelan 22 Apr '00

22 Apr '00

I've received a report that COVAD had several switch problems affecting their DSL service across the country dating back to April 5. At least three multi-hour outages have happened. I tried contacting COVAD, but was directed to call my local ISP. Mail to noc(a)covad.net bounced as undeliverable. Is anyone aware what is happening. Is it a switch problem, operation, or something else.

4 3

Network Solutions
by Stewart Gott 22 Apr '00

22 Apr '00

I've been silently reading the posts about Network Solutions, and boy! I cannot agree more. I deal with a lot of Vendor Tech Support and Network Solutions Tech Support is in a class by itself (the absolute worst I have ever dealt with)! Their incompetency knows no bounds! It is scary! Their attitude seems to be if you fill out the on-line or email form to the computer's satisfaction, and the computer accepts and processes it, fine, otherwise they have absolutely no clue how to help you, how to change anything, how to update anything, it really is pathetic! Stewart Gott Network Manager None of us will be free until nerd persecution ends!

3 2

RE: New Federal Law (COPPA)
by Robert Cannon 22 Apr '00

22 Apr '00

The law in question is the Child Online Privacy Protection Act, passed in 1998. Today, (Friday April 21) FTC rules implementing the new law take effect. You may be interested in the following information: FTC's How to Comply with COPPA http://www.ftc.gov/bcp/conline/pubs/buspubs/coppa.htm FTC's Privacy website http://www.ftc.gov/privacy/index.html According to the FTC guide, the following people must comply and thus will want to learn more about this: QUOTE If you operate a commercial Web site or an online service directed to children under 13 that collects personal information from children or if you operate a general audience Web site and have actual knowledge that it collects personal information from children, you must comply with the Children's Online Privacy Protection Act. * To determine whether a Web site is directed to children, the FTC will consider several factors, including the subject matter; visual or audio content; the age of models on the site; language; whether advertising on the Web site is directed to children; information regarding the age of the actual or intended audience; and whether a site uses animated characters or other child-oriented features. * To determine whether an entity is an "operator" with respect to information collected at a site, the FTC will consider who owns and controls the information; who pays for the collection and maintenance of the information; what the pre-existing contractual relationships are in connection with the information; and what role the Web site plays in collecting or maintaining the information. END QUOTE -Robert Cannon Internet Telecom Project www.cybertelecom.org ------Original Message------ From: "Moe Allen" <moe(a)vidnet.net> To: <nanog(a)merit.edu> Sent: April 21, 2000 7:10:50 PM GMT Subject: New Federal Law The Federal Government just announced a new Law that goes into effect today. ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

6 6

Re: Re: Re: New Federal Law (COPPA)
by Shawn McMahon 22 Apr '00

22 Apr '00

On Fri, 21 Apr 2000, "John A. Tamplin" wrote: > > > Need their email address for password verification? Sorry. > > Did you even read any of it first? It specifically exempts reponding > to one-time requests from requiring parental consent. I presume you > don't need to verify the address more than once. > You're being obtuse. Fine, if you're one of those people who can't comprehend hypotheticals, I'll give you concrete examples: Mailing lists. Slashdot. TV Guide. Those are examples of sites that must preserve information in order to provide their services.

1 0

Metro subway fire in Washington DC fiber repair delayed until Sunday
by Sean Donelan 22 Apr '00

22 Apr '00

The fire in the Metro subway line in Washington DC damaged some fiber. Due to the hazardous conditions, safety officials will not allow fiber repair crews access to the area until, at the earliest, Sunday. It appears most traffic is re-routed around the damage sections, but some unusual routing and increased latency is possible.

1 0