- Test - lists.nanog.org

RE: new.net: yet another dns namespace overlay play
by Mathew Butler 07 Mar '01

07 Mar '01

etoy.com versus etoys.com. -Mat Butler -----Original Message----- From: William Allen Simpson [mailto:wsimpson@greendragon.com] Sent: Tuesday, March 06, 2001 12:26 PM To: nanog(a)merit.edu Subject: Re: new.net: yet another dns namespace overlay play -----BEGIN PGP SIGNED MESSAGE----- Patrick Greenwell wrote: > > On Tue, 6 Mar 2001, Paul A Vixie wrote: > > ICANN's prospective failure is evidently in the mind of the beholder. > > Besides producing a UDRP that allows trademark interests to convienently > reverse-hijack domains Awhile back, somebody made a similar accusation. So, I spent the better part of a weekend reviewing a selection of UDRP decisions. Quite frankly, I didn't find a single one that seemed badly reasoned. Could someone point to a "reverse-hijacked" domain decision? > and the selection of a handful of lackluster > TLDs from a pool of applicants Here, I will agree. My observation is that they chose lackluster TLDs to avoid controversy on this, the first introduction of new TLDs in a dozen years. More will be forthcoming as operational experience is gained. And that's our area of expertise -- operational -- isn't it? > paying a non-refundable 50k fee in a The fee was always (and I'm going back to IETF, IAHC, and various other discussions) expected to be non-refundable. Pay as you go. Nobody else pays for your cost to operate. Very libertarian. Apparently, you've never optioned property.... Or supplied a performance bond. > completely arbitrary and capricious process, Really? In the legal sense? What proof do you offer? > perhaps you could point to > some of the many successes of ICANN as an organization? The public participation around the world has far outstripped anything I'd ever expected. On that basis alone, it's a success. Yes, I wish that things were moving faster. I wish that the fully envisioned board had been selected. I wish that there was more sunshine. But, I realise that not every citizen on the planet has the same adversarial bent in their civilization, and that some even consider collegial closed meetings more civilized! We've added some good people in the elections, and I have high hopes. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQCVAwUBOqVHh9m/qMj6R+sxAQGr8gQAgZC83rFcxOzQx13APCRlVmEXANHf/OMN rfiaAvZCW0Pq3mTt2/8roffizEZYQzN2cK/Y6pkyJj/9Le04t6FzFCbOdh8gdLjv E6XPu3AplDXbqNLZ38uN+A8lN9rnjhlkb7NuIvmGDF4zG6pj3YLrlhzEYQnxCyWW MIGSB9blde4= =QQ8G -----END PGP SIGNATURE-----

1 0

Re: Loose Source Routing
by smd＠clock.org 07 Mar '01

07 Mar '01

Uh is this "invent an acronym" day on NANOGame Street? | It makes sense to require peers to allow LSTR through their peer's | networks. LSRR is an IP option. So is SSRR. They stand, respectively, for Loose Source and Record Route and Strict Source and Record Route (RFC 791). All IP routers should DTRT with these options, even when disallowing the service. LSTR is something you made up which I guess means Loose Source Trace Route, which I guess refers to what you get from some traceroutes that take a -g (to specify one (of perhaps several) LSRR gateways). You probably _can_ allow something approaching only the traceroute application to use LSRR across your network, but basically that'd be done by something like filtering at the edge based on packet type if the LSRR option is set. Given that intermediate routers that are not LSRR gateways themselves have little to do with processing of an LSRR option, this seems, well, a suboptimal approach. Of course, if you're doing MPLS (barf barf barf) then digesting a new acronym hourly and doing tonnes of packet classifications at the edge is second nature anyway, so I guess I should shut up before someone calls me a curmudgeon. | Any badness that LSTR would allow seems to pale in comparison to A> | Peer's need to check policy compliance and operational troubleshooting, | and B> other nefarious things that can be done and not solved. Okay, I can't resist: if you have deployed MPLS strategically such that basically all traffic is going through multihop TE tunnels, what becomes of a packet with several LSRR or SSRR options flagged? (Extra credit for answers that let you be one of 2304290348209843 people listed in the Acknowledgements or Authors sections of a typical MPLS wg draft, or if you're a smarty pants who has already accomplished that, and still don't have a looking-glass in your network). Sean. - -- Sean Doran <smd+mean(a)ab.use.net>

2 1

Re: new.net: yet another dns namespace overlay play
by richb＠pioneer.ci.net 07 Mar '01

07 Mar '01

Shawn McMahon <smcmahon(a)eiv.com> wrote: > Wow; they wrote a program that transfers information, then redirects a > browser (via hooks already built in to the browser) to a new web page? > ... every Tom, Dick, and Harry will think he can just go off and > write that code. This one sums it up the best for me. About a year ago, I attended a talk by one of those 24-year-old megamillionaires who started out as a DJ in some remote New England hick town and then found himself in the Bay Area working at Oracle. At some point he decided to leave the nest, and had to choose between two opportunities: helping to start an Internet faxing company, or starting an online music-DJ service. He pondered this briefly: faxing? DJing? Which would I rather do? Well, of course he chose the more-fun DJ service, which landed him a 9-figure bank account and a job among the top ranks at AOL. May those who chose the glamorous career path as Internet registrar/root zone-grabber do quite so well. Sheesh. Yawn. And now let's return to our regularly scheduled discussion: how do you config your router for that? (A browser plugin?? Ugh.) -rich

1 0

RE: new.net: yet another dns namespace overlay play
by Karyn Ulriksen 06 Mar '01

06 Mar '01

:: > The stub config is interesting, though. :: :: Will be interesting to see if it even works. :: :: If they are just stubs for the fakeTLD.newdotnet.net., then :: all client :: requests will have to be properly formatted on send, meaning :: that it will :: only work if the plugin is used. Stuff like ping won't work. Nasty. :: :: If they are supporting an alias function (assuming ISPs are able to :: control the DNS settings on their users systems), then the :: ISP partners' :: DNS servers will have to run fake roots in order catch the :: requests for :: fake.zone. If they do that, are they going to answer with fake.zone. :: RRsets? or are they going to DNAME/CNAME everything? :: :: Neither mechanisms are pretty, both are required, it'll never last. No. It appears that they have fully prepared TLD DNS service implemented for the .chat, .xxx, .book, etc., Just like I could prepare a .karyn. TLD and set it up on my name server. I checked it out, the stub config sets up a slave stub zone for the TLDs they are serving, the resulting db file generated is like: ; BIND version named 8.2.3-REL Wed Jan 31 09:45:01 PST 2001 ; BIND version root@dns-01-001.root-dns.com:/usr/local/src/bind-8.2.3/src/bin/named ; zone 'chat' first transfer ; from 204.69.234.253:53 (local 64.7.192.162) using AXFR at Tue Mar 6 09:29:16 2001 $ORIGIN .chat 7200 IN SOA ns0.newdotnet.net. hostmaster.new.net. ( 983865614 1200 300 3600000 600 ) 7200 IN NS udns1.newdotnet.net. 7200 IN NS udns2.newdotnet.net. Using the stub config, you don't have to alter your root.cache. If ICANN has the root servers start serving of .chat info, then you can just remove the zone config from the .conf file. It's not that complicated to manage. You can keep the whole stub config outside of your main configs and "include" it (I do this ALOT anyways). The result is that you have a simple NS record like you do for COM/NET/ORG/EDU, etc. Not to evil. However, it would be VERY evil if the plug-in thing got into broad use. What a load that would be. Technical support on it would be a nightmare for every single ISP on the Internet. Imagine troubleshooting Joe Users browser access when he isn't telling you he's using this thaang. Dark clouds of jumbled characters over every TS cube is what you'll get. Next thing you know, every inet app would have to have this layer to get anywhere (the POS layer). Also, it's pretty evil that the first course they are offering ISP is to replace their root.cache file with a file that just has their 3 dns servers. No thanx. I'd hate to see what I'd find out when I trace out their locations and connectivity. Hopefully, they are smarter than having it as Bob's ISP, but I (like most netops) have become very cyncial about the technical capabilities of startups and "new" technologies. I would be willing to use them for name service for these alternative TLDs until they are served on the root servers. BUT, I won't depend on them for access to the root servers themselves. Color me foolish. K

2 1

RE: new.net: yet another dns namespace overlay play
by brandon＠rd.bbc.co.uk 06 Mar '01

06 Mar '01

> and of course, mac, un*x and linux users would be right out, unless they > plan to serve that market with "patented technology" as well. Don't need to, most companies don't bother and we get by > whatever you may think of ICANN, this concept is still fairly brain > damaged. For a land grab you only need those windows users with a plug in or on ISPs that have bought in to it (could be lots of people), the others without are part of your grab, you get them to hassle their ISP "why can't we get to hot.xxx", some ISPs will add the new root, repeat until owned or laughed off the net. Failure to get critical mass is probably the main reason none of the other alternate roots have grown. There's ICANN frustration, if you deliver what people wanted from ICANN the public may adopt it. brandon

1 0

RE: new.net: yet another dns namespace overlay play
by Richard Welty 06 Mar '01

06 Mar '01

Charles Sprickman [mailto:spork@inch.com] wrote: > On Mon, 5 Mar 2001, Steve Rubin wrote: > > patent-pending technology? oh brother. > Actually, that would be the part of it that lets users get to > these new > domains even if their ISP does not cooperate. Read the release again > carefully. hint: browser plugin. ok, here's the problem: if we take the press release as written (dangerous to do), then the design is inherently flawed, as the browser will be able to see the domains, but a copy of Eudora or a traditional FTP client wouldn't be able to. if we assume the press release is in error, then the "patented technology" might consist of a different name resolver for windows -- but i don't know how hard that substitution is to actually do, not being a windows hacker type. and of course, mac, un*x and linux users would be right out, unless they plan to serve that market with "patented technology" as well. whatever you may think of ICANN, this concept is still fairly brain damaged. richard

1 0

RE: new.net: yet another dns namespace overlay play
by Karyn Ulriksen 06 Mar '01

06 Mar '01

I wonder how many unsophisticated network operators are going to give up the existing root server infrastructure for this obviously problematic layer: ; . 3600000 IN NS ns1.newdotnet.net. ns1.newdotnet.net. 3600000 IN A 206.132.100.43 ; . 3600000 IN NS ns2.newdotnet.net. ns2.newdotnet.net. 3600000 IN A 64.209.213.126 ; . 3600000 IN NS ns3.newdotnet.net. ns3.newdotnet.net. 3600000 IN A 209.151.233.13 ; yeah. I want to rely on three root level name servers. Really, I do! I do! Can't we knock off some of the root servers like the one at MIT or something? Besides, I'm certain that idealabs! has much better experience in creating scalable nameserver systems than Vix, etc. <cough> The stub config is interesting, though. Maybe run it until ICANN figures out what they are going to do. Since the users pay the bills for the most part... K :: -----Original Message----- :: From: Kevin Loch [mailto:kloch@opnsys.com] :: Sent: Tuesday, March 06, 2001 9:30 AM :: To: Brian :: Cc: nanog(a)merit.edu :: Subject: Re: new.net: yet another dns namespace overlay play :: :: :: :: Brian, :: :: I'm curious, the use of UDNS1 and UDNS2 in your nameserver :: host names seems to suggest that UltraDNS is affiliated :: with this somehow. Is that true or was it just a bad :: choice of hostnames? :: :: KL :: :: Brian wrote: :: > :: > Here's the part of new.net that seems not well thought :: out. So if you don't :: > wanna dink with system settings to be an end user, and are :: not on a partner :: > network, then too bad, is that what I appear to be seeing? :: > :: > 2. Are there differences between how New.net domain names :: and .COM/.NET/.ORG :: > domain names work? :: > There are some differences, but in many ways the domain :: names work the same. :: > :: > One difference is that in order for people to see New.net :: domain names they :: > must be either accessing the Internet through one of our :: many ISP partners :: > or they must have downloaded and installed our Web browser plug-in. :: > :: > If either one of these requirements is met, then New.net :: domains will work :: > just as you are used to .com and .net domains working. :: > :: > 3. Who is helping to shape New.net? :: > New.net has many partners who are working with us to make :: New.net domains :: > widely recognized around the world. Some of our current :: partners include: :: > Earthlink, NetZero, Excite@Home, .KIDS Domains, Inc., and MP3.com. :: > :: > Brian :: > :: > ----- Original Message ----- :: > From: "Brian Wallingford" <brian(a)meganet.net> :: > To: "Patrick Greenwell" <patrick(a)cybernothing.org> :: > Cc: "Paul A Vixie" <vixie(a)mfnx.net>; <nanog(a)merit.edu> :: > Sent: Tuesday, March 06, 2001 8:30 AM :: > Subject: Re: new.net: yet another dns namespace overlay play :: > :: > > :: > > On Tue, 6 Mar 2001, Patrick Greenwell wrote: :: > > :: > > : :: > > :On Mon, 5 Mar 2001, Paul A Vixie wrote: :: > > : :: > > :> :: > > :> [ this came from http://www.new.net/about_us_press.tp :: and appears not :: > to be :: > > :> a joke. its operational impact will not be felt :: today, but if it's :: > even :: > > :> moderately popular before it dies, operational :: impact WILL be felt. :: > i'm :: > > :> quite surprised by some of the folks they list as their :: > artners. --vix ] :: > > : :: > > :Too bad ICANN has been such a complete and utter failure that an :: > > :organization felt it necessary to start such a business, huh? :: > > :: > > Sounds like this was driven more by carelessness and :: greed than by :: > > necessity. :: > > :: > > ::

3 2

RE: Loose Source Routing
by Mark Borchers 06 Mar '01

06 Mar '01

One way to compromise on this without undue security risk is to allow source-routing one hop into your network but no further. > What are people's feelings on loose source routing? The general > sentiment around here is that it is a very evil thing. The > reason I ask > is that there is a certain network out there (who will remain > nameless) > who refuses to peer unless loose source routing is enabled. I can > somewhat understand their reasoning (they can reroute traffic on OUR > network as necessary) but the security implications far out way the > benefits. Not only this I'm not comfortable with an outside source > having control over routing on our network anyway. > -Dave > -- > +------------------------------+ > Dave McGaugh, CCNA > Peering & IP Backbone Engineer > Electric Lightwave, Inc. > E-mail: dmcgaugh(a)eli.net > Direct Dial: 360.816.3718 > Fax: 360.816.3522 > +------------------------------+ >

1 0

Snowstorm effects on Network Utilization?
by Kavi, Prabhu 06 Mar '01

06 Mar '01

A major snowstorm hit the Northeastern US yesterday and today, causing many businesses to close, particularly in the Boston area. I was just wondering about what effect this has on network utilization on backbone links in the northeast. * Does it decrease because fewer people have access to high-speed internet access? * Does it increase because many people get on the Internet at home? I would expect that many more people would telecommute during these events, causing high utilization on RAS systems. But would that translate into higher backbone link utilization, since most of the traffic would be local? Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720

1 0

RE: new.net: yet another dns namespace overlay play
by Steve Riley (MCS) 06 Mar '01

06 Mar '01

> One difference is that in order for people to see New.net domain names they > must be either accessing the Internet through one of our many ISP partners > or they must have downloaded and installed our Web browser plug-in. > > If either one of these requirements is met, then New.net domains will work > just as you are used to .com and .net domains working. I suppose, if you wanted to go to www.debbiedoesdallas.xxx and didn't care to install their plug-in (possibly for fear of someone logging your movements), you could just go to www.debbiedoesdallas.xxx.new.net instead.... _______________________________________________________ Steve Riley Microsoft Communications Consulting in Denver, Colorado steriley(a)microsoft.com +1 303 521-4129 (OLD mobile) www.microsoft.com/isn/ Applying computer technology is simply finding the right wrench to pound in the correct screw.

1 0