Re: [cobalt-users] dns and nameservers

[Jens Kristian Søgaard <jens@xxxxxxxxxxxxxxxxxxxx>]

Hi,

> This is how it was designed to work, and how it is supposed to work:

Ehm, not quite...

> 1) The interNIC registration for a particular Domain Name  list the
> 'registered' name servers in order they are to be tried:

Nope. The order listed has no meaning what so ever for the resolve process.

> 3) The whois information from the interNIC database is maintained and
> up-dated by a number of Tier 1 and lower name servers.

The WHOIS and DNS system are completely unrelated (programatically). When
looking up a name or ip-address, your dns-server will never lookup in the
whois system.

> 4) The modern browsers will work up-ward through the various name servers
> until they reach a response from a name server (potentially all the way to
> the interNIC database) until the browser receives a response directing it
to
> the domain's name server.

They won't ever be directed to a whois server. Instead the datas that are in
the whois are sometimes (a few times a day) also put in the configuration of
a few dns server, which are known as the "root servers" (these a known under
names as a.root-servers.net or b.gtld-servers.net)

> 5) The browser is supposed to (by original on-paper design) to also look
for
> the second or even third or fourth name servers for any particular Domain
> should the primary one fail to respond.  HOWEVER by practice most commonly
> used browsers will only look for the primary, and if it fails to respond
> then the browser will send  to the user an error response rather than look
> further for the secondary, etc name servers.

This is _not_ correct.

1) Browsers never do resolves on their own (well, I have yet to see one that
does) - this is handled by resolve libraries.

2) There is no rule that the primary server should be asked first. It is the
nameserver with the fastest reply that is contacted first! (i.e. so you will
presumeably ask the name server that is geographically near to yourself)

3) If the server contacted first should not answer, then the other name
servers are contacted too. This is the case on all systems (Windows, Linux,
Macintosh, etc). So I cannot understand, why you think it will stop at the
primary server...

> The Original reason for having the Name server and the Secondary Name
> servers on different servers and in different locations of the country was
> so that the Browser could get the needed final IP number of the requested
> Domain Name, and then route to that IP number, even if major portions of
the
> INTERNET was down for reason of calamity such as war (nuclear war).

That surely _sounds_ like a good reason, but I doubt it. If you check the
original RFC's (the ones where they talk about _how_ they imagine a name
server system could be built), then they say the following:

"   Another issue was the central vs. distributed implementation of the
   name look up service.  It is recognized that separate servers for
   each domain has administrative and maintenance advantages, but that a
   central server may be a useful first step.  It is also recognized
   that each distinct database should be replicated a few times and be
   avialiable from distinct servers for robust and reliable service."

So it is "administrative and maintenance advantages" they're looking for...
the same as today. The quote is from RFC805, dated 8th of February 1982.

--
Jens Kristian Søgaard, Mermaid Consulting I/S,
jens@xxxxxxxxxxxxxxxxxxxx,
http://www.mermaidconsulting.com/
* RaQ Support and Consulting