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.
- Deny
all DNS traffic from the Internet to your trusted network.
-
Set
up a name server on your Optional interface (the DMZ). Configure it to only
have information about Internet-facing or Internet-reachable systems.
-
Allow
DNS traffic to and from the Internet to the DNS server on the DMZ.
-
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.
-
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.
-
Do
not support HINFO and WKS on the outside name server. Potential attackers
can sometimes use information in these records to their advantage.
-
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
|