Categories
How It Works

How DNS works, the recursive process

As more companies and products become dependent on internet connections, it is ever important to ensure secure and private communications. Thermostats, lights, security systems, door locks, window shades, entertainment, cameras, doorbells, outlets and smoke detectors are a few of the many devices available to connect to the internet. With more devices relying on external servers to operate, it is important that it is quick to find remote servers. DNS is the world wide distributed system which handles

This article is part of a series of articles explaining the security and infrastructure considerations behind the Domain Name system, in simple terms.

The role of DNS

The Domain Name System is an essential part of the internet as we use it. The system efficiently translates a domain to a set of IP records (among other things). When google.com is entered into your browser, your computer contacts a recursive server asking for the IP address of google.com, the recursive server then performs a process to determine the IP of google.com and returns it to your computer. This rather simple process called resolving is integral to IoT devices and the internet as we know it.

How it works

There are typically 5 different resources involved in the resolution process:

  • Stub Resolver:
    A stub resolver is a service that runs on every client device. The purpose of a stub resolver is to send a DNS request to a recursive server to provide a system with DNS services. When your browser requests a connection, it asks the stub resolver for the IP, and almost magically to the rest of the system — An IP is returned.
  • DNS Recursor:
    A recursive server receives requests from clients, and handles the rest of the DNS resolution process. The Recursor is responsible for for contacting and caching the rest of the DNS servers in the resolution problem. Typically your Internet Service Provider runs a recursive server, but you may have also heard of the Google (8.8.8.8) or Cloudflare (1.1.1.1) resolver.
  • Root Nameserver:
    This is where the true structure of DNS begins. There are 13 root DNS server IPs which are hard-coded into DNS recursors. Don’t believe that means there are only 13 root servers, in fact there are well over 600 distributed across the world thanks to a technology called Anycast, allowing multiple servers to sit behind one IP.
    The root nameserver resolves the IPs of the TLD nameservers. A TLD is a Top-level-domain, typical the last “dot” in a URL. For example, the TLD for google.com is “com” and for wikipedia.org, the TLD is org. Each TLD has it’s own set of nameservers which is then contacted next.
  • TLD Nameserver:
    These servers contains information about the about the domains hosted within a TLD. The TLD nameserver resolves the IP of the authoritative nameserver. If looking for google.com, the recursive resolver asks the .com TLD nameserver for the IP of the nameserver for google.com. The recursive nameserver then contacts the authoritative nameserver.
  • Authoritative nameserver:
    The authoritative nameserver is typically (but not always) ran by the host of a website or service. There is a large market to have another business to host and provide a more robust authoritative nameserver, but anyone can setup an authoritative nameserver for their own domain. This is where the IP for google.com is actually served. This is also where subdomains are resolved, such as mail.google.com, but it also possible for for another authoritative nameserver to be declared for a subdomain.

Different record types

Different kinds of data exist in the Domain Name System, labeled records. The typical record used when requesting an IP is called an “A” record. The A record represents an IP of a domain or subdomain. There are multiple other records such at TXT records which only contain text, SPF and MX which are used for email services, and AAAA which is used for IPv6 addresses.

DNS summary

Image of example DNS resolving process

Lets take all the information we have learned so far to summarize the DNS resolution process.

A user enters google.com into their web browser. The web browser tells their computer they need the IP of google.com. The stub resolver on the computer contacts the IP of a recursive DNS server requesting google.com The recursive DNS server contact the DNS root nameservers, whose IP is hard coded into the resolver, and asks for the IP of the .com nameserver. The recursive DNS server then contacts the .com nameservers, and asks for the google.com authoritative DNS IP. Next the recursive DNS resolver then contacts the authoritative DNS server and asks for the connection information for google.com. With this IP, the recursive DNS resolver then returns the IP to the stub resolver, which passes it to the browser to open a connection.

The importance of a trust worthy recursive resolver

In an article which will be published soon, we explain the shortcomings of DNS. The DNS based system is originally based off blind trust in your recursive resolver. As such you should use a recursive resolver which deserves your trust. One such services is operated by Cloudflare, one of the largest organizations pushing for a safer and more private internet. The service is called 1.1.1.1, and it comes highly recommended. I urge you to consider placing your trust in them for DNS needs, and removing it from your ISP or tracking conglomerates like Google.

Other DNS considerations

Caching of DNS requests typically occurs at the recursive nameserver level. This is enforced using Time-To-Live parameters in DNS records. An authoritative DNS server can tell a recursive to remember the IP of google.com for a set period of time. This means that if another request for google.com is made in the defined time frame, the recursive resolver can return it instantly without contacting the entire DNS structure. Caching can also occur by the stub resolver.

A client on a network may not directly contact the recursive resolver. Its increasingly common for home routers to serve their own DNS server which then contacts the recursive resolver on the stub’s behalf. These may also cache results themselves.
In enterprise environments, it can be rare to find a client which is permitted to directly connect to an external resolver.