October 2003 - Test - lists.nanog.org

Re: Verisign to sell Network Solutions
by Michael.Dillon＠radianz.com 17 Oct '03

17 Oct '03

CW> So...correct me if I'm wrong here...does this mean that the CW> registry services operations and the GTLD maintenance CW> operations for .com/.net will be owned by different CW> companies? >I wonder just how different they are, and what deals are being >made under the table. People don't normally draw a distinction between the registry and the GTLD operations. Normally people just assume that GTLD operations is part of the registry service. There are other GTLD registries that have outsourced the operation of their TLD DNS server operations but the key here is who controls the contents of the TLD zone. In every case, that is the GTLD registry so I don't think it would make any difference to the situation if Verisign were to spin off the GTLD operations. Remember, this whole thing was sparked by Verisign adding a wildcard record to the .COM and .NET zones. They didn't change their DNS servers; they just added bad data to them. --Michael Dillon

1 0

requesting hard data sources on ramifications of verisign wildcard
by k claffy 17 Oct '03

17 Oct '03

as already mentioned, fascinating public policy theatre is going on in DC on the verisign wildcard issue, see http://secsac.icann.org/ [all video and even transcripts of both meetings online. go icann.] you are encouraged to read through all of it before making public comments on this issue at nanog. (or, hope springs eternal, to this list.) caida has the following request on behalf of icann's secsac committee [an exceptionally competent group who is approaching this issue with impressive speed, equaniminity, and integrity. http://www.icann.org/committees/security/ i believe we're in good hands here. let's give the process a chance and constructively contribute where we can.] a common theme over the last week is an admitted lack of hard data [rather than lists of theoretical breakages, and anecdotal evidence, and predictions] from the operational community on actual loss of stability in Internet performance or functionality. david from XO gave an outstanding talk on 7 oct, http://www.icann.org/presentations/shairer-secsac-dc-07oct03.ppt but, as with many other providers, he deployed the bind patch within 24 hours so he didn't really have useful hard data to put on the table. i get similar comments from others. ben from harvard also gave some hard alexa data, fwiw http://www.icann.org/presentations/edelman-secsac-dc-15oct03.ppt but from a specific vantage point. we need more of these. icann's secsac committee is in a much stronger position to provide technically sound and equitable guidance if we can provide them with as specific, concrete examples (*hard data*) that indicate extent of various types of breakage. please save the arguments regarding the legitimacy and short notice of this request until you've read the hours of discussion about it that has already occurred among many qualified folks in DC (and in any case the meta-issue still stretches AUP of nanog list). the inconvenient reality is that the secsac committee needs concrete data (imagine), in addition to bulleted lists of things that break, for the policy process to work most effectively here. and nanog is in a position to make a difference. you are hereby encouraged to do so. please send any hard data reflecting observed ramifications on security and stability of Internet infrastructure to secsac-comment(a)icann.org no hard data will be refused service k

3 2

Re: Site Finder
by Robert Boyle 16 Oct '03

16 Oct '03

At 09:27 PM 10/16/2003, you wrote: >I agree that an application level solution at the edge is the best. > >I like the idea of having a user configurable parameter in the client >browser to allow the ``finder'' URL to be set. The browser >``manufacturer'' would of course put their own default and the ISP would >be able to ``configure'' their own defaults and the >end user could ``change'' it to suit their preferences. >This would allow competing ``URL finder'' type services, allow ISPs to >fine tune the interface for their customers and allow end users to >customize their own interface to the ``web''. > >Maybe its time for some ``finder'' API specifications, >mozilla patches, and ``finder'' reference implementations. The Internet Explorer Administration Kit has enabled this functionality for many years. We changed our default search page to Google about 3 years ago for all of our users who install our branded IE and dialer CD. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

1 0

Operational content, snr and nanog mailing list...
by Joel Jaeggli 16 Oct '03

16 Oct '03

By my count there have been 23 odd messages in which the subject contains the word tomatoes, this is out of 96 messages I've recieved on this list since midnight pdt. Isn't there something more useful people on this list could be doing. joelja -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja(a)darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

2 1

Site Finder
by Ray Bellis 16 Oct '03

16 Oct '03

Quoting Rusty Lewis from http://verisign.com/corporate/news/2003/pr_20031007b.html?sl=070804 "We will continue to take feedback from both Internet users and the technical community on how we can ensure that the service is available for the many Internet users who clearly like it." Well that's very simple Rusty - stop screwing around with *our* DNS and write a plugin for IE to catch NXDOMAIN, just like the Google toolbar does. That'll allow 90% of the browsing population a *choice*, something the wildcard clearly does not. Ray -- Ray Bellis, MA(Oxon) - Technical Director community internet plc - ts.com Ltd Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ tel: +44 1865 856000 email: ray.bellis(a)community.net.uk fax: +44 1865 856001 web: http://www.community.net.uk/

