When I first worked with DNS I was a bit confused, but it’s actually a very simple system.
DNS is essentially a key-value store that maps records pertaining to your hosting environment with bits of data needed to interact with it, such as where to find your server and how to connect to it.
The majority of the time, DNS is being used by browsers to connect to your website, so let’s look at it from that perspective.
I find that it helps to think of DNS as a set of steps, that the browser goes through in order to connect to your site. The goal of the browser is to take your domain and figure out what to connect to.
When having problems with DNS, it’s often helpful to trace from beginning to end to find the issue. Let’s follow the same steps.
There are two locations where DNS data is actually stored, combined with a hierarchy of caches to try to make it fast:
- Root Name Servers
- Root Name Servers store the lists of Authoritative Name Servers for every single domain. There are only a few of these, and they’re updated by setting your nameservers at your Registrar where your domain is registered.
- Authoritative Name Servers
- These servers act as the source of truth for records for specific domains, responding to DNS queries for that domain.
This is also a hierarchical system of caches, with caches in your browser, OS, Router and ISP which will all attempt to respond with a cached answer to your DNS query. Your computer finds the DNS server (usually your router) from your network config, which retrieves it’s DNS server (usually the ISP’s) from it’s network config and so on until the top level servers are reached.
When troubleshooting, I find that it helps to imagine that the caching layer isn’t there (other than the delay it causes), and that your browser will directly start by checking the root name server. Any records that cannot be accessed by tracing the steps from the root nameserver to the record are completely ignored, therefore I find that when facing DNS issues it’s usually helpful to approach in this way.
DNS records are stored in “zone files” which are the collection of records about a domain. All of the records pertaining to the domain must be stored there.
In DNS, all domains actually end with a dot (.), so my domain
jazon.dev is actually
jazon.dev., and you must always include the dot when referring to your domain. (This also works in your browser, but it’s optional there! https://www.jazon.dev..
As a shorthand, it’s possible to omit the domain when referring to subdomains by specifying the subdomain without the dot. For example, a record for
jazon.dev must be added as
www.jazon.dev can be added as
www.jazon.dev. or just
www since the zone file’s domain will be appended to it. Most DNS servers will also allow you to use
@ as shorthand for the zone file’s domain, but this is not ubiquitous.
The record itself has 5 main fields:
- Identifies the purpose of the record and represented by a letter code such as
- The record key, usually a domain, usually a domain or subdomain.
- How long this record stays cached in seconds, and also how long you need to wait if you need to change this record. Usually this is between 1-4 hours (3600-14400).
- The data associated with the record, often another hostname or IP.
This record identifies which name server is the correct one for your domain, which can be either the current server, or another server that should be checked instead. Typically, you’ll configure your name server at the registrar which will then list itself in it’s NS records.
It’s common to have multiple per zone file, in which case the additional ones would function as backup name servers.
In a pinch, it’s possible to chain these, where the browser will follow the chain of NS records until it arrives at a server that lists itself in the NS record.
These records function as a “see also”, where the browser is being asked to issue a new DNS request for a different hostname.
As with NS records, these can also be chained, and the browser will follow the chain until it finds a record that is not a CNAME. This can be very useful to minimize the number of records that actually contain IPs so that in a server migration, you’ll have to change as few records as possible. The chain of CNAME records can also reference domains on different hostfiles, BUT the origin record (the hostfile’s base domain, ex.
jazon.dev.) cannot have a CNAME record.
A and AAAA Records
These records reference an IP for a hostname, and terminate the browser’s DNS lookup process.
A records reference an IPv4 IP, while
AAAA records reference an IPv6 IP. Each hostname can have both an
AAAA record, and have multiple of each for load balancing / backup.
Since this is the only record type that distinguishes between IPv4 and IPv6, it’s ideal to use as many CNAME’s and as few A/AAAA records as possible to minimize the amount of records that need to change in a migration.
These records are a catchall for various services which do not have a predefined record time. Commonly these are used to verify domain ownership and email hosting.
When configuring email, a few additional records are needed:
MX records list the mail server hostnames for the domain, which can themselves be A/AAAA or CNAME records. MX records have an additional field for priority, to define several hosts that a sender’s mail server should attempt to connect to and specify the order in which those connections are attempted.
SPF records are actually just TXT records that have a special format. SPF records specify which servers are allowed to send email “from” addresses at your domain. So for example if you send mail from services outside of your server such as Mailchimp or G-Suite, you will need to add these services to the SPF record or risk those emails being marked as spam.
Like SPF, this is actually a TXT record, and it contains a key with which to validate signed mail messages. Along with SPF, this helps to reduce and track down spam. Email services will give you the exact correct record to add for DKIM.« Back to home