July 2008 - Test - lists.nanog.org

RE: what problem are we solving? (was Re: ICANN opens upPandora's Box of
by Gregory Hicks 01 Jul '08

01 Jul '08

> Subject: RE: what problem are we solving? (was Re: ICANN opens upPandora's Box of > Date: Tue, 1 Jul 2008 12:25:38 -0700 > From: "Tomas L. Byrnes" <tomb(a)byrneit.net> > To: "Jay R. Ashworth" <jra(a)baylink.com>, <nanog(a)nanog.org> > > Shouldn't we take all the ICANNt and DNS Related stuff to > dns-operations? Seems more "on-topic" there... > > > -----Original Message----- > From: Jay R. Ashworth [mailto:jra@baylink.com] > Sent: Tuesday, July 01, 2008 11:48 AM > To: nanog(a)nanog.org > Subject: Re: what problem are we solving? (was Re: ICANN opens > upPandora's Box of > > On Tue, Jul 01, 2008 at 12:04:57PM +0100, Roland Perry wrote: > > In article <20080630212216.GJ8195(a)cgi.jachomes.com>, Jay R. Ashworth > > <jra(a)baylink.com> writes > > >The Domain Name System is not now, and never has been, away to *find* > > > >things, anymore than 123 Elm St, Worcester MA is a way to *find* a > > >house. > > > > What about "1 Microsoft Way, Redmond, WA" ? > > Or 1 Tech Data Drive, Largo, or 1 Infinite Loop; yeah, there are lots of > good examples of why addresses are random and shouldn't be used to > *locate* things... except as keys into directories. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra(a)baylink.com > Designer The Things I Think > RFC 2100 > Ashworth & Associates http://baylink.pitas.com > '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 > 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Joseph Stalin) > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.101 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 > 7:26 AM > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

1 0

Packetloss while transiting as7018
by Brad Tarno 01 Jul '08

01 Jul '08

Any AT&T engineers willing to help me out? I'm seeing some significant packet loss but only when using our AT&T circuit. (USING AT&T) Source: 67.192.51.58 Destination: 24.73.68.114 traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.569 ms 0.566 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.359 ms 0.338 ms 0.366 ms 3 vlan903.edge4.dfw1.rackspace.com (72.3.128.52) 0.484 ms 0.476 ms 0.366 ms 4 12.87.41.177 (12.87.41.177) 2.111 ms 1.980 ms 1.864 ms 5 tbr1.dlstx.ip.att.net (12.122.100.42) 2.485 ms 2.474 ms 2.613 ms MPLS Label=32334 CoS=0 TTL=127 S=0 6 * ggr3.dlstx.ip.att.net (12.123.16.193) 2.091 ms 1.962 ms 7 * 192.205.35.142 (192.205.35.142) 2.210 ms 2.212 ms 8 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.483 ms 12.595 ms * 9 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 15.869 ms * 6.799 ms 10 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 59.553 ms 33.089 ms 33.075 ms 11 * * * 12 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.198 ms 33.463 ms 33.288 ms 13 gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.341 ms 33.190 ms * 14 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 36.223 ms 35.200 ms * 15 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 46.048 ms * * --- 24.73.68.114 ping statistics --- 374 packets transmitted, 193 received, 48% packet loss, time 373296ms rtt min/avg/max/mdev = 42.010/44.140/65.817/2.757 ms, pipe 2 (NOT USING AT&T) traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.598 ms 0.972 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.504 ms 0.468 ms 0.441 ms 3 vlan903.edge3.dfw1.rackspace.com (72.3.128.51) 1.914 ms 1.954 ms 1.992 ms 4 xe-8-1.r02.dllstx09.us.bb.gin.ntt.net (157.238.225.221) 2.098 ms 2.138 ms 1.986 ms 5 4.68.63.221 (4.68.63.221) 60.079 ms 2.060 ms 2.120 ms 6 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.419 ms 15.234 ms 2.244 ms 7 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 2.758 ms 14.855 ms 2.995 ms 8 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 33.125 ms 32.968 ms 33.334 ms 9 ae-7-7.car2.Tampa1.Level3.net (4.69.133.41) 32.984 ms 32.956 ms 33.192 ms 10 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.161 ms 33.068 ms 33.343 ms 11 gig10-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.65) 33.213 ms gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.085 ms 32.954 ms 12 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 34.965 ms 35.080 ms 34.845 ms 13 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 42.830 ms 43.941 ms 44.589 ms --- 24.73.68.114 ping statistics --- 122 packets transmitted, 122 received, 0% packet loss, time 121191ms rtt min/avg/max/mdev = 41.699/43.900/46.118/1.060 ms, pipe 2 ============================ Brad Tarno Backbone Network Engineer Rackspace IT Hosting ============================ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse(a)rackspace.com, and delete the original message. Your cooperation is appreciated.

1 0

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Stephane Bortzmeyer bortzmeyer(a)nic.fr wrote: > I am very curious of what tests a "security-aware programmer" can do, > based on the domain name, which will not be possible tomorrow, should > ICANN allow a few more TLDs. The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and '[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective. Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name. It's not too hard to see the problems with that. An analogous network scenario would be IP addresses of varying length and without a netmask. > If you test that the TLD exists... it will still work. Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case. > If you test that the name matches (com|net|org|[a-z]{2}), then you are > not what I would call a "security-aware programmer". Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic? Not that that doesn't happen now, to a far lesser degree. But it's the extent to which this presents new opportunities for black hats that should have given ICANN pause. Odds are that RBLs will be among the first targets. Bottom line is the decision was made for it's _monetization_ value, not security, and customer service was just a pretense. Roger Marquis

14 24

Re: DNS and potential energy
by Daniel Hagerty 01 Jul '08

01 Jul '08

Rob Pickering <rob(a)pickering.org> writes: > Or .com. Oddly enough I just now found a Windows box and typed > "command.com" in a browser URL bar and it did what I expected, when I > typed the same thing at a cmd prompt it did something different and I > expected that too. 1. Copy \windows\system32\cmd.exe to the desktop. 2. Run internet exploder. 3. Type "cmd.exe" in the address bar and observe what happens. I don't know about you, but given ie's default download location, and your (apparently common) erroneous expectation, this looks ripe for social engineering to me.

1 0

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Phil Regnauld wrote: > As business models go, it's a fine example of how to build demand > without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis

9 18

Re: Mail Server best practices - was: Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Rich Kulawiec wrote: > notification is essential in order to provide a heads-up about > problems (and that once problems are noticed, cooperation is > essential in order to fix them). But mail should never be > discarded without notice In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. Quoting <http://www.postconf.com/docs/spamrep/> : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis

3 2

Re: DNS and potential energy
by Rob Pickering 01 Jul '08

01 Jul '08

> > Maybe it's not that bad. The eventual result is instead of having > a billion .COM SLDs, there are a billion TLDs: all eggs in one There are simply not going to me billions, millions, or even probably tens of thousands of TLDs as a result of this. It's still a complex several months long administrative process that costs some multiple of $100,000. As far as I can work out, minus the press noise, the difference is that creating a TLD will take half a year rather than half a decade or more. > basket, the root zone -- there will be so many gTLD servers, no DNS > resolver can cache the gTLD server lookups, so almost every DNS > query will now involve an additional request to the root, instead > of (usually) a request to a TLD server (where in the past the TLD > servers' IP would still be cached for most lookups). Maybe, maybe not. > Ultimately that is a 1/3 increase in number of DNS requests, say > to lookup www.example.com > if there wasn't a cache hit. In that case, I would expect the > increase in traffic seen by root servers to be massive. There will probably be a significant increase if there is a very wide takeup of new TLDs, yes. Conversely load on some of the existing gTLD servers may decrease if the number of domains in active use is spread across a larger number of independent TLDs. > Possible technical ramifications that haven't been considered with > the proper weight, > and ICANN rushing ahead towards implementation in 2009 without > having provided opportunity for internet & ops community input > before developing such drastic plans? > Massive further sell-out of the root zone (a public resource) for > profit? Further > commercialization of the DNS? Potentially giving some registrants > advantageous treatment at the TLD level, which has usually been > available to registrants on more equal terms?? > [access to TLDs merely first-come, first-served] Don't think that is operational and in any case the current system is weighted towards entities who have had domains for eons when they were able to be the first comers, it's very unfair and unequal in the sense that it works against the interests of newer registrants. Definitely not operational though. > Vanity TLD space may make ".COM" seem boring. Visitors will expect > names like > "MYSITE.SHOES", and consider other sites like myshoestore1234.com > "not-legitimate" > or "not secure" > > > The lucky organization who won the ICANN auction and got to run the > SHOES TLD may price subdomains at $10000 minimum for a 1-year > registration (annual auction-based renewal/registration in case of > requests to register X.TLD by multiple entities) and registrants > under vanity TLD to sign non-compete agreements and other > pernicious EULAs and contracts of adhesion merely to be able to put > up their web site, > > As a subdomain of what _LOOKS_ like a generic name. > > > And, of course, http://shoes/ reserved for the TLD registrant's > billion-$ shoe store, > with DNS registration a side-business (outsourced to some DNS > registrar using some "domain SLD resale" service). The operational issue is? Actually your shoe shop still now has a greater number of choices (.com or .shoes) and I can bet that if your scenario comes to pass with a very aggressive and restrictive registrar of .shoes, some enterprising soul will register .boots, .sneakers or .shoeshop etc to make their living on those parts of the market that don't like .shoes policies. > The possibilities that vanity TLD registry opens are more insidious > than it was for someone to bag a good second-level domain. Questionable and certainly not operational. > > > >> Sure, nefarious use of say .local could cause a few problems but >> this is > > I'd be more concerned about nefarious use of a TLD like ".DLL", > ".EXE", ".TXT" Or other domains that look like filenames. Or .com. Oddly enough I just now found a Windows box and typed "command.com" in a browser URL bar and it did what I expected, when I typed the same thing at a cmd prompt it did something different and I expected that too. > Seeing as a certain popular operating system confounds local file > access via Explorer with internet access... > You may think "abcd.png" is an image on your computer... but if you > type that into your > address, er, location bar, it may be a website too! To the extent that possibility already exists, there is a reason that web URIs have both a host and path component. I don't see why new TLDs substantially change this. If applications insist on confusing the two then bad things will always happen but that is an app issue. -- Rob.

1 0

Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
by Jay R. Ashworth 01 Jul '08

01 Jul '08

[ back on list ] On Mon, Jun 30, 2008 at 05:34:53PM -0400, Jerry B. Altzman wrote: > There was a HUGE one about that domain name between Nissan Motors and > some computer consultant named Nissan (a Hebrew name) in NC. > vis http://www.nissan.com/Lawsuit/The_Story.php > I don't know exactly how to quote the ruling and decision. Nissan Motor > Co. Ltd v. Nissan Computer Corp Yeah, I vaguely remembered it after you mentioned it. A quick look at the website would imply that he won, which rather makes my point, no? :-) The September ruling speaks directly to my assertion that the mere existence of a mark in a domain name doesn't constitute infringement. The methods by which you can infringe a trademark are pretty bright-line... Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)

2 1

Re: ICANN opens up Pandora's Box of new TLDs
by Jean-François Mezei 01 Jul '08

01 Jul '08

Scott Weeks wrote: > How'd you do that? I use FF on FreeBSD, but parhaps there're similar settings. Since a few people asked. in the url line: about:config This is the magic incantation that gets you a page with just about all configuration settings. you can serach for a particular setting in the "filter". To disable the google searching, look for the string "keyword". set keyword.enabled to "false". You can alco zap the value of keyword.URL To get a button to easily enable and disable javascript: http://prefbar.mozdev.org/ This allows you to put up a whole series of buttons such as java, images, javascript, kill cache, and a "UA" selection box to fake other browsers and much more. Another extension is the Web Develoer extension: http://chrispederick.com/work/web-developer/ It gives you plenty of options, including disabling CSS, viewing source etc etc. Good support available in the mozilla.support.* newsgroups (such as mozilla.support.firefox). If you are on an ISP that have cut down NNTP, it is available on the NNTP server: news.mozilla.org

2 1