How DNS works

The idea behind this How-To is to give you a brief, simple tutorial on how DNS (and
name resolution in general) occurs. The focus will be on Windows systems, since that's
what I know, but most of it will apply to any system.

You will find that once you understand DNS you can fix A LOT of issues, regardless of
the underlying OS.

First a quick definition of DNS: Domain Name Services is a simple lookup system that
translates fully qualified domain names (FQDN) into IP addresses. That's it! Even when
you type in a simple name (ping myserver) your operating system will create an FQDN
by adding a DNS suffix to the name as defined on your particular address--in Windows
it appends the FQDN for your Active Directory domain.

16 Steps total
Step 1: Overview

Expand
Here's a picture of how DNS works, at a very high level. I got the image from Royal
Pingdom, who got it from Verisign Domain Name Industry Brief, June 2007 (PDF), last
page (link below).

Step 2: www.abc.com
 Expand
For this how-to, we'll use www.abc.com as our example.

First, a break down of this Fully Qualified Domain Name (FQDN). The left most name
before the first period is always the host name or the name of the server. In the
Windows world this host name does not have to match the server name, but usually
does. In this case "www"

Everything after that is the zone the host belongs to. In this case the server's zone is
"abc.com".

"ABC" is a subzone of ".COM", while ".COM" is a subzone of the root zone "."

Many times you'll hear a DNS zones called domains. A domain/zone is the "abc.com"
part of any FQDN. I like to use the terminology zone instead of domain because in the
Windows world, domain typically signifies Active Directory, and while AD relies heavily
on DNS, I like to make the distinction between the two.

Step 3: Root Zone

The root zone exists on every FQDN, but is rarely expressed. Most systems will add it in
without you ever knowing that it's there.

