- NANOG - lists.nanog.org

RE: [nanog]: cisco site down?
by Tomas Daniska 06 Oct '03

06 Oct '03

the same here -- deejay > -----Original Message----- > From: Ezequiel Carson [mailto:ezequiel@ifxnw.com.ar] > Sent: 6. októbra 2003 17:23 > To: nanog(a)merit.edu > Subject: [nanog]: cisco site down? > > > hi, > can anyone use cisco site? > > > [root@localhost root]# telnet www.cisco.com 80 > Trying 198.133.219.25... > Connected to www.cisco.com. > Escape character is '^]'. > Connection closed by foreign host. > [root@localhost root]# > > ezequiel. > > >

2 1

Re: Security v. Privacy (was Re: Is there anything that actuallygets users to fix their computers?)
by Sean Donelan 06 Oct '03

06 Oct '03

On Sun, 5 Oct 2003, Jamie Reid wrote: > While we were fighting blaster/nachi and others, we relied heavily on > IDS's to generate alerts for the worms, then we disabled their network > access and called them. Generic viruses are not an ISP's problem, but > a worm is something that affects the prviders infrastructure, and is > therefore a network operators business. Did the users actually believe you when you told them their computer had a worm? How many times did you disable the same user's network access because they didn't actually fix their computer but told you it was fixed? But I have a really important document that has to be sent right now, and I can't wait to fix the computer.

2 3

Reverse DNS problem
by Schmiedt, Jamie 06 Oct '03

06 Oct '03

