Networking Essentials: DNS

source: devto devToUrl: "https://dev.to/swyx/networking-essentials-dns-1dl7" devToReactions: 33 devToReadingTime: 4 devToPublishedAt: "2018-09-26T04:12:12.237Z" devToViewsCount: 425 title: "Networking Essentials: DNS" published: true description: Domain names, you buy them, you sell them, but how do they work? tags: Networking

This is the fifth in a series of class notes as I go through the free Udacity Computer Networking Basics course.

The Domain Name System

The purpose of DNS is to map IP addresses to human-readable names:

The client wants to looks up a domain name
The client's stub resolver takes the name and issues a query. The resolver may have cached the name.
If not in cache, query gets sent to Local DNS Resolver (usually configured when your machine gets assigned its IP address, using the Domain Host Control Protocol)
If the first Local DNS Resolver doesn't respond within a preset timeout, it will try the second.
The query is recursive, so redirects and referrals spawn further queries and the client only wants the end result.
But Local Resolvers work iteratively, only answering the specific query in front of them.

So a query/resolution sequence might go:

Request: A "www.gatech.edu" (to root server)
Response: NS "k.edu.servers.net" (NS` records are referrals)
Request: A "www.gatech.edu" (to .edu servers)
Response: `NS "dns1.gatech.edu"
Request: A "www.gatech.edu" (to gatech.edu servers)
Response: A 130.207.160.173 (success!)

This process is rather slow due to all the round trips, so the Local Resolvers keep a cache of all the A and NS mappings for a particular TTL (Time to Live). You may also want to store more frequently accessed domains like the root or google.com for days and weeks, but a local name like www.gatech.edu might change more frequently and so deserve a shorter TTL.

Record Types

What are those A and NS notations above? They are record types indicating level of authority in the response:

A records map Names to IP addresses
NS (aka referrals) records map Names to authoritative nameservers

In plain English, if you ask the root server for a specific name, it probably doesn't specifically know the IP, but it will know who knows, and tells you to go ask that "authoritative nameserver". And so on down the line until you find the final nameserver that knows the exact IP of the domain you are looking for. This lets the Domain Name System be implemented as a hierarchy.

Other record types:

MX maps Names to Mail Servers
CNAME sets a Canonical name, or alias, to another domain name that needs to be looked up
PT R maps IP addresses to domain names (reverse lookup)
AAAA maps Names to IPv6 addresses

Try it yourself!

You can run your own traces in your terminal! try dig www.gatech.edu:

; <<>> DiG 9.8.3-P1 <<>> www.gatech.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40374
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.gatech.edu.            IN  A

;; ANSWER SECTION:
www.gatech.edu.     59  IN  CNAME   tlweb.gtm.gatech.edu.
tlweb.gtm.gatech.edu.   29  IN  A   130.207.160.173

;; Query time: 267 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 26 00:01:01 2018
;; MSG SIZE  rcvd: 72

The QUESTION SECTION shows our A record query for www.gatech.edu.

The ANSWER SECTION shows the answer with a CNAME swapping www.gatech.edu for tlweb.gtm.gatech.edu with a 59 second TTL.

So we issue another A request for tlweb.gtm.gatech.edu, and this time get back 130.207.160.173.

Load Balancing example

Try dig nytimes.com:

; <<>> DiG 9.8.3-P1 <<>> nytimes.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23334
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nytimes.com.           IN  A

;; ANSWER SECTION:
nytimes.com.        319 IN  A   151.101.193.164
nytimes.com.        319 IN  A   151.101.1.164
nytimes.com.        319 IN  A   151.101.129.164
nytimes.com.        319 IN  A   151.101.65.164

;; Query time: 128 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 26 00:03:49 2018
;; MSG SIZE  rcvd: 93

The 4 parallel addresses in the ANSWER SECTION are all the same, but if for example 151.101.193.164 gets overloaded the next response will swap that out for one of its other siblings.

Reverse lookup example

What if you tried to look up an IP address?

dig -x 130.207.7.36:

; <<>> DiG 9.8.3-P1 <<>> -x 130.207.7.36
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3657
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;36.7.207.130.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
36.7.207.130.in-addr.arpa. 299  IN  PTR granite.cc.gatech.edu.

;; Query time: 449 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 26 00:09:13 2018
;; MSG SIZE  rcvd: 78

You get the PTR record type pointing you back to the human readable domain. Note the reversed IP octets as the IP address moves from higher to lower parts in the domain name hierarchy.

Next in our series

Hopefully this has been a good high level overview of the Domain Name System and you can ping your own domains to see where records are held. I am planning more primers and would love your feedback and questions on:

swyxio / swyxdotio