How DNS Really Works

How the DNS Protocol Returns Data

View from the client

A client system - phone, dekstop, laptop, server - looking to find an IP address for a name, lets use www.clintmcguire.com as an example, sends a DNS request to its configured name resolvers.
Name resolvers are either statically assigned by a network administrator or handed out by DHCP.

The client sends a request - typically via UDP - on port 53, to the name resolver. This is a question, asking for the Resource Record (RR) details that match a name/domain name.

The name resolver will - eventually, ideally - return the data to the client.

How does the name resolver get the answer to provide to the client

The name resolver will first check its cache to see if it has recently answered this request. There are three possible outcomes from this.

  1. It does not have the answer.
  2. It has the answer, but the cache time limit has expired - so the answer is no longer good.
  3. It has the answer and the cache time limit has not expired - so the answer is still good.

In the case of #3, the name resolver will respond to the client with the answer from the cache.
In the case of #1 or 2, the name resolver will have to find the answer for the client.

Lets go back to our example - www.clintmcguire.com - this name requires an RR to lookup. If you are using a web browser to go this site, the request will contain either an A record or an AAAA (Quad-A) record.

Resource Record Aside

There are many types of RRs, here is a quick list - that is not definitive

  • A - IPv4 address for a name
  • AAAA - IPv6 address for a name
  • CNAME - Alias for a name
  • TXT - Text string, used by a bunch of things, like SFP to assist with mail filtering
  • MX - Mail Server for the domain
  • PTR - Pointer, for looking up a name from an IP address

If you are interested in seeing a better list, check out: http://www.zytrax.com/books/dns/ch8/#types

Back to how does the name resolver get the answer to provide to the client

With an RR type and domain or host name, the name resolver will start a search against the Root domain servers, looking for - in our example - the name servers for the .com domain.
It will then ask the .com servers for the name server for clintmcguire.com.
It will then ask the clintmcguire.com name servers for the A or AAAA record for www.clintmcguire.com. Once it gets this answer it will reply to the client with the details.

This process descbribes a Recursive Query - where the name resolver does the leg work of tracking down the answer.
An alternate process would be an Iterative Query, the process is the similar.

How does an Interaive Query work

When a name server performs an Iterative Query, it responds to the client with the closest match it has, and leaves tracking down the answer to the client.
So asking for www.clintmcguire.com, a resolver might reply back with the .com name servers and a “Good luck!”, so the client then asks the .com servers for the name servers for clintmcguire.com. And so on.
The end result will be the same.

A bit more on the technical side

Currently, DNS traffic is sent to UDP port 53 on the server. The protocol allows for traffic to be sent via TCP, also on port 53, but because of the additional overhead of the TCP communications, UDP is preferred.
Unfortunately, this traffic is sent in the clear, so anyone that can see your network traffic can read your DNS queries. Additionally, this traffic is susceptible to manipulation - via Man in the Middle Attack.

There are a two different approaches to securing this traffic being experimented with - DNS over HTTPS (DoH) and DNS over TLS (DoT).
DoH is supported in Firefox, with some configuration.
There is criticism to both of these approaches, so it is still unclear what the final verdict will be.
In the mean time you can test it out for yourself if you want to dig into this more.

Also, DNS, as generally implemented, does not provide any data integrity, authenticaiton of data or have a way to assert a record does not exist. A solution to this is DNSSEC - DNS Security Extensions. DNSSEC addresses these shortcomings by signing responses with a certificate. This doesn’t encrypt the data being sent, it just allows the client to confirm that the data is true, by comparing the signed result with the certificate that has been published as part of the zone details. The original DNSSEC RFCs were published in 2005 but DNSSEC has not yet seen widespread adoption. However, I’ve been hearing more about it recenlty, as interest in “securing all the things” seems to be picking up. Hopefully this will start to gain wider adoption.

comments powered by Disqus