First of all: you read all the stuff before here right? You have to.
Before we really start this section I'm going to serve you
some theory on and an example of how DNS works. And you're going to
read it because it's good for you. If you don't want to you should at
least skim it very quickly. Stop skimming when you get to what should
go in your named.conf
file.
DNS is a hierarchical, tree structured system. The top is written
`.
' and pronounced `root', as is usual for tree data-structures.
Under .
there are a number of Top Level Domains (TLDs); the best
known ones are ORG
, COM
, EDU
and NET
, but there
are many more. Just like a tree it has a root and it branches out.
If you have any computer science background you will recognize DNS as
a search tree, and you will be able to find nodes, leaf nodes and
edges. The dots are nodes, the edges are on the names.
When looking for a machine the query proceeds recursively into the
hierarchy starting at the root. If you want to find the address of
prep.ai.mit.edu.
, your nameserver has to start asking somewhere.
It starts by looking it its cache. If it knows the answer, having
cached it before, it will answer right away as we saw in the last
section. If it does not know it will see how closely it can match the
requested name and use whatever information it has cached. In the
worst case there is no match but the `.' (root) of the name, and the
root servers have to be consulted. It will remove the leftmost parts
one at a time, checking if it knows anything about ai.mit.edu.
,
then mit.edu.
, then edu.
, and if not that it does know about
.
because that was in the hints file. It will then ask a .
server about prep.ai.mit.edu
. This .
server will not know
the answer, but it will help your server on its way by giving a
referral, telling it where to look instead. These referrals will
eventually lead your server to a nameserver that knows the answer. I
will illustrate that now. +norec
means that dig is asking
non-recursive questions so that we get to do the recursion ourselves.
The other options are to reduce the amount of dig produces so this
won't go on for too many pages:
$ ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; AUTHORITY SECTION:
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
This is a referral. It is giving us an "Authority section" only, no "Answer section". Our own nameserver refers us to a nameserver. Pick one at random:
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
mit.edu. 172800 IN NS BITSY.mit.edu.
mit.edu. 172800 IN NS STRAWB.mit.edu.
mit.edu. 172800 IN NS W20NS.mit.edu.
;; ADDITIONAL SECTION:
BITSY.mit.edu. 172800 IN A 18.72.0.3
STRAWB.mit.edu. 172800 IN A 18.71.0.151
W20NS.mit.edu. 172800 IN A 18.70.0.160
It refers us to MIT.EDU servers at once. Again pick one at random:
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 10562 IN A 198.186.203.77
;; AUTHORITY SECTION:
ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu.
ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu.
ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu.
ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu.
;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43
LIFE.ai.mit.edu. 21600 IN A 128.52.32.80
ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5
BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
This time we got a "ANSWER SECTION", and an answer for our
question. The "AUTHORITY SECTION" contains information about which
servers to ask about ai.mit.edu
the next time. So you can ask
them directly the next time you wonder about ai.mit.edu
names.
Named also gathered information about mit.edu
, so of
www.mit.edu
is requested it is much closer to being able to
answer the question.
So starting at .
we found the successive name servers for each
level in the domain name by referral. If you had used your own DNS
server instead of using all those other servers, your named would
of-course cache all the information it found while digging this out
for you, and it would not have to ask again for a while.
In the tree analogue each ``.
'' in the name is a branching
point. And each part between the ``.
''s are the names of
individual branches in the tree. One climbs the tree by taking the
name we want (prep.ai.mit.edu
) asking the root (.
) or
whatever servers father from the root toward prep.ai.mit.edu
we
have information about in the cache. Once the cache limits are
reached the recursive resolver goes out asking servers, pursuing
referrals (edges) further into the name.
A much less talked about, but just as important domain is
in-addr.arpa
. It too is nested like the `normal' domains.
in-addr.arpa
allows us to get the host's name when we have its
address. A important thing to note here is that the IP addresses are
written in reverse order in the in-addr.arpa
domain. If you have
the address of a machine: 198.186.203.77
named proceeds to find
the named 77.203.168.198.in-addr.arpa/ just like it did for
prep.ai.mit.edu
. Example: Finding no cache entry for any match
but `.', ask a root server, m.root-servers.net
refers you to some
other root servers. b.root-servers.net
refers you directly to
bitsy.mit.edu/. You should be able to take it from there.