[ DNS ] [ DNS Lookup ] [ Domain Name Service ] [ dig ] [ nslookup ] [ Networking ]
Contents
WHAT IS DNS
A Domain Name Service (DNS) is a critical service that everyone uses every time they surf the web. Before we get into the technical details let’s talk about telephone numbers.
PHONE BOOK ANALOGY
DNS is similar to a phone book. In the long, long ago when you needed to call someone and didn’t already know their number you had to look them up by name in a telephone book, see their phone number, and then make the call. If you needed to make a call to someone long distance then you had to call information and hope you could them enough information to find the person or business’ number you needed. Instead of carrying a phone book around all the time or calling information people used to have address books, black books, scraps of paper, or a number written in ink on their hand to keep frequently used numbers with them for easy access. As long as we have our local copy of the number we could stop at the next payphone we passed and call anyone we know without taking the time to look the number up in the city wide phone book.
This isn’t a perfect analogy, but it gives us a simple picture that most people understand and we can use to build the concepts of DNS. We are going to make a few connections to DNS. The operator would be a DNS root server. The phone book would be your immediate DNS server and a personal address book would be the local DNS cache. An IP (Internet Protocol) address is equivalent to a phone number.
DNS OVERVIEW
This website, blue42.net, translates to the IP address 52.20.23.22. While that’s all fantastic and relatively simple the truth is many people don’t understand how this information is made available to all Internet users.
At the top of the DNS hierarchy are the ROOT SERVERS. These servers tell all other DNS servers where who to talk to about resolving a domain name into an IP address.
The next step down are AUTHORITATIVE DNS SERVERS. These servers answer for the domains that they are assigned to them.
Below that are RESOLVING DNS SERVERS. These are the server your ISP runs that allow you to look up any domain you want to visit.
Finally, your local computer, and in some cases your home router, will cache lookups for a specified period of time. Caching is the process of saving data locally for a specified period of time to keep from having to talk to the RESOLVING DNS SERVER for every request we make. It’s not uncommon for one web page to make forty or more request every time it’s loaded. AUTHORITATIVE DNS SERVERS will tell any client how long they are allowed to cache a record – this time is called the TTL (time to live).
When making a DNS query the server will return what is called a record. A record is the answer to one lookup. When looking up blue42.net the AUTHORITATIVE SERVER returns a record that tells your computer to use 52.20.23.22 when connecting.
FOLLOWING A DNS REQUEST
NEW REQUEST
Let’s walk through looking up a DNS record that we haven’t looked up before. So we type in our browser blue42.net…
Step 1: Our computer checks if the DNS for blue42.net is in our local cache… nope.
Step 2: We ask our ISP’s DNS servers for the DNS records. Unfortunately, blue42.net is not very popular and our ISP’s servers don’t have this record already cached so they have to move up the ladder and ask the ROOT SERVERS which DNS server is AUTHORITATIVE for blue42.net.
Step 3: Now our ISP’s DNS servers know which servers are AUTHORITATIVE and makes a request to one of those servers and asks for the DNS record (RR or RESPONSE RECORD) for blue42.net.
Step 4: The AUTHORITATIVE server responds with an IP address for blue42.net and a TTL that gives our ISP’s name servers permission to cache this record for a specified period of time.
Step 5: Our ISP’s DNS server sends our local computer the answer from the AUTHORITATIVE server along with a TTL.
Now we know locally what the IP address for blue42.net is and we don’t have to repeat the above process until the TTL expires.
EXAMPLE DNS ANSWER
; <<>> DiG 9.10.3-P4-Ubuntu <<>> blue42.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46544
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blue42.net. IN A
;; ANSWER SECTION:
blue42.net. 25 IN A 52.20.23.22
;; Query time: 0 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Tue Mar 14 14:20:59 UTC 2017
;; MSG SIZE rcvd: 55
ABOUT THE TTL
The TTL or Time to Live part of a DNS record seems to cause the most confusion when you aren’t familiar with how DNS works.
This field is a 32 bit integer in units of seconds, an is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded. RFC1034
The TTL is a time value in seconds that tells other servers how long they should cache a response record before asking the AUTHORITATIVE SERVER for the record again. So if a TTL is set to 600 seconds (10 minutes) we are not going to send any requests to the AUTHORITATIVE SERVER for at most ten minutes.
This is great for reducing unnecessary network traffic, but there is a bit of a gotcha in this. It’s one that comes up mostly when migrating a site or service to a new hosting provider. Depending on the length of a records TTL clients will not get updated information for some period of time.
If your TTLs are set low (e.g, 600 seconds) before a migration then clients should get the updated record relatively quickly. But, if our TTL is set to 1 week our clients may not see the new service address for an entire week!
The neat thing about all this is we can see the TTL of a response record using the Linux command dig. Earlier in this post you’ll find an example DNS answer. In that answer the remaining TTL was 25 seconds.
;; ANSWER SECTION:
blue42.net. 25 IN A 52.20.23.22
If we run the same command , dig blue42.net, a few seconds later we can see the TTL has gone down to 11 seconds.
;; ANSWER SECTION:
blue42.net. 11 IN A 52.20.23.22
The same can be done on windows using nslookup.exe. NSLookup is included in Windows and does not need to be installed. However, to view the TTL you need to run nslookup.exe and then turn on debugging.
PS C:\Users\luke_000> nslookup.exe
Default Server: cdnsxx.comcast.net
Address: 123.123.123.123
> set debug
Now that you are armed with this TTL information the next time you are waiting for a record to propagate you can see how much time remains before your cache expires.
CONCLUSION
DNS is a backbone service of the Internet. Without it the world wide web (Hello 1995!) would break horribly. It’s not necessary to understand DNS on an intimate level, but if you work with technology it is a good idea to at least understand the basics.