We have been experiencing problems with reverse DNS requests since Thursday 10/2/2003. Just wondering if anyone else is seeing this issue? This is affecting freeBSD & Linux hosts with Bind version 8.2.3 & 8.3.3. Reverse Lookups fail as follows: host0001$ nslookup Default Server: host0001.domain123.net Address: 0.0.0.0 > ccn.com Server: host0001.domain123.net Address: 0.0.0.0 Name: ccn.com Address: 63.172.52.127 > 63.172.52.127 Server: host0001.domain123.net Address: 0.0.0.0 *** Request to host0001.domain123.net timed-out > tcpdump shows this: 16:32:21.864111 123.123.123.123.1024 > 192.12.94.30.53: 6333 A? chia.ARIN.NET. (31) 16:32:21.864298 123.123.123.123.1024 > 192.12.94.30.53: 48444 A? dill.ARIN.NET. (31) 16:32:21.864597 123.123.123.123.1024 > 192.12.94.30.53: 43887 A? henna.ARIN.NET. (32) 16:32:21.864754 123.123.123.123.1024 > 192.12.94.30.53: 13510 A? indigo.ARIN.NET. (33) 16:32:21.864910 123.123.123.123.1024 > 192.12.94.30.53: 6129 A? epazote.ARIN.NET. (34) 16:32:21.865067 123.123.123.123.1024 > 192.12.94.30.53: 61408 A? figwort.ARIN.NET. (34) 16:32:21.865222 123.123.123.123.1024 > 192.12.94.30.53: 38595 A? ginseng.ARIN.NET. (34) 16:32:21.865383 123.123.123.123.1024 > 192.36.148.17.53: 60682 PTR? 127.52.172.63.in-addr.arpa. (46) 16:32:21.932444 192.12.94.30.53 > 123.123.123.123.1024: 48444- 0/7/7 (271) (DF) 16:32:21.941921 192.12.94.30.53 > 123.123.123.123.1024: 6333- 0/7/7 (271) (DF) 16:32:21.951550 192.12.94.30.53 > 123.123.123.123.1024: 43887- 0/7/7 (272) (DF) 16:32:21.961288 192.12.94.30.53 > 123.123.123.123.1024: 13510- 0/7/7 (273) (DF) 16:32:21.970903 192.12.94.30.53 > 123.123.123.123.1024: 6129- 0/7/7 (274) (DF) 16:32:21.980540 192.12.94.30.53 > 123.123.123.123.1024: 61408- 0/7/7 (274) (DF) 16:32:21.990282 192.12.94.30.53 > 123.123.123.123.1024: 38595- 0/7/7 (274) (DF) 16:32:22.016671 192.36.148.17.53 > 123.123.123.123.1024: 60682- 0/7/0 (199) (DF) 16:32:22.017854 123.123.123.123.1024 > 192.54.112.30.53: 46181 A? chia.ARIN.NET. (31) 16:32:22.017883 123.123.123.123.1024 > 192.54.112.30.53: 28356 A? dill.ARIN.NET. (31) 16:32:22.017907 123.123.123.123.1024 > 192.54.112.30.53: 29015 A? henna.ARIN.NET. (32) 16:32:22.017932 123.123.123.123.1024 > 192.54.112.30.53: 39822 A? indigo.ARIN.NET. (33) 16:32:22.017958 123.123.123.123.1024 > 192.54.112.30.53: 25113 A? epazote.ARIN.NET. (34) 16:32:22.017984 123.123.123.123.1024 > 192.54.112.30.53: 7656 A? figwort.ARIN.NET. (34) 16:32:22.018008 123.123.123.123.1024 > 192.54.112.30.53: 53035 A? ginseng.ARIN.NET. (34) 16:32:22.142472 192.54.112.30.53 > 123.123.123.123.1024: 28356- 0/7/7 (271) (DF) 16:32:22.151936 192.54.112.30.53 > 123.123.123.123.1024: 46181- 0/7/7 (271) (DF) 16:32:22.161553 192.54.112.30.53 > 123.123.123.123.1024: 39822- 0/7/7 (273) (DF) 16:32:22.171199 192.54.112.30.53 > 123.123.123.123.1024: 29015- 0/7/7 (272) (DF) 16:32:22.180924 192.54.112.30.53 > 123.123.123.123.1024: 25113- 0/7/7 (274) (DF) 16:32:22.190561 192.54.112.30.53 > 123.123.123.123.1024: 53035- 0/7/7 (274) (DF) 16:32:22.200290 192.54.112.30.53 > 123.123.123.123.1024: 7656- 0/7/7 (274) (DF) 16:32:26.868123 123.123.123.123.1024 > 192.41.162.30.53: 32457 A? chia.ARIN.NET. (31) 16:32:26.868300 123.123.123.123.1024 > 192.41.162.30.53: 65240 A? dill.ARIN.NET. (31) 16:32:26.868452 123.123.123.123.1024 > 192.41.162.30.53: 15332 A? henna.ARIN.NET. (32) 16:32:26.868602 123.123.123.123.1024 > 192.41.162.30.53: 41975 A? indigo.ARIN.NET. (33) 16:32:26.868753 123.123.123.123.1024 > 192.41.162.30.53: 21934 A? epazote.ARIN.NET. (34) 16:32:26.868905 123.123.123.123.1024 > 192.41.162.30.53: 56761 A? figwort.ARIN.NET. (34) 16:32:26.869057 123.123.123.123.1024 > 192.41.162.30.53: 52488 A? ginseng.ARIN.NET. (34) 16:32:26.869208 123.123.123.123.1024 > 198.41.0.4.53: 64459 PTR? 127.52.172.63.in-addr.arpa. (46) 16:32:26.923374 192.41.162.30.53 > 123.123.123.123.1024: 32457- 0/7/7 (271) (DF) 16:32:26.930326 198.41.0.4.53 > 123.123.123.123.1024: 64459- 0/7/0 (199) 16:32:26.931103 123.123.123.123.1024 > 192.52.178.30.53: 45170 A? chia.ARIN.NET. (31) 16:32:26.939982 192.41.162.30.53 > 123.123.123.123.1024: 15332- 0/7/7 (272) (DF) 16:32:26.949578 192.41.162.30.53 > 123.123.123.123.1024: 65240- 0/7/7 (271) (DF) 16:32:26.959220 192.41.162.30.53 > 123.123.123.123.1024: 41975- 0/7/7 (273) (DF) 16:32:26.968842 192.41.162.30.53 > 123.123.123.123.1024: 21934- 0/7/7 (274) (DF) 16:32:26.978581 192.41.162.30.53 > 123.123.123.123.1024: 56761- 0/7/7 (274) (DF) 16:32:26.988220 192.41.162.30.53 > 123.123.123.123.1024: 52488- 0/7/7 (274) (DF) 16:32:27.058851 192.52.178.30.53 > 123.123.123.123.1024: 45170- 0/7/7 (271) (DF) We can temporarily resolve the problem by issuing the following dig command: dig @<any ARIN in-addr.arpa server; ginseng, fogwort, etc.> -x <any sequence> example: host0001# dig @ginseng.arin.net -x abc Then the reverse lookups being to work and the tcpdump is as follows: (notice the difference in lines 8,9,10,11) 16:33:01.664320 123.123.123.123.1024 > 192.35.51.32.53: 33751 A? chia.ARIN.NET. (31) 16:33:01.664460 123.123.123.123.1024 > 192.35.51.32.53: 11278 A? dill.ARIN.NET. (31) 16:33:01.664573 123.123.123.123.1024 > 192.35.51.32.53: 55449 A? henna.ARIN.NET. (32) 16:33:01.664684 123.123.123.123.1024 > 192.35.51.32.53: 49768 A? indigo.ARIN.NET. (33) 16:33:01.664797 123.123.123.123.1024 > 192.35.51.32.53: 18859 A? epazote.ARIN.NET. (34) 16:33:01.664909 123.123.123.123.1024 > 192.35.51.32.53: 40146 A? figwort.ARIN.NET. (34) 16:33:01.665002 123.123.123.123.1024 > 192.33.14.32.53: 62349 PTR? 127.52.172.63.in-addr.arpa. (46) 16:33:01.725238 192.35.51.32.53 > 123.123.123.123.1024: 33751*- 1/8/8 A 192.5.6.32 (320) (DF) 16:33:01.736288 192.35.51.32.53 > 123.123.123.123.1024: 11278*- 1/8/8 A 192.35.51.32 (320) (DF) 16:33:01.747452 192.35.51.32.53 > 123.123.123.123.1024: 55449*- 1/8/8 A 192.26.92.32 (321) (DF) 16:33:01.758663 192.35.51.32.53 > 123.123.123.123.1024: 49768*- 1/8/8 A 192.31.80.32 (322) (DF) 16:33:01.765379 192.33.14.32.53 > 123.123.123.123.1024: 62349- 0/3/0 (134) (DF) 16:33:01.765834 123.123.123.123.1024 > 199.191.128.105.53: 19916 PTR? 127.52.172.63.in-addr.arpa. (46) 16:33:01.776697 192.35.51.32.53 > 123.123.123.123.1024: 18859*- 1/8/8 A 192.41.162.32 (323) (DF) 16:33:01.787806 192.35.51.32.53 > 123.123.123.123.1024: 40146*- 1/8/8 A 192.42.93.32 (323) (DF) 16:33:01.794121 199.191.128.105.53 > 123.123.123.123.1024: 19916*- 1/2/2 (171) (DF) Restarting named does not help. These host are located on several different ISP networks. Forward lookups function properly. Stumped... Any help or suggestions would be greatly appreciated. Thanks. -jamie

