Introduction to DNS
This article is an introduction to the concepts and internal mechanics of DNS (or Domain Name Systems).
IPv4 (ex: 123.3.4.5) was, up until the arrival of IPv6, the only way any computer could speak to any other computer on a network.
Because it is impossible for us humans to remember IP addresses for all the common services we rely on, Domain Name Systems (DNS) became a thing: Instead of having to remember Google’s public IPs for its search engine, now you only need to remember “google.com”. Much easier.
The problem is that machines cannot understand those names.. so DNS was invented as a solution to this, and is essentially a Service which aims at translating machine readable addresses (IPv4, IPv6) into human readable names (and vice versa): You give DNS www.google.com and it returns an IP address (a publicly accessible one in this case).
The com in Google.com
There is agreed upon hierarchy when dealing with domain names: The Top Level Domain refers to the very last part of the root of a URL. com, net, gov, org, fr, us, etc. are all Top Level Domains.
Zonefiles
A Zonefile is a text file made of a variety of different records for an individual domain. A zonefile resides on a DNS Server.
Here is an example for domain example.com:
$ORIGIN example.com. ; designates the start of this zone file in the namespace$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL valueexample.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )example.com. IN NS ns ; ns.example.com is a nameserver for example.comexample.com. IN NS ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.comexample.com. IN MX 10 mail.example.com. ; mail.example.com is the mailserver for example.com@ IN MX 20 mail2.example.com. ; equivalent to above line, "@" represents zone origin@ IN MX 50 mail3 ; equivalent to above line, but using a relative host nameexample.com. IN A 192.0.2.1 ; IPv4 address for example.com IN AAAA 2001:db8:10::1 ; IPv6 address for example.comns IN A 192.0.2.2 ; IPv4 address for ns.example.com IN AAAA 2001:db8:10::2 ; IPv6 address for ns.example.comwww IN CNAME example.com. ; www.example.com is an alias for example.comwwwtest IN CNAME www ; wwwtest.example.com is another alias for www.example.commail IN A 192.0.2.3 ; IPv4 address for mail.example.commail2 IN A 192.0.2.4 ; IPv4 address for mail2.example.commail3 IN A 192.0.2.5 ; IPv4 address for mail3.example.comevery line in the file is a DNS record of some kind (see below for more)
See the reference to SOA, NS, MX, A, AAAA, CNAME? those are DNS Records. Keep that in mind for now.. more on that later.
Root Servers
When you point your browser to www.google.com, the top level domain of your request is com. This top level requests are typically processed by Root Servers responsible for handling Top level domain queries.
Those Root Servers respond to your browser with a bit more information (on where to go to resolve the full address) but usually not an actual public IP.
TLD Servers
A Root Server responds to your browser with more information as to who would be able to resolve the address. TLD servers are the ones helping resolve the google part of www.google.com.
Domain Level nameservers
In the same way the Root Server resolves the top level domain com and returns information about the right TLD Servers to query next, the TLD Servers return more information for your browser to be able to send the resolution request to Domain Level nameservers:
Those are responsible to resolving the now complete address: www.google.com. Domain Level nameservers will return the actual public IP (or IPs) matching the full address.
DNS Resolution is always done in a hierarchical way from top level down.
Back To DNS Records
While DNS is responsible for mapping human readable names to IP addresses, it is also used as a form of key/value database for the Internet.
In the early days of the internet, a common service provided by most domains was the Mail server(s).
This makes sense because DNS needs to resolve public IPs for many different types of services, not just web servers.
| Record Type | Description |
|---|---|
| A | Responsible for mapping individual hosts to an IP address. For instance, myserver in the myserver.mydomain.com syntax. |
| AAAA | The IPv6 equivalent of an A record (see above) |
| CNAME | Canonical name. Used to alias one record to another. For example, nas.mydomain.com could be aliased to myserver.mydomain.com. |
| MX | Specifies mail servers responsible for handling mail for the domain. A priority is also assigned to denote an order of responsibility. |
| PTR | Resolves an IP address to an FQDN. In practice, this is the reverse of an A record. (see Reverse DNS below) |
| SOA | Specifies authoritative details about a zonefile, including the zonemaster’s email address, the serial number (for revision purposes) and primary nameserver. |
| SRV | A semi-generic record used to specify a location. Used by newer services instead of creating protocol-specific records such as MX. |
| TXT | Arbitrary human-readable information that needs to be stored in DNS. Examples include verification codes and SPF records. |
Back to Zonefiles
Now take a look at the zonefile again, and look at all Records on it:
$ORIGIN example.com. ; designates the start of this zone file in the namespace$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL valueexample.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )example.com. IN NS ns ; ns.example.com is a nameserver for example.comexample.com. IN NS ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.comexample.com. IN MX 10 mail.example.com. ; mail.example.com is the mailserver for example.com@ IN MX 20 mail2.example.com. ; equivalent to above line, "@" represents zone origin@ IN MX 50 mail3 ; equivalent to above line, but using a relative host nameexample.com. IN A 192.0.2.1 ; IPv4 address for example.com IN AAAA 2001:db8:10::1 ; IPv6 address for example.comns IN A 192.0.2.2 ; IPv4 address for ns.example.com IN AAAA 2001:db8:10::2 ; IPv6 address for ns.example.comwww IN CNAME example.com. ; www.example.com is an alias for example.comwwwtest IN CNAME www ; wwwtest.example.com is another alias for www.example.commail IN A 192.0.2.3 ; IPv4 address for mail.example.commail2 IN A 192.0.2.4 ; IPv4 address for mail2.example.commail3 IN A 192.0.2.5 ; IPv4 address for mail3.example.comsee the CNAME for example.com? this is why www.example.com and example.com resolve to the same host (and why you usually don’t have to worry about NOT typing www in your browser).
Computer Specific DNS Configuration
If you are administering systems, specifically Unix systems, you should be aware of two pieces of host-side configuration which allow your machines to interface with DNS:
- /etc/hosts/etc/resolv.conf
- the Hosts File
Hosts File
The /etc/hosts file (C:\Windows\System32\drivers\etc\hosts on Windows) has the purpose of acting as a local alternative to DNS (and always takes precedence over DNS).
Why is the hosts file a thing at all?
Because the hosts file IS the original DNS system.. When the Internet was invented, it started on a small network so it was much easier to maintain a single file referencing ALL hosts on the network and distribute it across computers.
You might use this when you want to override the record in place in DNS on a particular machine only, without impacting that record and its use for others - therefore, DNS can be overridden using /etc/hosts.
Alternatively, it can be used as a back-up to DNS: if you specify the hosts that are mission-critical inside /etc/hosts, then they can still be addressed by name even if the nameserver(s) holding your zonefile are down.
However, /etc/hosts is not a replacement for DNS - in fact, it is far from it: DNS has a much richer set of records that it can hold, whereas /etc/hosts can only hold the equivalent of A records. An /etc/hosts file might, therefore, look like:
127.0.0.1 localhost255.255.255.255 broadcasthost::1 localhostfe80::1%lo0 localhost
192.168.2.2 sql01192.168.2.3 sql02192.168.1.10 puppetmaster puppet pm01The first four lines of /etc/hosts are created automatically on a Unix machine and are used at boot: they shouldn’t be changed unless you really know what you’re doing! In fact, the last two lines of this section are the IPv6 equivalents of the first line. After these first four lines, though, we can specify a name and map it an IP address. In the above example, we’ve mapped sql01 to 192.168.2.2, which means that on a host with the above /etc/hosts configuration, we could refer to sql01 alone and get to the machine responding as 192.168.2.2. You’ll see a similar example for sql02, too. However, there is a slightly odd example for the box named puppetmaster in that multiple friendly names exist for the one box living at 10.0.0.2. When referenced in this way - with multiple space-separated names against each IP address - the box at 10.0.0.2 can be reached at any of the specified names. In effect, puppetmaster, puppet, and pm01 are all valid ways to address 10.0.0.2.
Resolvers
What are Resolvers for?
A Resolver is a resource which points to one or more DNS services and can be used to resolve an address like example.com.
The Operating System you run on your computer maintains an ordered list of such Resolvers: all DNS queries go to the first resolver and, if resolution is unsuccessful, it goes to the second resolver, then third, etc. until resolution of the address is successful.
If you are on a mac, try running the following command in a Terminal window (with the Twingate Client** not running**): scutil --dns :
my-mbp16 git % scutil --dnsDNS configuration
resolver #1 nameserver[0] : 192.168.1.1 if_index : 14 (en0) flags : Request A records reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2 domain : local options : mdns timeout : 5 flags : Request A records reach : 0x00000000 (Not Reachable) order : 300000The default Resolver (when the Twingate Client is not on) is, in this case, the router (the router here helps deal with all DNS requests for all machines on a local network like a home network).
Now, let’s take a look at our Resolvers again but with the Twingate Client on:
my-mbp16 git % scutil --dnsDNS configuration
resolver #1 nameserver[0] : 100.95.0.251 nameserver[1] : 100.95.0.252 nameserver[2] : 100.95.0.253 nameserver[3] : 100.95.0.254 if_index : 29 (utun7) flags : Supplemental, Request A records reach : 0x00000003 (Reachable,Transient Connection) order : 103200
resolver #2 nameserver[0] : 192.168.1.1 if_index : 14 (en0) flags : Request A records reach : 0x00020002 (Reachable,Directly Reachable Address) order : 200000the first Resolver is now different: It maps to Twingate’s own DNS Resolver service (100.95.0.25[1-4]).
Why does Twingate adds its own Resolver on top of the list?
Jump to How DNS Works with Twingate to find out.
DNS Caching
Imagine every machine on the internet having to constantly resolve complex names into IP addresses: this wouldn’t scale very well and would be very intensive for a network to handle. This is why DNS records can be cached (meaning: temporarily kept in memory so as not to require a network request).
The SOA record at the start of each zonefile specifies an expiry value: this tells clients for how long they can keep the zonefile before re-requesting it from the domain server.
$ORIGIN example.com. ; designates the start of this zone file in the namespace$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL valueexample.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )Caching.. at what level?
But what exactly caches DNS records? the OS? an application?
Well, it depends.. both are possible and it is largely a function of what OS you are running.
On Unix based systems (Linux, Ubuntu, etc.) caching is typically done at application level (ex: your own browser handles its own DNS cache).
On Windows, it is a bit more centralized and you can see it by running the command ipconfig /displaydns:
C:\\Users\\aUser>ipconfig /displaydns
Windows IP Configuration
array801.prod.do.dsp.mp.microsoft.com ---------------------------------------- Record Name . . . . . : array801.prod.do.dsp.mp.microsoft.com Record Type . . . . . : 1 Time To Live . . . . : 406 Data Length . . . . . : 4 Section . . . . . . . : Answer A (Host) Record . . . : 40.91.80.89
Record Name . . . . . : a.root-servers.net Record Type . . . . . : 1 Time To Live . . . . : 406 Data Length . . . . . : 4 Section . . . . . . . : Additional A (Host) Record . . . : 198.41.0.4
Record Name . . . . . : b.root-servers.net Record Type . . . . . : 1 Time To Live . . . . : 406 Data Length . . . . . : 4 Section . . . . . . . : Additional A (Host) Record . . . : 199.9.14.201
Record Name . . . . . : c.root-servers.net Record Type . . . . . : 1 Time To Live . . . . : 406 Data Length . . . . . : 4 Section . . . . . . . : Additional A (Host) Record . . . : 192.33.4.12DNS Caching & Propagation of DNS Records
DNS Caching is the reason why some DNS Record updates take a while to get propagated to all machines on a network. If the SOA record at the beginning of the zonefile is set to 24hrs, it means it will take at most 24 hrs for all machines on a network to see the updated DNS records.
TTLs or Time To Live
TTLs, or ‘time to live’ values in Zonefiles allow you to force the expiry of individual records, thus bypassing the expiry time referenced in the SOA record on a per-record basis.
For instance, let’s say that opsschool.org has moved to a new web host but it needs to ensure that the service is available as much as possible. By reducing the TTL for the www and * records in the opsschool.org zonefile, the switch between previous and new vendor should be relatively pain-free because it will instruct clients to request an updated zonefile frequently enough to catch the update quickly.
TTLs and caching work well together - with a suitably high TTL and suitable caching in place, the time for a request to be responded to and the time for updated records to exist on caches are both dramatically reduced.
$ORIGIN example.com. ; designates the start of this zone file in the namespace$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL valueexample.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )Reverse DNS
DNS translates a human readable name to an IP address. Guess what Reverse DNS does? yup, it returns the human readable name when given an IP address.
In order for this to be possible, a zonefile must contain PTR Records.
PTR Records
Domain names follow a specific syntax - mydomain.com, where .com is set by ICANN and chosen by you when they register your own domain name (against a fee..).
So how do you “resolve” an IP address to a name?
With reverse DNS, a similar ordered syntax exists as with forward DNS.
Let’s assume that we want to know which hostname responds at 22.33.44.55. We do this as follows:
- Reverse the octets of the IP address -ex:
22.33.44.55becomes55.44.33.22 - Add
in-addr.arpato the end of the reversed address - we now have55.44.33.22.in-addr.arpa - The root nameserver tells queries to find the
arpanameserver (same mechanism as forward DNS) - The
arpanameserver directs the query toin-addr.arpa’s nameserver - The
in-addr.arpanameserver then responds with details of22.in-addr.arpa, and so on… - In the zonefile, the IP address matching the query is then found and the relevant hostname is returned
Private DNS
Resolving www.google.comfrom anywhere on the internet is functionally the same as resolving, say, nas.home.int when I am at my house connected to my own local network however I do not want nas.home.int to be publicly resolvable and most companies do not their private resources to be exposed and visible to the internet either.
This is why companies typically leverage DNS servers that are only accessible within their private network (sometimes referred to as “Private DNS”): it allows companies to define their own domain & their own records / hosts so that they can all be accessed by name when connected to the private network yet remain invisible to the outside world.
Looking to understand how DNS works with Twingate?
If you aren’t familiar with it yet, we recommend you check out how DNS works with Twingate
Last updated 9 months ago