The only times I've had to use the root zone in the FQDN are on some DNS servers
(namely XO's web based DNS services) when I'm trying to alias one zone to another.
Namely, the web site would try to add my zone to the end of my alias, which is bad so I
placed the root zone at the end to stop that.

Early Windows 2000 servers used to have a problem with DNS because for some
reason it would create a root zone "." in the list. Since the root zone was local the server
would attempt to resolve from there, but the zone would be empty and name resolution
would fail. Deleting that zone would resolve the issue.

Step 4: Name resolution order

A Windows host will try several things to resolve any name it's given.
1. Is it me? Do I have it in my local cache?
2. Look in the HOSTS file: c:\windows\system32\drivers\etc
3. DNS
4. LMHOSTS file: c:\windows\system32\drivers\etc
5. WINS
6. Broadcast

You'll notice that the HOSTS file is one of the first things a Windows host will check.
This is why many virus's attack that file to cause redirection to malicious web sites.

Step 5: Windows Host DNS Settings

 Expand
Most people put in a primary and secondary DNS server in their Windows host TCP/IP
settings. There is a very commonly held misconception that if the primary server can't
resolve the name then the secondary will give it a try. This is not the case.

Windows will attempt to connect to the primary server, if that fails then it will attempt to
connect to the secondary. If the primary connection succeeds then Windows will totally
rely on that server to make the resolution. If the server can't make the name resolution
then Windows will move onto the next item in it's resolution order (LMHOSTS).

Step 6: Quick note about forwarders

 Expand
A forwarder can be considered like a delegation of the task. If your DNS has a
forwarder, it will delegate the task of doing the lookup to the server specified in its
configuration. The DNS server will not attempt to resolve the name itself.

Step 7: DNS Resolution

DNS goes through a similar progression when resolving a host name:
1. Is the host in my cache?
2. Do I have the zone in my database?
3. Do I have a forwarder?
4. If no forwarder, do a full lookup

Step 8: Walking through the Zones

 Expand
So, DNS has never seen this host before (and stored the name in cache), it does not
have the zone in it's own database and you don't have forwarders turned on. That
means it has to do a full lookup.

DNS works backwards through the zone on it's way to resolving the name. First up, the
root domain.

The root domain is a special domain and every DNS server has a set of static IP
addresses that represent the name servers for the root zones. You can look at these
settings by going to the properties of your DNS server and looking at the Root Hints tab.

Step 9: Talking to the Root Servers

Your DNS server now has a place to start. It goes to a root server, from its root hints list,
and asks if you know any name servers for the next zone up. For our example, that
would be ".COM".
Any zone that's right under the root zone is considered a Top Level Domain, or TLD.

Since your root server has probably heard of ".COM" it will return with a list of TLD
name servers.

(This is step #1 of the overview picture)

Step 10: Talking to the TLD Servers

Now your server goes to one of the TLD's and asks, do you know about "ABC.COM"?

The .COM server will return a list of name servers. If you've ever done a WHOIS
search, the name servers returned from this is the same list your DNS server will get.

To the right I've shown an example of the return you would get from Google.com if you
tried a WHOIS search on it. The only difference is, when you DNS server asks the
.COM server will actually return a list of IP addresses.

(This is step #2 of the overview picture)

Step 11: Talking to ABC.COM

As you can see, we've finally landed on the name servers that should know about our
host, WWW.ABC.COM.

Now your DNS server will ask one of the name servers for ABC.COM, do you know a
host named WWW?

The name server will return an IP address. This name will be passed down to your
Windows host and it will also be stored in the DNS servers cache, for a specified
amount of time known as the Time to Live.
(This is step #3 and #4 of the overview picture)

Step 12: What is TTL?

TTL: Time to live. This is a setting that tells a DNS server, as well as a DNS client, how
long to keep this host/zone and IP address combination in cache.

The DNS cache is simply a list of every place that's been visited and it's IP address so
the DNS server doesn't have to do a full lookup every time.

Back in ancient times (3 or 4 years ago) saving every ounce of bandwidth was very
important so it was not unusual to have cache's held for long periods of time, 1-3 days.
The cache does not get updated until that TTL period has expired. This is why, even to
this day, that most ISP's will say you need to wait 24-72 hours before your changes will
take effect. What's really happening is you're waiting for the data in the DNS cache's to
expire so your new settings will be re-read.

Today, bandwidth is not much of an issue and most TTL's are set in the seconds.

Step 13: DNS Propagation

DNS Propagation is a term commonly used to describe the function of waiting for the
TTL to expire and having your DNS server query the zone name servers for new IP
addresses. Many ISP support personnel will use this term, and I'm not convinced they
know what it means!

I'm not a fan of the term because I think it has some connotation that DNS servers are
secretly transferring data while we're not looking. They're not. There's just lookup,
caching, timeout and re-lookup's going on.

Step 14: DNS Cache

If you're in DNS on your server, you can turn on the advanced view and see your DNS
cache. Hosts/zones and IP addresses are stored here for the duration of that hosts TTL
settings. You can delete anything and everything in here at will, as the server will simply
relook anything up if it's not in the cache.

Windows hosts also have a local cache and host/zone and IP addresses will be stored
in there, also for the duration of the TTL settings.

If you're making changes to a host record and it's not resolving you may need to delete
the cache on your local Windows host (IPCONFIG /FLUSHDNS from a command
prompt) and delete the cache from the DNS server.

Step 15: Zone Transfers

This is a little bit outside the scope of this how-to, but I felt it should be mentioned.

The actual DNS zone database records can be kept on multiple servers, and the data is
copied using a process called Zone Transfer. At its most basic, there are primary zones
(read/write copies of the zone) and secondary zones (read only copies). Typically you
would set up Zone Transfers between your DNS servers to keep data up to date
between them.

With Active Directory, this process is a little different. An Active Directory Integrated
zone keeps all of the data in AD, and uses the AD replication processes to keep servers
up to date, so no zone transfers are necessary. Windows servers support AD integrated
zones, and the more traditional zones (the database is actually a simple text file).

Step 16: DNS Suffix's

 Expand
A common problem for Windows administrators is multi-AD domain name resolution.
Let me set it up:

Primary domain: mycompany.local (HQ)

Child domain: newyork.mycompany.local

Server in HQ: hqserver1

Server in New York: nyserver2

You're at the HQ and you try to ping nyserver2 but the name doesn't resolve. How
come? It's a child domain with a full trust?

Windows will always try to add your default DNS suffix to a host, so if you're at HQ
you're in the mycompany.local domain, so you're suffix will be ".mycompany.local". So,
when you ping nyserver2, you're actually pinging nyserver2.mycompany.local. See the
problem? The server FQDN is actually nyserver2.newyork.mycompany.local.

The easiest fix is to add an additional suffix to your DNS settings: "mycompany.local
and newyork.mycompany.local" (see image). Now your Windows host will first try
nyserver2.mycompany.local (which will of course fail), and then
nyserver2.newyork.mycompany.local (which should succeed).

Should? What do you mean should? Well, does your mycompany.local DNS server
know about the newyork.mycompany.local zone? Not normally. What to do? Setup a
conditional forwarder on your DNS server. Type the name of the zone you want to
foward (newyork.mycompany.local) and then configure the IP address to the DNS
server in that domain.

Notice the differences between zone and domain as I'm using it? Unfortunately this is
probably a unique differentiation so understanding different administrators will always
be a challenge.

There you have it, you can now consider yourself an expert in DNS -- or at the very
least you'll be able to fool 90% of the people you talk to!

Good luck out there and happy DNS'ing!

Next, read about how Reverse DNS works (see reference section below for the link).
Published: Jun 17th, 2009 · Last Updated: Oct 11th, 2017