1 0

Removal of wildcard A records from .com and .net zones
by Matt Larson 06 Oct '03

06 Oct '03

VeriSign was directed by ICANN to suspend the Site Finder service by 0100 UTC on Sunday, October 5. We requested an extension from ICANN to give more notice to the community but were denied. We will be removing the wildcard A records from the .com and .net zones beginning at 2300 UTC on Saturday, October 4. The former behavior for these zones (returning Name Error/RCODE=3 in response to queries for nonexistent domain names) will be in place by 0100 UTC on Sunday, October. Matt -- Matt Larson <mlarson(a)verisign.com> VeriSign Naming and Directory Services

14 14

Security v. Privacy (was Re: Is there anything that actuallygets users to fix their computers?)
by Jamie Reid 05 Oct '03

05 Oct '03

While we were fighting blaster/nachi and others, we relied heavily on IDS's to generate alerts for the worms, then we disabled their network access and called them. Generic viruses are not an ISP's problem, but a worm is something that affects the prviders infrastructure, and is therefore a network operators business. Privacy is not an issue in this case as there is a policy being monitored by a policy monitoring tool, and enforced on a per-violation basis. It wasn't a fishing expedition that could assess the users configuration or usage, it was monitoring our network. There is no generalized way, without management access to the customers machine (via SMS or citrix or something), to check that the machine is in compliance with a network policy. An IDS can tell you if it violates policy, and you can act as your security procedures dictate. -- Jamie.Reid, CISSP, jamie.reid(a)mbs.gov.on.ca Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 >>> "Sean Donelan" sean(a)donelan.com> 10/05/03 04:49pm >> [...] So from an ISPs point of view, is there a way for the ISP to quickly tell the customer if the particular computer is fixed without unduly intruding on the privacy of the customer? With home networks, there may be multiple computers behind a NAT/router/firewall. So a simple network scan doesn't always work.

1 0

David McGuire article on Verisign 10/4/2003
by Howard C. Berkowitz 05 Oct '03

05 Oct '03

