- Test - lists.nanog.org

An Open Letter of corrections to Mark McLaughlin's Innovation and the Internet
by Owen DeLong 07 Oct '03

07 Oct '03

While I realize that your Perspectives area is a place where various people are allowed to submit editorials, your publication of this particular very skewed piece without checking some of the stated facts within it does not meet CNet's usual standard of journalism. In addition to Mr. McLaughlin's errors or omissions of fact, he makes a number of misleading statements and outright incorrect implications. As such, I will simply address the article paragraph by paragraph, beginning with the bold paragraph being considered paragraph 1. Paragraph 1: It's not about whether innovation should be encouraged. I think if you were to survey the opponents of Verisign's maneuver, you would find that each and every one of them would say they are in strong support of innovation on the internet. What Verisign did was not innovation. It was a move to line their pockets with significant additional revenue while simultaneously abusing their monopoly position in control of a resource contracted to them to manage in the public trust. They do not OWN the domains that they modified, instead, they are entrusted with the management of said domains (namely .NET and .COM). None of Verisigns competitors is in a position to place wildcard records in these zones, so, Verisign also was abusing it's position of public trust to gain unfair advantage over competitors. Paragraph 2: The error page simply indicates that they URL they typed involved the name of a host which did not exist. Verisign ignored the fact that DNS does not only effect web services. While it is true that some may say that this is an improvement for web browsers, it creates significant problems for other applications. More on this below. Paragraph 3: Site finder is not about improving the user experience. If it were, Verisign would have solicited public input prior to inflicting this change on a critical are of internet infrastructure. Verisign is now launching this PR campaign to try and make ICANN look like the bad guys for finally saying no to Verisign's repeated abuses of their position. Site finder is about profits for Verisign. In fact, substantial profits on the order of Millions of dollars per day. This is why they were so reluctant to take it down in spite of a polite request from ICANN. ICANN had to point out that Verisign was in violation of several clauses of their contract and threaten them with legal action to get them to comply. Paragraph 4: Similar services were tested in a manner which did not break existing infrastructure for non-web oriented applications which were well known on the internet. Verisign didn't do any testing, they simply unleashed this on the two most popular top level domains without review, notice, or even a heads up to the operational community. In fact, the first notification to the NANOG (North American Network Operators Group) mailing list by Verisign came several hours after the debate had already started. Verisign's site finder service didn't trigger debate because they hadn't been tried for .com and .net, it triggered debate because it disrupted services, constituted a change which was not subjected to appropriate public review beforehand, and, represented a cavalier and mistaken attitude by Verisign that these top level domains were theirs to manage however they saw fit. These domains have a long history on the internet, and, they have always been considered a public-trust type of resource. The contract to Verisign to manage these domains clearly calls for Verisign to manage them in the public interest. This was Verisign managing the domain in their own interest, the public be damned. While it is true that during the three weeks it took to get Verisign to fix their abomination, DNS continued to function for most visible levels, the internet continued to route packets, and, most things functioned as before, that does not mean that their change did not break things. As an example, prior to Verisign's change, if I sent an email to user(a)noexist.com intending to send it to user(a)exists.com, I would get an answer back immediately saying "noexist.com" does not exist. After Verisign's change, their mail rejector would either simply drop my mail in a black hole, or, when it was too busy, fail to respond for long periods of time. Either way, since I don't get an error message, I don't know that my mail didn't get through. Another problem comes from anti-spam utilities which depend on being able to determine if a domain name being used in mail exists or not. Verisign rendered it virtually impossible, because, under their proposed system, all domains exist in DNS. They essentially eliminated a vital and useful error message from the internet, instead choosing to make everyone use their error handler. Without going through the IETF and RFC processes, this is an unacceptable move on their part. Of course, IETF would never approve such an action and Verisign knows it. Further, if a domain expired or was accidentally removed, most software is designed to deal with NXDOMAIN responses (the error code returned prior to Verisign's actions) in a manner that allows this to be resolved without serious consequences. With Verisign's change, however, it becomes fatal. Imagine if you are looking for CNET.COM, but, due to a clerical error, CNET.COM has been removed from the DNS. Now, instead of getting an error saying that the site could not be located, you get Verisign. All your mail for CNET.COM, instead of getting queued and waiting for it to reappear for several days now instantly disappears into a black hole. I would think, if you were CNET.COM, in this case, you would be upset. Paragraph 5: ICANN bought into the claims that very specific things were broken by Verisign's actions. Those claims are true. The effort of Verisign to deceive the public into believing that this is not true and that ICANN caved under pressure from zealots and purists is a grossly inaccurate characterization of what happened. The pressure came from the operational community, the research community, and, end users. Sure, for some, technical purity and religion may be an issue. For most, we were far more upset that real applications in real use for real economic purposes were being interrupted or hampered by this unannounced, unprecedented, and, unacceptable change. Paragraph 6: This vocal minority is the MAJORITY of the people actually keeping bits flowing on the internet. It is, admittedly, not the majority of users of the internet, but, it does represent the majority of internet service providers. It represents the connectivity of the majority of users on the internet. Most end users don't even know what DNS is, let alone what happens when it is changed. It's not about resentment of use for commercial purpose. I'm sure there are people out there that think the internet shouldn't be used for commercial purposes. The majority of the outcry, however, came from people trying to make a living out of keeping the internet running for commercial purposes. Mr. McLaghlin and Verisign seem, instead, to have ignored the fact that there's more to the ineternet that matters to our economy than just Web Browsing. Paragraph 7: They can disagree with purists all they want. The problem is that here they are disagreeing with the actual operators of the internet who are not trying to hold the internet back, but, keep it functioning. Paragraph 8: Throughout that history, the debate has been held in public and actions and changes to standards on the internet have been based on a combination of rough consensus and running code through a public process known as the IETF (Internet Engineering Task Force). Verisign did not subject these changes to any form of review outside of Verisign. There was no community input or review. If there had been, the community would have rejected this before it started, because it had real operational impact, and, because it had Verisign abusing public trust to line their pockets. Fierce debate is good. Verisign tried to avoid debate all together by launching this without the required reviews beforehand. Verisign has a long history of doing this. Paragraph 9: This is the one paragraph with significant truth in it. The result of this debate will have far reaching implications for the future of the internet. Do we send a clear message to Verisign that their role as agent of the public trust does not involve making whatever changes to critical infrastructure they feel are in their best interests? Do we allow Verisign to continue down the road that they have repeatedly attempted where it is as if they think they own all rights to these TLDs which were entrusted to them to manage by contract from ICANN. ICANN is a non-profit public benefit corporation charged with managing this part of the internet infrastructure. They contracted out this specific duty to Verisign with some reasonably strict rules about how they can do it. Verisign, in spite of this, has repeatedly ignored those rules in it's own interest. If ICANN allows this to continue, it will, indeed, change the face of the internet significantly. Mr. McLaughlin may think that's a good thing, as he will surely profit heavily from it. I doubt that it will improve things for internet users or operators, however. Paragraph 10: The internet already has a process for doing that. It's called the IETF. If this didn't happen in IETF, we wouldn't have HTTP, IPSEC, or, even DNS. Almost every protocol in use today on the internet was developed through the IETF process. Many improvements to protocols (BGP is currently on version 4, for example) have also come through the IETF and the related RFC process. The significant test is not whether the internet can do this (it already has), but, whether the internet can control the contractors entrusted with the management of items in the interest of the public. If not, ICANN will need to find an alternative. That will be difficult and painful. Paragraph 11: Noone is discouraged from exploring the bounds of the internet. Verisign is discouraged from BREAKING existing functionality in the name of lining their pockets. There are lots of places on the internet to experiment with new tools. The two most populated top level domains in the DNS tree are _NOT_ the right place to experiment. You wouldn't want a rocket scientist developing new fuels at your kid's elementary school, would you? Well, what Verisign has done is equivalent to that. They decided without warning to conduct their experiment in production instead of a laboratory. Paragraph 12: This paragraph cannot stand without the lies from the previous paragraphs. Paragraph 13: Verisign did not spend hundreds of millions of dollars to fortify the two root servers alone. Also, a number of other root servers withstood the attack as well. This whole paragraph is specious and misleading. In fact, Verisign has one of the worst track records for errors of any DNS provider in history. The technical community is less concerned about what will happen without Verisign than they are about what Verisign will do to the internet. Paragraph 14: The decisions made in this debate will not be about innovation. They will be about theft and hijacking. Will Verisign be allowed to hijack non-existant domain names to their own purpose and profit? Will they be allowed to continue to make arbitrary changes to services which are considered critical infrastructure by a large portion of the Internet community? Will ICANN stand up and say "no more" to Verisign's abuse of their position under the ICAN and USDOC contracts? These are the decisions that will be made around this issue. Innovation is safe and secure in the IETF. I will agree that there are problems to be solved in the IETF process, but, Verisign's actions won't even touch those, let alone make any positive contribution. Paragraph 15: The decisions made over the next months and years will determine whether the namespace remains a consistent and well-ordered hierarchy, or, whether the distaste for Verisign and the lack of action by ICANN to stop them becomes so distasteful to enough network operators that the authority of ICANN is usurped and the namespace becomes fragmented. That would be bad for everyone. Biography: Owen DeLong is a Network Architecht for a Mountain View based communications firm. He has held positions ranging from Systems Administrator to Senior Backbone Engineer at ISPs ranging from very small to very large. He has designed and built networks from dialup to OC-192. He has been an active participant in the Internet Operational Community and NANOG for more than a decade. Owen DeLong owen(a)delong.com

