On 5/20/06, Aaron S. Joyner <[EMAIL PROTECTED]> wrote:
I'm really surprised no one else has picked up this thread and run with
it. :) Both Jon and Tanner had good answers, so I'll send them both a
T-shirt (let me know your size and color preference, privately if you
prefer). I'll point out some common misconceptions from their answers,
and pose some additional thinking points. Jon and Tanner, give it a day
or so before you respond, if you'd like to. :) If things aren't
completely fleshed out by Monday evening, I'll try to remember to hit
this thread again and tidy up the loose ends.
Ok, so it's been 47 hours now, so I'll go ahead and respond. :-)
1) whois is not used by DNS in any manner, what so ever. It's used by
humans, as a database maintained by the registrars, of contact
information for a given domain. If I want to look up the name servers
for a domain, I should use host or dig (no, you really shouldn't use
nslookup, but it would work :) ). If I want to look up who to contact
about that domain, I should use whois. Well, I'd probably trust the
You are correct, mostly, except that I think you give too little import
to your second point -- "as a database maintained by the registrars".
To illustrate my point, I'd like to highlight just how DNS works.
So, what happens when you, say, tell your web browser to go to
http://www.trilug.org/? First off, your computer has no idea what
www.trilug.org should be. So, it goes and asks the nameserver
that it is configured to use. This, among other things, is generally
a caching server, but let's assume for the moment that www.trilug.org
is not in the cache. All caching nameservers are configured with a
list of root name servers. If it doesn't have a hostname in its cache,
it first picks one of the root name servers in its list and asks them.
Now, ideally, a root nameserver, or alternatively a name server that
responds authoritatively for "." would look at the last part of the
hostname
and say, "I don't know, but go ask the ORG nameserver at this IP
address". What generally happens in practice, though, is that most
root nameservers are also nameserver for .com, .org, and .net too,
so it will skip over the .org part and see trilug.org. From here it
says,
"I don't know, but go ask the TRILUG.ORG nameserver at these
IP addresses."
Now, here is the question? How does it know what IP addresses
to give for trilug.org. If you know the address of a nameserver for
trilug.org you can query that to get it's list of nameservers, but
generally the root nameservers do *not* do that. So, where do they
get the list of nameservers for any given domain? The answer is
given by Aaron's mention above of "as a database maintained
by the registrars". That's where the nameserver fields in whois
information goes. If you change that information, Verisign, who
runs the root nameservers, updates the root nameservers with
that information from whois every 12 hours.
Now, after being told where to go by the root nameserver and
querying a trilug.org nameserver, in addition to returning
a CNAME record (Canonical Name, or in other words, a nickname
or alias) and an A record (Address record) for talon.trilug.org
(where the www.trilug.org nickname points) in the "Answer section",
it also returns an "Authority section". In the authority section,
it gives it's list of nameservers. Note that these nameservers
do not, in fact, have anything to do with those from the whois
information that the root nameservers use. These, however,
take precedence over any earlier answers. So, if you wanted
to, you could turn the trilug.org nameserver provided by the root
nameserver into a "delegating nameserver" just like the root
nameservers, That is, instead of providing an authoritative answer
to query, it instead says, "I don't know, but go ask this nameserver
over here" just as the previous nameservers did.
Finally, since name server TTL (time to live) values should be
at least, if not more, time than cname or A records TTLs, if a
record times out, the caching nameserver should still have
the nameserver record in its cache and can just go ask it
directly without going through the root server again.
So, this is why I mentioned the whois information in my previous answer.
email contact listed in the SOA more, but if I needed more traditional
contact methods, ala name, phone, address, whois provides that. How
would I use host or dig to find out what the delegating entity believes
my name servers are, ie. instead of the whois command Jon suggested:
`whois trilug.org`?
As I mentioned before, they are returned with any query in the
"Authority Section" of the DNS response. You could also query the
NS values directly by doing "host -t ns trilug.org" or "dig ns
trilug.org".
2) Neither Tanner nor Jon touched on who you actually need to contact to
update the information in the "whois" record. There's a good buzzword
name for that company or entity, which I'm sure they both know, but
neglected to mention directly.
As Ian mentioned, that would be your registry. That used to be only
Network Solutions but when the system was opened up for more
registries they distributed the whois information. Verisign (who bought
Network Solutions), however, maintained control over the main root
nameserver. This is how, a couple of years ago, they started redirecting
mistyped domain names that weren't registered to their own
web page saying "buy this domain". Instead of returning "unknown
domain" to something like "unregistereddomainanme.com" they would
return an A record for their web server. This upset MANY people because
it broke a LOT of assumptions, not the least of which was that an easy
spam check is to see if the return address domain exists or not, and
one of the main things to come out of that was an option in bind to
delegate certain domains as "delegation only". That is, bind, when
it goes to a nameserver for a particular portion of a hostname, say "com"
can be configured to only accept a delegation response (that is, a
response
that's like the ones above, "I don't know but ask this nameserver over
there.").
3) Nobody touched on this fun and interesting angle: Can you do it with
out talking to that entity, and what interesting things happen if you
try? (hint: this more often happens by accident)
Yes. As I mentioned above, the list of name servers returned by
a nameserver doesn't have to match those in the root nameserver's
list at all. The ones in the root nameserver's list, however, do have to
be running a nameserver and know where to send you (i.e. at least
one need to be able to send you to a nameserver other than the root
nameservers) or else your hostname won't resolve at all.
4) Neither of them mentioned if any updates would be required to
secondary servers?
Yes, that's one of the functions of the SOA field. When you change
the serial number of the SOA serial number field (which generally
follows the convention of a date: YYYYMMDDNN, where NN is an
ascending tag for each change made that day, but nothing at all
says it has to follow that convention; you could just as easily just
increment the value each time you changed a domain's information),
a secondary nameserver compares the SOA serial number field
with the one it has and if the one on the primary is greater than the
one it has, it updates. The primary can also send the secondary a
signal asking it to do the comparison right now so that a secondary
isn't out of date until the SOA TTL expires.
5) Much attention was given to the SOA, the authoritative name server
mentioned in it, and it's TTL. What role do each of these parts play?
What do slaves use to determine who to pull the zone from? How do they
decide to get a new copy of the zone? What roles does the SOA play to
persons other than the secondary?
Ok, so is it obvious that I'm answering each section sequentially,
since I just answered that question. :-)
If a good answer comes along to all of these, I might feel compelled to
toss out another T-shirt. If not, I'll be sure to eventually answer all
my own questions for the curious minded folks. :)
This has been an excellent series of questions. I may have to
come up with a few of my own on a different subject and see if
we can get a few more people to answer. :-) (Hint to people:
if you're wrong, that's ok, the purpose is to get discussion going,
not whether you're right or not. If you don't know, just remember,
even easy things have to be learned.)