Let me begin with appropriate disclaimers and identifiers. While in college in 1966-1967, I was a part-time science writer for The Washington Post, so have some familiarity with the news process. At the present time, I am an independent consultant in networking and medical computing, with experience including Internet operational design. With respect to the latter, I have four published books, including one on ISP design: _Building Service Provider Networks_ (Wiley). I am a participant in the Internet Engineering Task Force and North American Network Operators' Group. I have no financial interest in Verisign or its competitors. My concern is first with journalistic balance with respect to sources, and second with technical inaccuracy. The article quotes a Verisign executive, as well as an executive of a firm with a commercial offering similar to Verisign's Sitefinder process. In contrast, the Post cited "the close-knit group of engineers and scientists who are familiar with the technology underpinning the Internet" without naming a single name of an acknowledged expert on the Domain Name System, the Internet function that translates human-oriented names to computer-oriented Internet addresses. It would be simple to find recognized professionals with no financial interest in the type of redirection from Verisign and Paxfire. Balanced reporting should cover both sides of the story. There are a great may individuals and firms that were adversely affected by Verisign's action, and considerable sentiment in the worldwide Internet engineering community that the Verisign action was technically unsound, and in a manner that can be demonstrated objectively, interfered with the normal operations of the Internet. While I wouldn't quite call the article a Verisign press release, I'm appalled either that Mr. McGuire failed to obtain opinion from independent, financially disinterested individuals, or, alternatively, that the editorial staff removed such material. Let me summarize some of the major operational concerns, and not get into the governance issues between Verisign and ICANN. Strong arguments can be made that adding the wildcard (i.e., that which causes any undefined domain to be redirected to Sitefinder) to .com and .net breaks the operational and even protocol aspects of DNS. A great many network security tools, especially spam filters, depend on checking if domains are undefined. There is a specific DNS protocol message for undefined domain, which the wildcard defeats. Beyond security, the wildcards have an indirect effect of potentially slowing electronic mail or causing it to be dropped. One thing that Verisign seemed not to consider is that the Internet is more than the Web, and mail agent redirection to Sitefinder provides absolutely no value to the mail-using Netizen. Here's the problem. Let's say I misaddress a piece of mail to foo.com, which I shall assume is a nonexistent domain. When an ISP first tries to deliver it without the DNS wildcards, when it discovers there is no such domain, it will treat that as an error, usually returning the mail to sender with an appropriate error message. With wildcards, however, an unmodified SMTP agent will get back an address (Sitefinder) and try to set up a SMTP session with it. At best, it will discover that Sitefinder does not support mail exchange and treat the message as undeliverable, again returning it. It's more likely, however, that the SMTP software will decide that since it can find foo.com (with sitefinder's address), a temporary error is interfering with delivery. It will requeue the message for retry. Typically, mail agents try to redeliver for several days, and may or may not return intermediate warning messages. We now have the effects: --ANY mail to an incorrectly spelled name gets added to the outgoing mail queue for retry, increaasing queue length. Doing so: -- slows down mail delivery due to the need for repeatedly processing mail that will never be delivered -- consumes queue storage resources and increases ISP costs, which may be passed on to the end user --Inconveniencing the user, who, if they received a prompt error notification, might discover they spelled an address incorrectly and simply need to correct the message and resend it. With the wildcards, days may elapse before the sender even knows there is a problem. -- Howard C. Berkowitz 5012 25th Street South Arlington VA 22206 (703)998-5819 voice (703)998-5058 fax (alas, sometimes poorly operated by "helpful" cat)

1 0

SANOG III Announcement
by Joe Abley 05 Oct '03

05 Oct '03

> South Asian Network Operators Group (SANOG) III Annoucement > > SANOG III: 15-22 January, 2004, Bangalore, India > > SANOG III will be colocated with the South Asian IPv6 Summit in the > silicon city of India. As in the past, the SANOG program will feature > workshops, tutorials and presentations on operational areas of interest > to the South Asian Internet community. The meeting will be hosted by > IPv6 Forum India. The program structure will be as follows > > 15-18 January, 2004 -- Workshops > 19-20 January, 2004 -- Tutorials > 21-22 January, 2004 -- SANOG Meeting / IPv6 Summit > > We welcome presentations during the Meeting. We would like to hear > about your own experiences and research on making sure the Internet > works the way it is intended to. > > Please write to gaurab at lahai.com with your expression of interest. > More information at www.sanog.org

1 0

Re: Is there anything that actually gets users to fix their computers?
by Mike Nice 05 Oct '03

05 Oct '03

We created a set of RAS filters that we can call up in the user's RADIUS record - Block ICMP request, Block SMTP outgoing, etc. When the user has a virus we just set the filter. They can still get on without doing any damage, yet still download fixes, etc. They might call if they need to use SMTP instead of webmail. > ----- Original Message ----- > > > Short of turning off their network access, why won't users fix > > > their computers when the computer is infected or needs a patch?

1 0

RE: VeriSign Capitulates
by JC Dill 05 Oct '03

05 Oct '03

At 07:17 AM 10/4/2003, St. Clair, James wrote: > I would add that what you perceive as a "diverse group" is still a >realtively small sub-set of all the internet operations. Be that as it may, this group is *anything* but "close knit". This is as unified as I've seen nanog participants on any matter (technical or otherwise) over the years that I've been on nanog. That alone speaks volumes about the "technical community's general opinion" of Verisign's actions in this matter. jc

2 1

Wildcards gone here
by Christopher X. Candreva 05 Oct '03

05 Oct '03

Looks like Verisign has the wildcards out. The following is without any bind patches. [westnet]:~$ date Sat Oct 4 20:46:09 EDT 2003 [westnet]:~$ host www.opensrsS.net Host not found. Whoo Whoo Whoo Whooo ! ========================================================== Chris Candreva -- chris(a)westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/

2 1