1 0

Trying to subscribe to Sitefinder list
by Howard C. Berkowitz 07 Oct '03

07 Oct '03

Well, I've been trying. I got a double opt-in that gave me a deadline to respond of 5AM Wednesday. I replied. No confirmation. Tried to post (crossposted to NANOG). Got error message telling me I was not yet on the list. Of course, with the apparent assumption the Internet is the Web, the first directions were to use a browser. Another option was to respond with a token in the message, a common enough procedure for mailing lists. I didn't read the fine print well enough. The first time, I discovered that the token had "confirm no" in it. Removed "no". Reread instructions. Just removing wasn't enough. Had to edit it to "confirm yes". Is there something wrong with the user friendliness of this picture, assuming that people actually use something other than a web browser, shocking as that might be for a m-a-i-l-i-n-g l-i-s-t? grrrr.

3 2

Architectural issues involving Sitefinder & related functions
by Howard C. Berkowitz 07 Oct '03

07 Oct '03

(since I haven't gotten back my enrollment confirmation, it seemed appropriate to crosspost this to NANOG. While I will address Sitefinder, there are broader architectural and operational issues). Let me assume, for the sake of this discussion, that Sitefinder is an ideal tool for the Web user, helping with the problem of not-quite-correct URLs. Given that, I'll stipulate in this discussion that the implementation of Sitefinder, along with the .com and .net wildcards that lead to it for unresolved domains, is a true benefit for the Web user. The Internet, however, is more than the World-Wide Web. It seems only logical to be able to discuss Sitefinder in two contexts: 1. Where it becomes the default, as with the recent Verisign wildcards 2. Where it is reached in some other manner. My architectural concern is defining a way in which context #1 serves the _non-Web_ services of the Internet. If DNS were purely an information service for Web users, the architectural conflict would go away, and only commercial and policy issues remain. I would hope that within the scope of the Sitefinder discussion list, or alternatively in another forum, is an approach to reconciling the IP-level DNS such that it continues to serve non-Web applications. Is there disagreement that Sitefinder provides no functionality to SMTP trying to deliver to an unresolved domain? To a user who mistypes the name of an FTP site and does not intend to use a Web browser? What about failover schemes for non-HTTP cooperative research across the Internet, where the inability to resolve a host name (assume that cached records have a zero lifetime) triggers selection of an alternate server? Seriously, technical people at Verisign may have thought about this and actually have suggestions. They may be very good ones, but, judging on the reactions to the Sitefinder deployment, it might be well to discuss them in open technical forums before a change is made. I'm really not trying to make it a matter of personalities, but there have been public statements by Verisign executives that such a process inhibits innovation. If Verisign policy is that as operator of .com and .net, it has the right to make unilateral changes, I think that needs to be clear to all concerned. I recognize that a number of independent parties suggest that the ICANN contract does not explicitly prohibit such unilateral action. Ironically, I worked with the original founders of Network Solutions, and almost was a principal back when it was a couple of rooms in McLean. Gary Desler, the founder and a fine engineer, always used to say "there is no technical solution to a management problem". In the current context, I simply want to know the rules for the playing field.

1 0

Comcast - Atlanta?
by Ian Wilson 07 Oct '03

07 Oct '03

Could someone with a clue from Comcast in the Atlanta, GA area please send me an email off-list? Thanks; Ian -- Ian Wilson IWCG.net Ian()iwcg!net PO Box 304 . Ada, Ohio 45810 The authors at Microsoft were nice enough to credit LSD in their latest security bulletin. It's nice to see that they're finally admitting that they were on LSD when they wrote their code.

1 0

Utah to deploy public owned fiber to 17 cities
by Eric Kuhnke 07 Oct '03

07 Oct '03

From the CANET-NEWS list, this seems relevant to network operations... >For more information on this item please visit the CANARIE CA*net 4 Optical >Internet program web site at http://www.canarie.ca/canet4/library/list.html >------------------------------------------- > >[From www.convergedigest.com -- BSA] > >Utah's UTOPIA Project Plans Widescale FTTH Deployment >Salt Lake City and 17 other cities across the state of Utah are planning to >build a publicly-owned, fiber telecommunications network that would reach >nearly 250,000 homes and 35,000 business, representing a population of about >724,000. The Utah Telecommunications Open Infrastructure Agency (UTOPIA) >plans to build the network and then act as a municipally-owned wholesale >carrier. The project plans to issue 15 to 20 year bonds that would be paid >for by leasing capacity on the network to various service providers and >ISPs. It does not expected to raise the tax base for the communities served. > >UTOPIA plans to use an "Open Service Provider Network" model developed by >Dynamic City, which serves as consultant for the project. The first phase of >the rollout will connect some 15,000 homes beginning in early 2004. UTOPIA's >Fiber-to-the-home (FTTH) will use an active architecture rather than a PON >design. Riverstone Networks has been selected to provide core electronics >and access distribution systems. Allied Telesyn's RG223 Residential Gateway >has been chosen as the customer premises solution for the network. The RG223 >features two analog phone ports, three 10/100 Ethernet LAN ports, and >supports IGMP for secure and efficient multicast video.Allied Telesyn's >product distributes traditional voice and multiple IP-based services >throughout a home, including broadband Internet access, VoIP, broadcast >television, and video on demand. The gateway, which would be placed inside >the home, directly terminates the fiber connection. A category 5 Ethernet >cable is used to connect to an IP set-up box. >http://www.utopianet.org/ >http://www.dynamiccity.com >http://www.alliedtelesyn.com >06-Oct-03 > >Wave7 Optics Selected for Large FTTP Deployment in Tenn. >The Jackson Energy Authority (JEA) of Jackson, Tennessee, a municipal >utility, selected Wave7 Optics for a fiber-to-the-premises (FTTP) network >that is expected to pass some 31,000 homes and businesses in 2005. Jackson >Energy is the local electrical utility. Wave7 is scheduled to begin >delivering network equipment in December 2003 and JEA anticipates it will >initiate deployment in Q1 2004. The network will be used to deliver over 250 >analog and digital cable television channels, high-speed (up to 500 Mbps) >two-way business and residential Internet connections, full featured POTS >and IP telephony (as a carrier's carrier for local CLECs). Commercial >activation of the network is expected in Q2 2004. Wave7's solution is an IP >and Ethernet optical access system that provides all traditional >"carrier-grade" telephone services (including fax), high-speed data (e.g., >Internet service) and both analog and digital video (including IP streaming >video). Wave7 provides standard data, telephone and CATV interfaces at its >customer premise devices, accommodating existing home and business >telephone, television and computer systems. Financial terms were not >disclosed. >http://www.wave7optics.com >http://www.jaxenergy.com >06-Oct-03 > > > >------------------------------------- >To subscribe or unsubscribe to the CANARIE-NEWS list please send e-mail to: > >majordomo(a)canarie.ca > >In the body of the e-mail: > >subscribe news >end > >------------------------------------- > >These news items and comments are mine alone and do not necessarily reflect >those of the CANARIE board or management. >----------- >Bill.St.Arnaud(a)canarie.ca >starnau(a)attglobal.net >www.canarie.ca/~bstarn >

1 0

Re: Is there anything that actually gets users to fix their computers?
by Kee Hinckley 07 Oct '03

07 Oct '03

At 8:15 PM -0400 10/6/03, Jeffrey S. Young wrote: >It's a difficult thing for all of us when j.random users start to discover >things like personal firewall. I had one threaten me personally with >'investigation' by the FBI because "my system was attempting to break >into his PC" He sent it to my account, no cc: to abuse. I'm quite sure these are off topic. But I have to say my favorite response came early in the wormalert hoax, when I was attempting to respond by hand to people asking them to stop sending us email. I received this reply. >Gather evil into your briars >Reflect negativity back to its sender >all ill will or any blight >Snatch from the air and send it back in flight >Seek out the one who did this deed >That it return to them thrice >by magick's creed >Hence more contact made by he >spew his negativity back times three. > >So Mote It Be I'd never been formally cursed before. Sure beats a DoS attack. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.

1 0

Comcast
by Wesley Vaux 07 Oct '03

07 Oct '03

Is anyone having issues sending or receiving email to comcast.net? Is there anyone here from comcast? Wes Vaux, CCNA, CCDA Network Security Engineer

2 1

Re: Reverse DNS problem
by Trent Arsenault 06 Oct '03

06 Oct '03

I've been in touch with ARIN on the same issue noticed at a different site. According to ARIN, some older BIND resolvers aren't handling the referrals that they get back from the gtld-servers for some of ARIN's name servers. The problem started Thursday when ARIN changed the list of NS's for the ARIN in-addr.arpa zones. ARIN is still investigating and I'm waiting to hear back. Trent Arsenault trent(a)trent.us At 05:46 AM 10/6/2003, Schmiedt, Jamie wrote: >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

RE: cisco site down? multiple sources reporting connectivity problems
by Sean McPherson 06 Oct '03

06 Oct '03

> From: Brennan_Murphy > Date: Mon Oct 06 14:56:46 2003 > > --------------------------------------------------------------------------- > > I'm on multiple mailing lists now with multiple persons reporting > connectivity issues to cisco.com. > > Can anyone summarize what the issue is? I'm currently getting the following: [sean@smidgen /tmp]$ telnet www.cisco.com 80 GET / HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 06 Oct 2003 20:33:47 GMT Server: CCO/1.0 (Unix) Set-Cookie: CP_GUTC=128.107.241.137.138341065472427777; path=/; expires=Fri, 29-Sep-28 20:33:47 GMT; domain=.cisco.com Content-Type: text/html Connection: close Connection closed by foreign host. And poof, that's it. No data. Try again, and I randomly get the whole page, part of the page down to the 'Feedback' line, or nothing. Same thing happens from work (AT&T / Qwest) or from my cable modem at home (InsightBB.com) Mozilla/Firebird and IE (5 or 6) seem to treat it a bit differently, and so far, Galeon and Opera seem the most adept at handling it w/o spitting up when a page closes mid-stream. Sean McPherson nanog <@ is the at sign> seanmcpherson dotcom

2 1

Will reverting DNS wildcard have any adverse affects?
by Gerald 06 Oct '03

06 Oct '03

I keep trying to think of how this discussion could be operationally relevant. The only thing I could come up with is: Will reverting back to the proper NXDOMAIN break anything? I have only seen inconveniences on my network since they changed, though I know some had it worse than I did. For the benefit of other NANOG readers, make sure reverting back won't cause more headaches on your network. Gerald Coon - How are ya? Never been better, ... Just once I'd like to be better.

9 19