Take the magic out of mapping
How does Domain Naming Service map user-friendly Internet addresses to computer-friendly numeric addresses?
By Al Berg
When you look for the latest networking news, remembering to point your browser at www.lantimes.com is a lot easier than remembering the site's numeric IP address. But if you examined the packets that pass between your browser and the LAN Times site, you'd see that it's 184.108.40.206 in the packet header that guides your requests through the Internet labyrinth.
Domain Naming Service (DNS), an Internet protocol and distributed database, provides the mapping between these disparate addresses. Having a basic understanding of how DNS works is key to successfully administering an Internet-connected network.
First we need to take a quick look at the structure of Internet host names. The last portion of a host name, such as .com, is the top-level domain to which the host belongs. In addition to the .com domain, there are six other top-level domains assigned by InterNIC, the coordinating body for Internet name services.
If your site is outside the United States, the organization that assigns domain names has its own standards. In most cases, top-level domains for non-U.S. hosts look something like .co.uk or .ac.uk, which indicate a company or academic institution in the United Kingdom.
At the top of the DNS database tree are root name servers, which contain pointers to master name servers for each of the top-level domains. For example, to find out the numeric address of www.lantimes.com, a DNS server would ask the root name server for the address of the master name server for the .com domain.
In turn, the master name servers for each of the top-level domains contain a record and name-server address of each domain name. So in trying to find out the numeric address of www.lantimes.com, the DNS server asks the .com server for the name of the server that handles the lantimes.com domain.
The individual name servers for each domain name, such as lantimes.com, contain detailed address information for the hosts in that domain. So in our example, the DNS server then asks the lantimes.com server for the name of the server that handles the lantimes.com domain.
Finally, this most specific name server supplies the DNS server with the IP address of the machine called www.lantimes.com.
Providing DNS to your users is an important part of linking them to the Internet. There are two basic ways to configure DNS. One option is to use your ISP's (Internet service provider's) DNS server. Many ISPs will let you do this. Another option is to set up a DNS server on your own network.
If your network-support staff is small and your needs are simple, having your ISP provide DNS services is the best option.
There are three steps to this process. First, have your ISP inform the InterNIC that it is providing both primary and secondary DNS services for your organization.
Second, your ISP will give you the numeric IP addresses of the primary and secondary DNS servers, which you'll need to configure your users' TCP/IP stacks. You can do this by entering the information manually either at the desktop or at your Dynamic Host Configuration Protocol (DHCP) server.
Finally, you need to tell your ISP about the DNS records that you wish to publish to allow outside users to interact with your network.
In addition, if you want to receive E-mail from the Internet, you will need to have a Mail Exchange (MX) record for your domain in your ISP's DNS database. MX refers to a machine that accepts E-mail con-nections for your domain.
An MX record has three parts: your domain name, the name of the machine that will accept mail for the domain, and a preference value. The preference value lets you build some fault tolerance into your mail setup.
Your domain can have multiple MX records, such as the following:
Acme.com mail.acme.com 0; Acme.com mail2.acme.com 10; and Acme.com mail.isp.net 100.
In this case, mail delivery will be attempted to mail.acme.com first because it has the lowest preference value. If delivery fails, mail2.acme.com will be tried next. If mail2 is also down, mail will be sent to a relay host called mail.isp.net, which in this case is at Acme's ISP.
If you plan to use your ISP's DNS server, you'll also need to have the ISP set up some A records, which associate IP addresses with computer names. Each of the computers mentioned in your MX records needs an A record to associate them with an IP address.
You may also want to set up A records for each of your workstations if your users need to use ftp (File Transfer Protocol) to download software from the Internet. This is because some ftp sites perform a lookup to get the DNS name of the machine from which they receive download requests. If the machine has no name, the sites deny the request.
You'll also need A records for any public servers you maintain. For example, if you have a World Wide Web server, you'll need to have the ISP set up an A record linking the name www.acme.com to the IP address of your Web server.
If your ISP does not provide name services or if you need to have a DNS server at your site to support internal networking applications, the first thing you need to know is that you must have at least two name servers--a primary and a secondary.
This is because the InterNIC will not grant you a domain name unless there are at least two DNS servers on the Internet with information about that domain. Another reason for a second server is that you really need the fault tolerance a second name server can provide. If your one and only DNS server goes down, users will be cut off from the Internet.
Some sites take a middle-of-the-road approach and use an onsite DNS server as well as their ISP's. Because maintenance of the domain names is done at the primary name server, choosing which one is primary and which is secondary is quite important.
If you choose to administer the primary name server yourself, keep in mind that you'll have to maintain the DNS records.
If you choose to have a secondary name server onsite, your ISP will do all of the work, and your secondary name server will simply download the data about your domain from the primary server periodically.
Why should you bother with having a DNS server on your LAN in the first place? There are a few reasons.
First, if you are running IP network-based applications inside your network that require users to connect to internal machines by name, it is not a great idea to advertise the names and addresses of these machines. DNS can give hackers a map of your network, so setting up an internal DNS server that does not publish information to the world is a good idea.
Second, a DNS server inside your network lets you be the master of your own domain. You can make changes, additions, and deletions on your own schedule.
Finally, name resolution will be faster for your users because your DNS server is probably not as heavily loaded as your ISP's server.
Now that you've got the basics of how DNS works, you stand a much greater chance of successfully administering your Internet-connected network.
DNS and BIND, 2nd Edition
Introduction to DNS