Domain Name System (DNS)

You can compare domain name system (DNS) to a public phonebook with a little more extra, if you like. As humans we can remember names, but for computers they have basically no meaning. DNS connects readable names with technical information to fill this gap. Like the phonebook on your smartphone.

Like in your phonebook, DNS can manage multiple details of information per domain, so let’s go into the details.

This is a very basic introduction into DNS to provide a good first overview. In most cases this will be all you need to know, for experts it will probably not be enough.

Understanding the DNS hierarchy #

The domain name system deals with a ton of traffic. To achieve this, information is distributed and organised in a hierarchy of several layers.

Root DNS Servers #

If you understand the URL schema, you know the components of a domain: It always has a top level domain and probably it has subdomains.

The root servers identify which top-level domain DNS servers exist and their addresses.

Top-Level Domain (TLD) DNS Servers #

With this information, you can now reach out for the top level domain DNS sever and ask for the authoritative DNS server.

Authoritative DNS Server #

Finally we reached the level where we can get some information: The authoritative DNS server knows details about the domain you are looking for.

This DNS server holds the so called zone file for the domain.

Zone file #

Think of the zone file like a text document, holding all information for your domain. As said, there is multiple details that can be managed. So let’s review the zone file for reliable.codes (at time of writing this):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

$ORIGIN reliable.codes.
$TTL 86400
; SOA Records
@		IN	SOA	hydrogen.ns.hetzner.com. dns.hetzner.com. 2024020700 86400 10800 3600000 3600
; NS Records
@		IN	NS	helium.ns.hetzner.de.
@		IN	NS	hydrogen.ns.hetzner.com.
@		IN	NS	oxygen.ns.hetzner.com.
; MX Records
@		IN	MX	10 mail
; A Records
*		IN	A	49.12.61.231
@		IN	A	49.12.61.231
mail		IN	A	49.12.61.231
www		IN	A	49.12.61.231
; TXT Records
@		IN	TXT	aspe:keyoxide.org:HEMUVQFNMGLH6YTRT4ASV2VT6I
@		IN	TXT	google-site-verification=0HijyyKS-AbOntZF3uXakJTsVGA9actXlvlV4snnLNU
_acme-challenge		IN	TXT	PJp6vG0jB9leOvutX08TEP4GmgHPrlt3ytiPu0WVYSs

How to read a zone file #

Lines starting with $ #

This is meta data, like $ORIGIN represents the domain that is managed by this zone file and $TTL defines how long this information can be expected to be valid (TTL stands for “time to live”, measured in seconds).

Comments #

All lines starting with a ; are just comments, they have no technical meaning.

Lines containing IN #

This is what we search for: Information. Let’s pull apart @ IN A 49.12.61.231:

1. @ means this particular domain reliable.codes, no subdomain of it
2. IN stands for “Internet”
3. A (see below) tells us that this entry provides an IPv4 address (the phone number)
4. 49.12.61.231 is the IPv4 address

On top of that, there can be another element before IN, that defines the TTL for this particular entry (e.g. @ 3600 IN A 49.12.61.231 would describe 1 hour lifetime for this IPv4 address). If not defined, the zone files TTL is used.

If you see lines starting with something else then @, for example www, this is a subdomain-entry (www.reliable.codes in this case).

Common Types of DNS entries #

As said, DNS can manage multiple information per (sub)domain. In the above shown zone file you can find SOA, NS, MX, A and TXT but there’s many more.

To not make this entry-level article to complex, I’ll provide you the most relevant entry types.

A

The IPv4 address (e.g. 49.12.61.231) of the service.

AAAA

The IPv6 address (e.g. 2001:db8::abd:def) of the service.

MX

The responsible mail server address (e.g. mail which in my case would resolve to mail.reliable.codes) for this domain. MX entries do have a priority (e.g. 10 mail means priority 10), the lower the number the higher the priority. This is to handle load balancing or system downtimes in complex systems. The default is 10.

TXT

This is text without any technical relevance. It’s often used to verify ownership of a domain, see the google-site-verification entry I have in the above zone file.

CNAME

This is basically a redirect (“whatever he sais”). With CNAME you can re-use other DNS entries. This is often used to “connect” your domain with other services like Microsoft Office 365.

Caution: CNAME, if defined, replaces all your other entries for this (sub)domain. You probably don’t want to use CNAME for @

Caching in DNS #

If you work with DNS but don’t respect that DNS probably is the most-frequent used resource on our planet, you will come into trouble.

Again: DNS is a very, VERY high traffic system. I talked about DNS hierarchy already and mentioned, it’s distributed information, that includes caching of loaded DNS entries on several occasions.

Once you mess up an DNS entry, there’s no way back, once cached.

How does DNS caching work #

As mentioned above, zone files and DNS entries do have a TTL. The logic is as easy as: Once loaded, for the defined amount of time I’ll not reload it.

Example: 10:00 AM I do load reliable.codes with a TTL of 86400 seconds, so I’ll not reload it until tomorrow 10:00 AM.

Is there a global DNS cache for all internet users #

No. There’s just some famous DNS servers (like Google’s 8.8.8.8) that are used by many. Once they cache an entry, probably many load from their cached values.

Can I force flush DNS cache? #

On your devices maybe, but as shown, there’s caching outside your systems, that you can’t control.

Continue learning about DNS #

Thanks for reading first introduction to DNS. Keep rolling. If you want to dive deeper, there’s a ton of material out there. Here’s a 100 second video about DNS which gives more visual insight: