Daryl's TCP/IP Primer

Addressing and Subnetting on the Near Side of the 'Net

[<--Prev] [Next-->]

[Printable Version] [Daryl's ColdFusion Primer] [About Daryl]

Web	ipprimer.com

Daryl uses Mozy for his online backups.

12. The Domain Name System (DNS)

The Domain Name System, or DNS, is a service that translates computer names into IP addresses. A name-to-address system is necessary because we humans do not easily remember numbers like, "207.68.156.61", but we can easily remember names like, "www.microsoft.com". The DNS is a hierarchical system, with the top of the system called the "root", and represented by a single period ".". There are twelve (very, very busy) "root" servers on the Internet at the time of this writing. Root servers know where the servers are for the "top-level domains" like .com, .net, .edu, .org, .uk, .de, .nz, .us, and so on.

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 anyone@reallyslow.net 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.
12.45.168.192.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.inaddr

We'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 ftp://ftp.software.com/BIND-NT/BOG.wri.

Next: Tips for Building an IP LAN