9 8

instead of tomatoes
by David Lesher 16 Oct '03

16 Oct '03

May I suggest..... pumpkins.... A pumpkin per complainant would make a nice visual symbol, one the press could grasp. And afterwards, they could be donated.... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

RE: Pitfalls of annoucing /24s
by Forrest 16 Oct '03

16 Oct '03

True enough, but are there any providers currently that filter /24's from the old Class C space that /24's were assigned directly from? I realize that if proposal 2002-3 does get passed but everyone filters those prefixes then it will be a completely worthless proposal, and even worse than using PA space. It seems to me that proposal 2002-3 could enable providers to filter more efficiently however. They could accept the long prefixes out of the micro-assignment block, while filtering out all the garbage /24's in the other space caused by people needlessly announcing every /24 out of their large aggregate. Forrest On Wed, 15 Oct 2003, Andrew Dul wrote: > Forrest, > > Even if ARIN passes this policy that will not make any provider change > their filtering policy. It is true that many providers do use the ARIN > allocation sizes to create their filtering rules but the two are not > inherently linked. Any ASN can choose the filter on what ever rule set > they choose. > > Andrew >

5 4

ISC causes stability problems
by Sean Donelan 16 Oct '03

16 Oct '03

An "anonymous reader" using almost identical language to Verisign public statements, submitted the following to Slashdot: "After .COM and .NET started using a wildcard, the internet community busily started creating patches to various pieces of software to circumvent this. It was said that this was a grave problem to the internet. Several official BIND patches were announced over the next few days. However, it turns out they weren't necessarily too well thought through. Usage of the patch unexpectedly broke at least 7 Top Level Domains, ISC announced 3 weeks later, after users started having problems. The .NAME registry has sent a formal letter to ICANN's Security and Stability Advisory Comittee to warn against using the BIND patch, which they will look into in their next meeting. The intention may have been good, but... Stability? Anyone?" NSI negotiated an agreement with ICANN overseen by the Department of Commerce so it could keep acting as the registry and registrar for .COM and .NET. NSI/Verisign entered into this agreement of its own free will in order to extend its registry and registrar contracts for many years. NSI/Verisign agreed to follow several procedural safeguards, which some other registrar/registries like .NAME didn't. As part of the agreement NSI/Verisign split domain name operations into two parts. The VeriSign COM NET Registry managed the COM and NET registry and zone files. Verisign GRS committed to fair and equitable treatment of all ICANN registrars accreditated by ICANN. The Registry systems are supposed to have "total separation" from other VeriSIgn systems. Quoting their web site: "Since the establishment of the Registry division in 1999, a primary focus of the entire staff has been developing and maintaining effective structural and procedural measures to provide an effective, credible separation between its Registry and affiliated Registrar businesses." The Registry (not the Registrar) is responsible for generating the .COM and .NET zone files from information submitted by all accredited registrars on an equal basis. Assuming Verisign defends its position that wildcards in a top-level zone don't create security or stability problems, how will the Verisign GRS make the wildcard capability available to all ICANN acredited .COM and .NET registrars without creating a conflict of interest? Why shouldn't all ICANN accredited registrars be able to enter wildcards in the .COM and .NET zone files on a equal access basis? Or is the Verisign GRS favoring its corporate sibling by entering special information in the .COM or .NET zone files for its sibling's benefit without offering the same capability to all other registrars. Registry Code of Conduct http://www.icann.org/tlds/agreements/verisign/registry-agmt-appi-com-25may0…

8 7

Backdoor Trojan behind BigPond, Internet spam woes
by Sean Donelan 16 Oct '03

16 Oct '03

http://www.zdnet.com.au/newstech/security/story/0,2000048600,20279775,00.htm Backdoor Trojan behind BigPond, Internet spam woes By Andrew Colley, ZDNet Australia 15 October 2003 U.S.-based Internet security researchers have confirmed that a worm is behind the sharp jump in spam activity battering Telstra's BigPond and other major global ISPs since early last week. UPDATE: BigPond service recovery may take 'several weeks' By Iain Ferguson, ZDNet Australia 14 October 2003 Telstra has conceded it may be several weeks before BigPond e-mail service levels return to normal as the telecommunications carrier wrestles with delays caused by a steep ongoing surge in traffic.

1 0

RE: Tomatoes for Verisign at NANOG 29
by Dave Hilton 16 Oct '03

16 Oct '03

In reference to some earlier politically active days: Hey! Hey! Ver - i - sign ! How Many Domains Do You Think Are Thine? Hilton

1 0