Technical
Info
To resolve domain access requests you use 3 different kinds
of Servers:
1.) Root-Servers
There are 13 Public-Root Servers dispersed
across the globe. For instance the public
Root-Server at Amsterdam: a.public-root.com.
These machines only know
where the TLD-Servers for a certain TLD are. ( TLDs: the entire
Top Level Domain like .com .info .airport .news or .site.
2.)
TLD-Servers
TLD-Servers are machines like tld1.public-root.net and tld2.public-root.net. TLD-Servers
answer
authoritive for a TLD. That is why, when you look at a dig
report for e.g. .vangelis it comes
back as
two public TLD-Servers. tld1.public-root.net and tld2.public-root.net. These TLD
servers do not
know any IP numbers of web sites etc. The zone file of a TLD
server contains only addresses of
Name-Servers.
3.)
Name-Servers / Caching-Resolvers.
Name-Servers are machines like ns1.public-root.net and ns2.public-root.net. A Name-Server
translates a second level domain into an IP number. So a Name-Server
is authoritive for a set of
SLDs ( Second Level Domains like cnn.com or dating.area ) and knows exactly where these
particular web sites are. Name-Servers however are also
frequently used for another purpose. Access providers use these Name-Servers also to resolve requests
for their access traffic.
The Caching-Resolvers.
Reliability:
In order to increase reliability TLD-Servers
and the Name-Servers should not run
on the same machine. Using separated TLD-Servers, (like tld1tld1.public-root.net &
tld2.public-root.net) that will answer authoritive for one TLD
or a few TLDs, is the best solution.
These servers, of course on different locations and using
IP numbers from different ranges,
would serve ONLY TLDs which they are authoritive for - not
TLDs like .com or .us or anything.
In
this ideal situation, Root-Servers only answer authoritive
for the root, and point to the
TLD-Servers for a given TLD (like the public TLD Servers
for the TLDs which the servers are
authoritive for). So there will be no SLD zones on the TLD-Servers
- only TLDs. In case someone asks them where, for example, www.paris.city is, they will only respond
with the IP address of the Name-Servers which are authoritive
for paris.city e.g. ns1.public-root.netand ns2.public-root.net.
Those Name-Servers (The SLD Servers, if you will)
in turn will respond with the IP address of the host 'www.paris.city'
Cache
poisoning:
One server cannot (at least it most certainly should not)
perform two or more roles.
This, will eliminate any possibility for the occurrence of
cache poisoning throughout the root
system. That is why, for instance, tld1.public-root.netand tld2.public-root.net are two
TLD-Servers that not have its recursion on.
Quality
of service:
When people register an SLD with a Registrar, they will point
to the Name-Servers which are
authoritive for that SLD, just the same as they do now if
they register any domain through NSI
or anywhere else. Important is however that these TLD-Servers
and Name-Servers should not
be the same machines.
ISPs
are encouraged by TLD.NAME to operate Public-Root Servers,
but they MUST register and
sign contracts to guarantee public DNS services on those IP addresses.
In order to guarantee quality
of service, all Public-Root servers need to be checked and certified.
All providers will be encouraged to operate public Caching Servers
merely by changing their 'hint
files'.
Redundant:
TLD servers like tld1.public-root.net and tld2.public-root.net are currently
totally redundant.
These servers are running at 2 different locations and have
IP numbers from two different
IP ranges. IP 84.22.100.6 and 84.22.106.31. All TLD-Servers
need to be 100% redundant.
Plug-in:
TLD.NAME has a tool available
that enables every Internet user to see the whole Internet
without changing their DNS settings. This tool works with
almost all Windows versions.
Coverage:
The Public-Root is running public DNS Servers in almost every part of the
world.
Public-Root also provides coverage in areas of the world that have typically
been ignored.
Conclusion:
When a Name-Server gets a request for a domain name (witch
is not in the zonefile of the
Name-Server itself) it will consult a Root-Server ( It will
pick a random Root-Server from its
hint file ). The Root-Server will be asked where the TLD-Server
is and then the TLD-Server is
asked where the SLD-Server is and then the SLD-Server yields
the IP address of the host
(often 'www').