DNS - Resolving Domains to IP addresses
By Erik Rodriguez
This article provides an overview of DNS. If you have no idea how DNS works or what it is, you should keep reading. Also see RDNS - Reverse DNS Pointer Records.
What is DNS?
DNS is short for Domain Name System. DNS was created so we could use web address (domain names) instead of IP addresses. Remember that every device on the Internet has an IP address. For instance, skullbox.net has the IP address 220.127.116.11. DNS allows you to simply visit this site by using it's domain name. If DNS was not in place, every visitor would have to type http://18.104.22.168. Therefore, because DNS is in place, it does the work of associating the IP address with domain name making our lives much easier ;) Think of DNS like a phone book. You can look up a person or business and find a telephone number to contact them. DNS is nothing more than a directory services that must be queried to return results.
How Does DNS Work?
While the basic idea of DNS is fairly simple, the operation and design of the technology is very complex. Managing DNS records and mitigation in an enterprise network can be full time job. The diagram below illustrates how DNS works to associate domains names to IP addresses.
As you can see, the user requests a hostname (skullbox.net for example). That request is forwarded to the DNS servers of his/her ISP. DNS servers maintained by ISPs contain a cached table of DNS entries. These tables are refresed at a certain interval specified by the ISP. In the event you request a hostname that isn't in the local cache of the ISP's DNS server, the request is then forwared to the root DNS servers. The root DNS servers in turn replies with the requested hostname's IP addresss. This information is then relayed back through the ISP's DNS server and is cached for the next time it is requested. The root DNS servers are maintained by various governmental, educational, and research orgainzations around the world. These servers represent the top level of the internet, and without them, the internet would cease to function properly.
You can setup local DNS to run inside your LAN just as DNS runs globally. There are several ways to do this depending on the size of your LAN. The easiest way to do this on small networks is to edit the host file of each machine on your LAN. Remember that hosts added to these files will take prefrence over any "real" DNS requests. Here are to locations of these files:
Here is my sample hosts file from my Windows workstation: (C:\WINDOWS\system32\drivers\etc\hosts)
# Copyright (c) 1993-1999 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
# 22.214.171.124 rhino.acme.com # source server
# 126.96.36.199 x.acme.com # x client host
A sample file from a Redhat Linux server on the same LAN: (/etc/hosts)
192.168.0.1 router.skullboxnetworks.net router
192.168.0.200 thorin.skullboxnetworks.net thorin
192.168.0.100 moon.skullboxnetworks.net moon
192.168.0.15 roswell.skullboxnetworks.net roswell
192.168.0.20 saturn.skullboxnetworks.net saturn
192.168.0.55 neptune.skullboxnetworks.net neptune
127.0.0.1 mars.skullboxnetworks.net localhost mars
You will notice the syntax between the two is a little different, but for the most part the same.
From a shell, you can use a few different commands to reveal DNS information about the various hosts and domain located within these files. For example, from a shell, you can use the dig command to query DNS information about a host or domain. Let's query the TLD, skullbox.net: (Items marked in green represent user entered commands)
[weaponx@roswell weaponx]$ dig skullbox.net
; <<>> DiG 9.2.4 <<>> skullbox.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57191
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;skullbox.net. IN A
;; ANSWER SECTION:
skullbox.net. 14400 IN A 188.8.131.52
;; AUTHORITY SECTION:
skullbox.net. 36001 IN NS ns2.orlandotechworks.net.
skullbox.net. 36001 IN NS ns1.orlandotechworks.net.
;; ADDITIONAL SECTION:
ns1.orlandotechworks.net. 46051 IN A 184.108.40.206
ns2.orlandotechworks.net. 20853 IN A 220.127.116.11
;; Query time: 62 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Oct 21 12:13:31 2006
;; MSG SIZE rcvd: 131
As you can see, 18.104.22.168 is the A record for skullbox.net's hostname. Meaning, if you resolve skullbox.net to an IP address, 22.214.171.124 is what you will end up with. The authoritive section shows the name servers used by skullbox.net. As you can see skullbox.net is pointed to Orlando Tech Works' name servers. The IP's for those name servers are listed in the additional section.
Putting It All Together
Remember the diagram above? If we trace our steps, it would go form the web user (say me) --> ISP DNS servers --> Root DNS Servers --> Orlandotechworks Name Servers --> Skullbox.Net Web Server. The concept of DNS is fairly easy. However, it can get hairy in large networks with multiple DNS servers. Remember that without DNS, the internet would be MUCH different. You may also want to see the reverse side of this: RDNS - Reverse DNS Pointer Records.