This is a brief, simple tutorial on how DNS (and name resolution in general) occurs. The focus will be on Windows systems, 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.
Overview
Here’s a picture of how DNS works, at a very high level.
www.abc.com
For this how-to, we’ll use http://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.
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.
Name resolution order
A Windows host will try several things to resolve any name it’s given.
- Is it me? Do I have it in my local cache?
- Look in the HOSTS file: c:windowssystem32driversetc
- DNS
- LMHOSTS file: c:windowssystem32driversetc
- WINS
- 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.
Windows Host DNS Settings
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).
DNS Resolution
DNS goes through a similar progression when resolving a host name:
- Is the host in my cache?
- Do I have the zone in my database?
- Do I have a forwarder?
- If no forwarder, do a full lookup
Quick note about forwarders
A forwarder can be considered like a delegation of the task. If you 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.
Walking through the Zones
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.
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)
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)
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)
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.
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. That’s called Zone Transfers!
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.
Zone Transfers
This is a little bit outside the scope of this how-to, but I felt it should be mentioned.
DNS zones 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).
DNS Suffix’s
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.
Conclusion
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!
