[ncdnhc-discuss] Re: About Alternative Naming Scheme: (was before Re: [ncdnhc-discuss] Re: Why is "Marketing ccTLDs as generics"on NC Agenda?)

[Jonathan Weinberg]

Vany --

         The detailed technical information about how an ISP administrator 
running Unix can resolve new.net names is found in 
<http://www.new.net/help_isp_info.tp>.  For easy reference, here is a 
portion of that page.

 >>>>>>>
ISP Network Administrators:
ISP's who would like to provide their users with immediate access to 
New.net's™ domain names may do so by making one simple change to your systems.
On each recursive nameserver that is serving clients, you may implement any 
one of the options described below, assuming that you are using BIND on a 
Unix box (if you are not, then please email us for further information at: 
isp at New.net). Each of the following methods is roughly equivalent, with 
each having a minor advantage or disadvantage over the others. It is 
entirely up to you which you 'd like to pursue.
After you've activated your network for New.net domains, we'll give your 
service free promotional placement on our site. All you have to do is email 
your logo to us and once we've verified that you've made the necessary 
changes, we'll post your logo.
First, please note that "BIND config directory" refers to the directory 
listed in an options statement such as "/var/named" here:
options {
directory "/var/named/";
}
Here are four options you can choose from:

1. Our preferred solution is that you use a list of stub zones to 
supplement the ICANN roots with New.net domain extensions.
For this option, do the following:
Download ftp://ftp.New.net/domain/bind/root-stubs.conf into your BIND 
config directory.
Append the following line to your /etc/named.conf:
include "root-stubs.conf";
Reload the BIND configuration with the command "ndc reload".
The list of stubs is expected to change up to once per month. You may wish 
to set up a process to mirror root-stubs.conf weekly from New.net and 
reload your nameserver if you use this method.
2.Replacing the root.cache file with one that lists our new root servers.
In /etc/named.conf, find the filename for ".".
zone "." {
type hint;
file "named.root";
};
This file will be in the BIND config directory. In this case, it would be 
"/var/named/named.root". Download ftp://ftp.New.net/domain/bind/named.cache 
and overwrite the contents of that file with it.
Your server will grab a new list of root servers from those listed in the 
hints file every time it starts up, and will use those for all queries.
3. Alternatively, you may slave the root zone, ".", from a master DNS server.
Download ftp://ftp.New.net/domain/bind/root-slave.conf into your BIND 
config directory.
In /etc/named.conf, find the section listing hints for ".", the root zone.
They will look something like:
zone "." {
type hint;
file "named.root";
};
Delete that section, and insert in its place:
include "root-slave.conf";
Reload the BIND configuration with the command "ndc reload".
This will slave a copy of the root zone from a New.net master nameserver. 
Your server will remain in sync with ours automatically.
4. Fourth, if you have a mechanism already in place to publish 
authoritative zones to all of your servers, you can use it to also publish 
".".
You will need to daily or weekly grab a copy of 
ftp://ftp.New.net/domain/root.zone and publish it to your nameservers with 
the zone name of ".".
The root zone is nothing special as far as BIND is concerned. If your 
nameservers know the information contained within it, they will not need to 
query our servers for that.
Please note, if your company does not have a mechanism for change control 
publication, then you should not be considering this option. But if you do 
have such a mechanism, then the method is to simply publish to root zone 
information gathered from our ftp location , and publish as you would for 
any other zone that you are authoritative for.
We highly recommend that you check our ftp for updates regularly, and in 
any event at least twice each week.
 >>>>>>>
         I did read the email you sent articulating your concerns to the 
NC; indeed, it was reading that message that prompted my comment, 
yesterday, that "the questions you raise about [new.net] (relating, among 
other things, to the possibility of conflicts and the fact that the names 
do not universally resolve) apply no more strongly to them than to any 
other alternate root."

Jon


At 11:16 PM 10/4/2001 -0400, Nilda Vany Martinez Grajales wrote:
>Hi Jonathan and Dave:
>
>The information I described in my previus e-mail I took it from New.net
>home page, except for the masquerading part.
>The ISP has to upgrade their networks.  What they call upgrade their
>networks is simply add some lines to the a file named resolv.conf if the
>ISP is using linux.
>If the ISP provided of an internet user still doesn't resolv new.net
>domain names, then they have to install a software or provided by
>new.net.
>Again, New.net (and also other companies that are doing the same as
>New.net), are not Alternate Roots...because the Root they are using
>actual DNS structure in order to offer TLDs.
>That New.net could be an innciative for expanding the domain name
>space...maybe yes (maybe not)...but never an alternate root.
>If you have read the answer I gave to Bill, the item 8 of the NC
>teleconference agenda will become in "TLDs not created by ICAAN:  An
>attempt to expand the domain name space or creates confusion".
>Did you read the e-mail I sent today about the concerns I raised in the
>NC two moths ago?
>http://www.icann-ncc.org/pipermail/discuss/2001-October/000342.html
>
>Best Regards
>Vany
>
>
>
>
>Jonathan Weinberg wrote:
> >
> > At 12:26 PM 10/4/2001 -0700, Vany Martinez wrote:
> > >Jonathan:
> > >I have never asked to talk about Alternate Roots.
> > >Again this was another confusion from who draft the
> > >agenda.
> > >Let call with proper names the things:
> > >1.  An Alternate Root involves a server independent
> > >from the actual roots that is resolving TLDs (.TRAVEL,
> > >.GAME, .KIDS, etc, for example) different than the
> > >ones created by ICANN, without using any technology of
> > >masquerading an existent domain name within the actual
> > >existent TLDs (.COM, .ORG, etc...).
> > >2. The subject I am addressing is not Alternate Roots.
> > >The subject I am addresing is the launching of
> > >services as New.net and other Companies that uses and
> > >masquerades actual domain names inside TLDs as .ORG,
> > >COM, etc...in order to provide domain names inside
> > >TLDs as .TRAVEL, .GAME, .KIDS, etc... If New.net want
> > >to call themselves an Alternate Root, then is a bad
> > >definition because they are functioning under the
> > >actual Roots, maquerading existent domain names as we
> > >know them to provide new TLDs, etc...And, such TLDs
> > >are not resolved by everybody...only those who has the
> > >software they download or the ISP has upgraded their
> > >networks by adding some lines to their DNS
> > >configuration, are the ones that are able to resolve
> > >such domain names.
> > [snip]
> >
> >          Actually, I think this misdescribes new.net.  Yes, they offer
> > users a plugin that maps aaa.bbb to aaa.bbb.new.net.
> > But it doesn't appear
> > that the ISPs who partner with them are using that technique; rather,
> > they're simply pointing to a set of new.net alternate root servers.  See
> > <http://www.new.net/help_isp_info.tp>, which indicates that an ISP can
> > resolve new.net names by (among other things) replacing its root.cache file
> > with one that points to the new.net root servers.  So they are using *both*
> > of the two technologies you describe above.  And fwiw I think the questions
> > you raise about them (relating, among other things, to the possibility of
> > conflicts and the fact that the names do not universally resolve) apply no
> > more strongly to them than to any other alternate root.
> >
> > Jon
> >
> > _______________________________________________
> > Discuss mailing list
> > Discuss at icann-ncc.org
> > http://www.icann-ncc.org/mailman/listinfo/discuss
>_______________________________________________
>Discuss mailing list
>Discuss at icann-ncc.org
>http://www.icann-ncc.org/mailman/listinfo/discuss