DNS Support
  1. DNS overview
  2. Nameservers
  3. Resolution
  4. Configuration

DNS or Domain name service is the means by which domain names which humans understand get translated into IP addresses that computers understand. The Domain Name System is a distributed system. It does not reside on any one computer. There is a hierarchy to the organization of the servers, however which allows local servers to broaden their search for an answer to a DNS lookup request. These lookup requests are called "queries".


The Domain Name System is arranged in a hierarchy. At some point, there needs to be a central authority to direct the queries and register names. The primary nameservers are now under the direction of the US Government but are maintained under contract by Network Solutions. These "ROOT" servers perform the check to see if a domain is .com, .net, .org. or .edu, and pass the request to the appropriate name server that handles the zone in question. Netscape's nameservers would be listed for any


Examples of some of the Top Level Domains are .com, .org, .net, .edu, .mil, .gov and the Country Code TLD's (ccTLD's) such as .us, .uk, .jp etc. These Top Level Domains are handled by one of several main Network Information Centers given in the table below:

Network Information Center
Top Level Domain
.com, .net, .org, .edu
US Government NIC
www.nic.gov: .gov domains
Asian-Pacific country code domains: .jp, .cn, .kr, .ph
Eurpoean country code domains: .uk, .fr, .it, .gr

Note that there are other NIC's providing resolution for a variety of domains. Each NIC provides root resolution servers, as well as registration and whois databases.


Domain names such as netscape.com or yahoo.com are considered generic Top Level Domains. These domain names must be registered with an agent who has been certified by the appropriate controlling authority. In the United States, a list of accredited registrars for the .com, .net, .org, and .edu domains can be found at ICANN's website . Please register your domain first before requesting that Sprint perform DNS for you.



Client software applications perform queries to do their resolution. Nameservers also do queries, but if they are in charge of a zone, they actually do the lookup and translation. If a particular nameserver has an IP address stored in it's table for a particular name, it will respond to a client resolver with the IP address. If the nameserver does not know the answer, it will (if properly configured) ask another nameserver, sometimes even the ROOT nameservers.


There exists for each domain, a ROOT server. This server contains the registered nameserver for each second level or 'generic' domain such as sprint.com / sprint.net, etc. Who owns a domain, and what the servers are can be found by querying this root server for information. Keep in mind that most DNS nameservers store the results of past queries for a certain period of time. If the local DNS server doesn't know the IP address for the domain being queried, it will ask the ROOT server for that domain. The ROOT server will point the local server to another server which hosts resolution for the desired domain. The ROOT server can only do this however, if the owner of the target domain has registered a nameserver, and configured that nameserver to perform resolution.




Resolution is the process of turning a domain name or host name into an IP address or vice versa. Every client application contains a resolver. This means that your web browser, or your FTP software, or whatever Internet application you are using tries to resolve any name you type into it, into an IP address. This is called forward resolution. In some cases, an IP address is resolved back into a name. Looking up a name from an IP address is called reverse resolution.


Primary nameserver servers can be thought of as a Master server for DNS for a zone they are in charge of. The secondary nameserver can be thought of as the slave, or backup. In fact, this is how they are often described. The secondary DNS server performs a Zone Transfer from the primary, so it is indeed a slave pulling data from a master server. The Primary server is the server that was configured by a human being, and contains a complete record of the data for a particular zone.


An Authoritative server is a nameserver that possesses:

  1. A full copy of the zone file.
  2. The full set of host names and IP's for the domain/zone.
  3. A Start Of Authority (SOA) record naming itself as an authoritative server for the domain/zone.

Any nameserver which does not contain a full copy of the zone file for a domain is not authoritative for that zone. It is usually not possible for a server which is primary or secondary for a domain to NOT be authoritative for a zone. If a server is not answering "authoritatively" for the zone, then there is a mistake in that server's configuration. The most common errors are forgetting to properly format the SOA record at the beginning of the zone file.


If a Nameserver does not possess the answer to a resolution query, it will either query another nameserver or reply with "host not found" error message. Recursive servers continue to ask additional servers for an answer. Non-recursive nameservers check their own database and then stop.

A recursive server is a good server to point desktop clients to for Internet resolution. A non-recursive server is ideal for placing outside on the Internet for resolution of your own domain and nothing else.


Your domain's information is stored in one or more zone files on your authoritative server. This zone file defines all the public names and IP addresses you wish to be resolved. On a Berkeley BIND nameserver, the zone files are stored in database files. When these files are updated, and the server is reloaded, the new information takes effect.



Configuration of DNS requires writing resource records. In the case of BIND, you will also need to update the named.conf file (named.boot on older versions). All DNS systems use a serial number in the SOA record of every zone file to indicate the version of the file. Whenever making changes to the Zone file, you MUST update the serial number or your secondary servers will not update with the new information. Resource records define important information regarding your domain, such as where to send mail, and where your nameservers and webserers are.

We will cover resource records in two parts, the first supporting forward resolution, the second supporting reverse resolution.

FORWARD Resource Records

There are several types of resource records you will need to configure if you are performing Primary DNS. The examples listed below are for BIND 8.2.2. Please check the documentation of your DNS software if you have questions or require assistance.


"A" records are used to tell the nameserver which addresses correspond to which servers. Note that you can assign multiple host names to the same IP address using "A" records.

hostname.domain.com.	IN	A


An "MX" record is used to designate not only which server handles mail, but in which order these servers should be tried when attempting delivery. The DNS administrator writes in numbers before the name of the mail server to indicate the preference of that mail server. The server with the lowest number is most preferred and a server with a preference of zero will be preferred above all others. The preference is like creating a list of servers to be tried, in a particular order.

IMPORTANT: A mail domain (the @domain.com portion of an email address) must first be pointed to a specific host name, and that host must have an "A" record to be able to receive mail. You cannot use an IP address within an MX record. Please see the following example of a properly written set of records for a mail server:

domain.com.		IN	MX	10  mail.domain.com.
domain.com.		IN	MX	20  mail2.domain.com.
mail.domain.com.	IN	A
mail2.domain.com.	IN	A


"NS" or Nameserver records tell the client which server is a valid nameserver and for which domain. Nameserver records are only required if you are configuring the primary nameserver for the domain, or are setting up a sub-domain. As with Mail Exchanger records, a domain must be pointed to a specific host name, and then to an IP address to properly configure a domain to point to a nameserver.

domain.com.	IN	NS	ns1.domain.com.
ns1.domain.com	IN	A

To set up a sub-domain, you would need the following in your parent domain file:

Zone file "domain.com" (the PARENT domain)
sub.domain.com	IN	NS	ns1.subdomain.domain.com.

Zone file "sub.domain.com"
    sub.domain.com		IN      NS      ns1.sub.domain.com.
ns1.sub.domain.com	IN	A

Don't forget the SOA record in the sub-domain zone file.

REVERSE Resource Records

Reverse resource records match IP addresses to host names. The reverse addresses are always entered on the left hand side, and always in reverse order. The example below is working with the IP address block Note that some DNS systems automatically handle this reversal of the order of the octets for you. BIND does not.


A pointer record ties an IP address to a host name. Note the dot at the end of the lines listing the names. This is to prevent BIND from appending the text string "in-addr.arpa" to the resolved host name.		IN	PTR	ns1.sub.domain.com.		IN	PTR	ns1.domain.com.