DNS 101 – Lattimore University
Welcome to the first lesson from Lattimore University! For those unaware, Lattimore University is designed for anyone who works at branding, creative and design agencies who is:
- Worried about giving correct technical answers to clients,
- Baffled, confused or scared by technical jargon and not sure where to turn,
- Just interested in web development and want to know more
The first lesson in Lattimore University concerns one of the most fundamental yet, frankly, the most boring part of web development – DNS (domain name system) – basically, how a website appears on your screen when you click a link on Google.
Is the below the “final word” on DNS? No. Will it deeply offend systems admin people? Probably yes. Does it provide enough info for the contemporary user of the interwebs to have an understanding of what is going on “under the hood?” Absolutely.
What is DNS?
DNS is short for Domain Name System and acts fundamentally as the “phonebook” for the internet.
Technically web browsers interact via IP addresses; each device/machine has its own unique address, made up of structured digits (and sometimes letters).
However remembering IP addresses is hard for humans; it is significantly easier for us to remember domain names (also known as hostnames).
DNS resolution is the process of taking a hostname/domain name (e.g. lattimoreandfriends.com) and converting that a computer-friendly IP address (e.g. 192.168.1.1) – known as a “lookup.”
For instance, if one starts with typing “www.google.com” into a browser:
- Recursive resolver (aka DNS recursor) is the first step – acts as a middleman between you and your browser and a nameserver (where information we are looking for is stored)
- First, the recursor goes to one of the 13 DNS root nameservers to start its search. The root nameserver takes the domain name and directs the recursor to its next destination – the correct TLD nameserver
- A TLD nameserver maintains information about all the domain names that share a common domain name extensions e.g. .com, . net, .london, etc, etc
- The “.com” TLD nameserver takes the query (“www.google.com”) and then sends the recursor on its merry way to the authoritative nameserver
- The authoritative nameserver contains info specific to the domain name
- It holds key info like A records, CNAME, etc
Once the recursor has the IP address of the domain, it sends that back to the browser so it can make an HTTP request to that server, and hopefully displaying the webpage in the browser.
Your browser will cache DNS records for a set amount of time, ensuring that it can load the site quicker next time – this means that the browser will first check the browser cache for the IP address
If no IP address is found in the browser cache, the browser will reach out to the resolver and start the lookup process.
The resolver will first check its own cache, to see if it has accessed that resource recently, and if so, it will return the saved IP address straight away (and not pursue the whole process).
IP here stands for “Internet Protocol” and is a set of rules that enable devices to communicate over the internet.
They act like a physical address to a house; this is the exact server website the files and database are stored.
IPv4 and IPv6
IPv4 was implemented in 1983 and it is the most common format that we see. It is made up of four sets of numbers separate by dots e.g. 192.168.1.1
IPv4 allows for 4.3 billion unique IP addresses, which sure must have seemed an absurdly high number (and surely more than we would ever need) back in 1983…
IPv6 was implemented much more recently and uses a more complex format of sets of numbers and letters, separated by single or double colons e.g. 2607:f860:4005:804::200e
IPv6 allows for 340,282,366,920,938,463,463,374,607,431,768,211,456 unique addresses (I totally had to look up what that size of number was even called…). It also provides some security and privacy improvements on IPv4.
Crucially IPv6 can be used concurrently with IPv4, meaning there has been no dramatic loss of access to content.
Static IPs vs Dynamic IPs
If you’ve had the misfortune of dealing with hosting companies, ever, you may have encountered the phrases “static IPs” and “dynamic IPs” – but what do they mean?
As there is such a limited supply of IPv4 addresses, it led to introduction of dynamically assigned IP addresses.
For instance, when a laptop joins a home internet network, the ISP (internet service provider) will assign a temporary IP addresses from a shared pool – this is significantly cheaper and easier for the ISP.
The example we have seen at Lattimore and Friends most often is where some IT teams have locked down SFTP and whitelist certain IP addresses to access the server – but it’s hard to do from home where the IP address might change regularly.
DNS Records aka Zone Files
DNS records/zone files are “instructions” that live in the authoritative DNS servers and provide key info about the domain. We have outlined some of the most common ones below:
A records hold the IP address of the domain, and ultimately enables the matching of a domain (e.g. ben.com) to an IPv4 address (e.g. 192.168.1.1).
AAAA records have the same functionality as an A record but for IPv6 addresses (e.g. 2607:f860:4005:804::200e).
CNAME records are used in lieu of an A record when a domain/subdomain is an “alias” of another domain.
In plain English, this occurs when a domain/subdomain needs to point to another domain.
If we imagine the whole DNS resolution process as like a “scavenger hunt,” then a CNAME record acts as a further clue – sending the resolver on another “lookup” to the new domain.
A live example of this might be:
- Example.com lives on IP address 192.168.1.1
- However the blog (blog.example.com) is powered by Hubspot, hosted on Hubspot’s servers
- When someone goes to blog.example.com, the resolver will find a CNAME record that sends it to a new domain (e.g. exampleblog.hubspot.com), at which point it will do the whole lookup again, hopefully getting to an authoritative nameserver with an A record (and IP address) for the Hubspot-hosted blog
MX stands for “Mail Exchange” and directs email to a mail server. The process goes as follows:
- When someone sends an email, the “Message Transfer Agent” (MTA) does its own DNS query (like the resolver above) to identify the mail server of the email recipient
- There are typically a number of MX records set-up, with different priorities. The MTA will start the highest priority mailserver and work down if they fail to deliver the email to the preceding mailserver
TXT records allow someone add informational text into the DNS. This was originally intended as just a place for human-readable notes but increasingly TXT records are being used with machine-readable data.
This allows for the two most common usages of TXT records:
- Email spam prevention
- Domain ownership verification
Each domain name can have as many TXT records as required,
Follow On Questions
What does @ mean in DNS? And *?
Great question! Here is an example:
The @ here indicates that this record (an A record in this case) is for the root domain.
In the above example, example.com is the root domain (typically the primary website); it acts as the overarching structure containing any subdomains and every URL.
The root domain can be divided into “smaller” domain called subdomains. For instance, a common use of these is for different languages or regions e.g. fr.example.com or usa.example.com.