Let's start with an example: If you ask your local name server for the address of "www.north-america.example.com" the name server will do the following:
1. Check to see if it already knows the address of "www.north-america.example.com"
(let's assume it doesn't. The example is more interesting that way.)
2. The DNS server queries a "root" server for the address of "www.north-america.example.com". All fully-functional DNS servers are configured with a static list of root servers, available at ftp://ftp.rs.internic.net/domain/named.root.
3. The root server will refer your DNS to a list of ".com" servers.
4. Your DNS will query one of the ".com" servers for the address of "www.north-america.example.com"
5. The ".com" name server queried refers your name server to a list of name servers for "example.com".
6. Your DNS server then asks one of the "example.com" name servers for the address of "www.north-america.example.com".
7. One of two things can happen here. If the "example.com" name server queried knows the address of "www.north-america.example.com" then it returns that address to your DNS server. If the "north-america" subdomain has been delegated to some other name server(s), then that name server list (of name servers that service the zone, "north-america.example.com") will be returned to your DNS, and your DNS will query one of those servers for the address of "www.north-america.example.com".
Note that your DNS remembers, or caches, all the information it retrieves this way. Therefore, if you asked your local DNS for the address of "ftp.north-america.example.com", then it would directly ask the name server finally referenced in step 7 (above) for the address of "ftp.north-america.example.com". This prevents the top-level and root servers from being more heavily loaded than they already are. (It's also interesting to note that the root servers are also the top-level domain servers for the US domains.) It is possible to set up a caching-only DNS server that processes and caches requests, but isn't directly knowledgeable ("authoritative") about any domains itself.
Domains, Zones, and Authority
There are several different types of name servers. There is one Primary name server for each domain or delegated subdomain ("zone"). A "zone" refers to the domain and subdomain(s) (if any) a server is authoritative for. In many cases "zone" and "domain" mean the same thing, but when you start delegating authority for subdomains, they get their own zone to administer, although it's part of your domain. For example, the root servers are authoritative for the ".com" zone but they aren't authoritative for the entire ".com" domain. "example.com" is, in fact, a subdomain of the ".com" domain, but is a different DNS zone. Zone boundaries typically follow administrative control boundaries: since the people managing the ".com" domain are not the same as the people managing the "example.com" domain, a new zone is created and authority for the zone is delegated to that zone's name servers.
Every Primary name server should have at least one Secondary name server. A Secondary name server simply copies the zone information from the zone's Primary server. Secondary name servers also answer DNS requests authoritatively. It is strongly suggested that at least one secondary name server be on another physical network. If someone wants to send you mail, and your mail server is unreachable, the mail is queued and retried, but eventually delivered. If the sending mail server is told there is no mail server or host information about your network (which is what happens if all authoritative DNSes are unreachable) then the mail bounces.
If you set up a Primary name server, it is necessary to have the parent domain delegate authority for your zone to you. For example, if you wanted to be the authoritative name server for the domain "reallyslow.net", you would have to ask the administrators for ".net" (InterNIC, in this case) to delegate the zone authority for "reallyslow.net" to you. Similarly, if the engineering department wanted to run there own name server for "engineering.reallyslow.net", then they would have to ask you to delegate the zone "engineering.reallyslow.net" to their name server(s).
It is usually possible to look up an address and come up with a machine name. This is called a "reverse lookup," because instead of getting an address from a name, you are getting a name from an address. The reverse lookup system behaves very similarly to "normal" DNS; in fact, you could almost consider it to be a parallel DNS system. Lookup is done in reverse order by octet with the domain "in-addr.arpa" appended. Let's say you "own" a network 192.168.45.0 with a subnet mask of 255.255.255.0. You would contact the administrator for "168.192.in-addr.arpa" and ask him/her to delegate the authority for the zone "45.168.192.in-addr.arpa" to your name server. On your name server you would create a zone file for reverse lookups that would be authoritative for that zone.
Types of DNS Records
SOA: A Start of Authority record is used at the top of every zone file to indicate the
zone that the file is authoritative for. The SOA record also contains administrative
contact information, the serial number for the file (which must be incremented whenever
the file is updated), and various default timeout and retry values for the domain.
reallyslow.net. IN SOA turtle.reallyslow.net root.reallyslow.net ([various numbers])
A: Address records actually provide name-to-address mapping:
turtle.reallyslow.net. IN A 192.168.45.10 caterpillar.reallyslow.net. IN A 192.168.45.12
CNAME: Canonical name records are "alias" records that are often used to map conventional
names like "www.reallyslow.net" to the actual name ("A" record) of the computer providing
World Wide Web services for the domain. Other names use by convention include "ftp." for
ftp services, "mail." for e-mail servers, and "ns" for name servers.
www.reallyslow.net. IN CNAME turtle.reallyslow.net. snail.reallyslow.net. IN CNAME caterpillar.reallyslow.net.
NS: Name Server records indicate which machines are used as name servers. NS records
sometimes point to host names ("A" records), sometimes point to aliases ("CNAME" records),
and sometimes just list an IP address.
reallyslow.net. IN NS turtle.reallyslow.net. reallyslow.net. IN NS snail.reallyslow.net.
MX: Mail eXchanger records indicate which machines are mail servers for a domain and
what their preference is. The lower the number, the higher the preference (hey, I didn't
invent it.) Other mail
servers will try to send mail to the highest preference mail server first. We want
email for firstname.lastname@example.org to be delivered to the machine mail.reallyslow.net:
reallyslow.net IN MX 10 mail.reallyslow.net.or, if you used another company to handle your email services...
reallyslow.net IN MX 10 mail.notquitesoslow.net.MX records should not point to CNAME records.
PTR: Reverse lookup pointers are used by the reverse lookup system to map addresses
to names (notice the reversed order of the octets:)
10.45.168.192.in-addr.arpa. IN PTR turtle.reallyslow.net. 126.96.36.199.in-addr.arpa. IN PTR caterpillar.reallyslow.net.
Note that host names never include "@" symbols. An "@" symbol almost always indicates an email address [one notable exception being a message identifier for a Usenet newsgroup posting. Tks again B.B.] The name to the right of the "@" sign is queried for an MX record and mail is delivered to the machine indicated by the MX record(s). In a DNS file, the "@" symbol is a placeholder used to represent "the current domain" as it was named in named.boot. named.boot is the standard file name used by DNS ("named", pronounced "name dee") servers. A basic named.boot looks like this:
primary reallyslow.net db.reallyslow.net primary 0.0.127.IN-ADDR.ARPA db.127.0.0 primary 45.168.192.in-addr.arpa db.inaddrWe're telling BIND that it is authoritative for the "standard" zone "reallyslow.net", and also primary for the reverse lookup zones for the subnets 192.168.45.x and 127.0.0.x. (The only entry for 127.0.0.x is 127.0.0.1, which maps to LOCALHOST, which is a reserved address and name for "this machine". In other words, you will always have a VERY fast ping to localhost :-) The zone file for 45.168.192.in-addr.arpa contains standard PTR records after the SOA record. Note that it's really easy to forget to update named.boot if you add a new domain to your name server (hint, hint.)
If you are going to set up your own name server, I highly recommend the book
DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly & Associates,
ISBN 1-56592-010-4). On the 'net, check out the "BIND Operations Guide"
in Windows Write format at
Next: Tips for Building an IP LAN