RE: [cobalt-users] .med tld - which method is best?

[jale@xxxxxxxxxx]

At 09:21 AM 2/24/2003 -0500, you wrote:

> > OK there are two options, as the new tlds are not
> > yet on root-servers.
>
> Nor are they likely to be in the foreseeable future.

I found the write-up below on new.net - I am thinking of using option #3 - 
does anyone see this as bad, should I use one of the other ones for any 
particular reason? Any reason doing this at all is bad? I don't need the 
new domain name that much, but for my industry it would be nice to use.

Thanks!!
Jale

(sorry for any formatting issues, removed the HTML stuff)

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@xxxxxxx). 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.