RE: new.net: yet another dns namespace overlay play

Mailman List Mirror (Read Only)
1

:: > 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

Using the stub config, you don't have to alter your root.cache.

Looking at their web site it appears there are two options for uses other
than browsers: stub the fake zones on your own server, or use their root
zone (local or remote copy, either way it's still their private root).

The original issue still exists in either case. If a user sends a query
for www.domain.xxx. -- and if that query is redirected to a "partner"
ISP's DNS servers for resolution (because the ISP has configed the client
this way via PPP or DHCP or whatever) -- then will the query be answered
with RRs for the fake TLD or will it be answered with new.net. CNAME or
DNAME answers/referrals.

Similarly, this is also a question for the browser plug-in: does the
"query" get changed to fake.xxx.new.net. or does it get passed in original
form to their root servers? We have been assuming the former but I'm not
sure that's what they'll be doing in light of the above.

The real question is "do member zones exist under the fake root or under
the new.net. hierararchy?" IE, is the fake root just providing referrals
to the new.net. hierarchy or is it really acting like a new hierarchy?

For mail processing purposes, referrals would seem to be the same way to
go, with all customers getting a 3LD under new.net, and also getting a 2LD
under one of the fake TLDs. Using a fake 2LD for daily operations would
require that everybody who ever wanted to send you mail had access to the
fake zone structure. Conversely, if it's just a web-branding thing, then
the fake zones via the web snapin would work okay (but ping and other
tools sure wouldn't).

I suppose this is more of a concern with how they are positioning it and
the expectations they are setting.

And voila: http://www.new.net/help_faq.tp#tc-9

"9. Can I use my New.net domain for email?
"We are currently working on an email solution to parallel our Web site
addressing system. In the meantime, you may send or receive emails at your
New.net domain by appending new.net onto your domain name.

"For example, if your New.net domain is www.pie.shop and you have chosen
self@pie.shop as your email address, you can use self@pie.shop.new.net as
your temporary address until your email software is published. We will
notify all domain name holders when that software is available."

This will collapse before too long. We should start a pool on how long
they last.