> >In other words, if there were to be established a viable non-ICANN root
> >system, then all this effort to establish advisory committees, Supporting
> >Organizations, WIPO rules, ADR, taxes/fees, etc would all exist only on
> >those things willing to voluntarily accept the rules derived from the
> >ICANN root (and possibly the ICANN TLDs). Everyone and everything else
> >would be exempt.
...
> Which certainly has its appealing aspects. But 'splain something: I'm
> sitting here on, say, a xxx.com or a xxx.net ISP, and I want to search a
> .per or a .biz
In general we need to begin by distinguishing between the typical end user
machine and an intermediary machine that I'll call a resolving server.
In general when one configures a user machine one of the configuration
parameters is one or more IP addresses for one or more resolving servers.
(This is often done via DHCP, so the user never even sees it happening.)
These intermediary servers do the real heaving DNS lifting on behalf of
the end user machines.
These intermediary machines are usually operated by an ISP or a corporate
or organizational administration. Some of us techies run our own.
In any case, these intermediary machines are where the knowlege of which
root system to use is to be found. Generally this is a file named
"named.cache", or "cache.db" or something like that.
I'll attach a copy of a commonly used one at the end of this note.
This file tells the intermediary server what root servers to use.
If the intermediary uses a file that lists root servers that know about
.per and .biz, as well as the normal TLDs, .com/.edu/.net/.org ... and the
various ccTLDs, then you will have no problem resolving any name in any of
that set of TLDs.
If the intermediary uses a file that lists root servers that don't know
about the TLD you are uttering in your query, then you will get an answer
that says "we dunno".
It all comes down to what I have been calling the "inventory" of TLD
references that are adopted by the operator of the root server group which
your intermediary server points to.
If the root server group operator has a big inventory, you can resolve
lots of TLDs. If the root server operator has a small inventory, your
name resolution experience will be diminished.
It takes only a short period of time (usually tens of seconds) to re-aim
one of those intermediary servers from one root system to another -
generally one simply copies a new cache.db file and then executes a very
simple three word command.
As a general matter, those who operate root or TLD servers do not allow
those servers to accept "recursive" queries. Rather the work of walking
down through the DNS label hierarchy is expected to be done by the
intermediary server and not by the root or TLD servers.
That may be a bit cryptic, but it means that as a general matter, an end
user computer needs to use an intermediary server that is willing to do
the "recursion". Fortunately virtually all intermediary servers are
willing to do this.
But it does mean that the end user tends to have to select which root
server group (and hence the inventory of TLDs) by the indirect method of
selecting an intermediary server that, in turn, points to the desired root
group.
It is easy and relatively inexpensive, however, to set up intermediary
servers. The main problem typically being administrations that have
firewalls that limit the passage of outgoing DNS queries to packets
originating from a limited set of machines. In those cases, some
additional doors may have to be configured into the firewall.
Much of this may sound a bit complicated. But it's really not all that
hard to do in practice.
Below is a copy of the file that intermediary servers use to find the
"legacy" set of root servers.
To change the roots that one uses, one simply drops in a different version
of this file and pokes the DNS server software to say "new configuration
is available, use it".
(An somewhat different method, which I won't get into here, and which is a
bit harder, but more flexible, is for a user with a box with a real
operating system, to run their own root with their own favorite inventory
of TLDs.)
--karl--
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File
