WatchGuard


Republished with permission of WatchGuard Technologies. Originally published 16 May 2003.

DNS 101

By Fred Avolio, President, Avolio Consulting, Inc.

If you type www.watchguard.com into your Web browser’s address window, your computer connects to a system with that name at WatchGuard Technologies (assuming your machine is on a correctly configured and connected network). What magic directs the client software on your computer to connect to the correct server somewhere out there on the Internet? That's part of the job of the Domain Name System (DNS). This article provides an introduction to the wonders and hazards of DNS, the network service without which the Internet would not work.

Addressing

DNS is about one computer finding another, by address. Every computer on an Internet Protocol (IP) network has at least three addresses:

  • The media access control (MAC) address. The MAC address is irrelevant to a discussion about DNS, so let's skip over it.
  • The hostname. The hostname is the name we are most used to and that we use more than any other address. In my opening example, the host name is www.watchguard.com.

  • A 32-bit IP address. For an internetwork, the most important piece of information is the IP address. The 32-bit IP address is represented by four decimal numbers, or octets, separated by periods. The IP address for www.watchguard.com, as I write this article, is 206.253.208.100.

So, using DNS, a computer associates www.watchguard.com with IP address 206.253.208.100, looks for a route to that address, and sends the packets along to the router that claims to be able to deliver them.

History

In the 1980s, the original Internet was the ARPANET, named for the funding sources, the Advanced Research Projects Agency of the United States Department of Defense. ARPANET was later renamed DARPA, the "D" standing for "Defense". But that early ARPANET was a place where everyone knew everyone else -- literally. A single file was all that was needed to tie easy-to-remember hostnames to their numeric IP addresses. Every day, computers automatically downloaded the latest Internet hosts file from a central repository in case ARPANET had new members or machines had changed location or been removed. Over time, this file grew to unmanageable size.

In 1983 the University of Wisconsin developed DNS, a dynamic and distributed naming hierarchy. So, instead of hostnames like watchgrd, multics, ucbvax, etc., we have domains of authority under various top-level domains such as all of the ISO country codes (.cn, .uk, .ru, .fr, etc), and other organizationally-related domains (.com, .gov, .mil, .edu, etc.). Rather than using a central store of all Internet host names, hosts are grouped into domains. The job of managing them has been pushed down to the various organizations that own them. Hence, WatchGuard Technologies is responsible for everything under watchguard.com. Root Name Servers on the Internet store top-level domain information and, when queried, return information telling DNS servers where to get further address data about a domain.

DNS Record Types

DNS keeps track of all kinds of records about domains and individual hosts. Here's a sample of some various DNS record types.

A — This is what we referred to in the opening example: hostname to address mapping. In DNS, this mapping is returned to a name server query in an A record, "A" for "Address."

MX — Lists all Mail eXchangers for a domain. A mail exchanger is a host that will accept and properly deliver e-mail for a particular domain. An MX server need not be in the domain it serves.

PTR — Pointer records allow the reverse look-up of a host by IP address (kind of like looking up a phone number to find out the owner).

CNAME — A Canonical name is an alias for a host.

SOA — The Start of Authority for a domain lists who is responsible for the domain, along with e-mail information for that contact person, timing information (such as how often a site that has cached information for this domain should update the cached data), and a serial number to track changes to the DNS information of the host or network.

HINFO — Returns host information, such as what operating system a host is running, on what hardware platform.

WKS — Lists the names of Well Known [Internet Protocol] Servers running in the system.

Both HINFO and WKS are undesirable from a security standpoint, as I will explain.

NS — The Name Server record returns information (hostname, IP address, etc.) for a hostname or domain. Shortly, we will see how this is used. Name server is synonymous with DNS server.

How it all works

When you connect your computer to the Internet — whether it is on a LAN at work or over a dial-up connection — your computer receives its IP address and a list of DNS servers to use for DNS queries. When you type www.watchguard.com into your Web browser, the browser side says, "I don’t know what IP address to connect to. Let me query my name servers." Your system makes a DNS query for an A record for www.watchguard.com. If another system on your network has recently made the same query, the DNS server will have the information in its DNS cache. The locally stored cache allows your DNS server to deliver the address more rapidly than if it has to query a root server elsewhere.

But let's assume our name server does not have the information. In that case, it sends out an NS query to the root servers, essentially asking, "Who out there knows about WatchGuard.com?" It learns that information about watchguard.com is available from dns1.watchguard.com and dns2.watchguard.com. The query also returns the IP addresses of the two WatchGuard servers.

Our name server next queries one of the WatchGuard name servers and gets back the A record for www.watchguard.com. Finally, the DNS server returns the information to your computer, and your browser can connect to www.watchguard.com.

Security and DNS

There are a few things you can do to make sure you are operating DNS as securely as possible. A few of them have to do with protecting DNS servers themselves, and the others deal with hiding information from outside hosts.

  1. Deny all DNS traffic from the Internet to your trusted network.
  2. Set up a name server on your Optional interface (the DMZ). Configure it to only have information about Internet-facing or Internet-reachable systems.

  3. Allow DNS traffic to and from the Internet to the DNS server on the DMZ.

  4. For security and performance, designate and set up one or more internal name servers that talk to your DMZ-based DNS server. Configure these with all “trusted side” system information, as well as DMZ-system information.

  5. Permit DNS traffic between the internal DNS servers and the one on your DMZ. The strategy behind steps 4 and 5 provides the bare minimum that the public needs to get to your Web site, while protecting the internal DNS servers that serve up sensitive corporate information to users on your trusted network.

  6. Do not support HINFO and WKS on the outside name server. Potential attackers can sometimes use information in these records to their advantage.

  7. Do not allow zone transfers — the transfer of all of the records for part or all of a domain — to any IP address except those that require the information. Zone transfers from the DMZ server to internal servers (by IP address) are okay. Transfers to unknown systems are not. (We do not need to help any would-be attacker with information about our trusted network.)

On-going maintenance

So there you have the very basics. In this amount of space, I can't cover every DNS issue. For example, some DNS servers have been the subject of numerous buffer overflow attacks. Even though the Firebox protects your DNS servers, it is important to keep on top of all security advisories related to the name servers you run (and the operating systems under them). LiveSecurity articles cover some other DNS issues, such as "How to Stop DNS Spies" and "Outsourcing DNS: For Once, Laziness Wins." There's plenty more to learn -- but for now, you have started understanding DNS. ##

Resources:

Fred has been contributing punchy, practical columns to Information Security Magazine for well over a year. Check out his recent article on "Practical Patching," or rummage through past articles here. He also freely dispenses sound security advice at his Web site.


Copyright © 1996 - 2003 WatchGuard Technologies, Inc. All rights reserved.
Legal Notice/Terms of Use