An epic journey awaits: The hows and whys of DNS (and why DNS privacy is important)
(Above: The logo of Cloudflare's new announcement. Read on to find out more! Sourced from here.)
Hello! I hope everyone had a nice restful Easter. Cloudflare made an exciting announcement recently (more on that later), which inspired me to sit down and write about a vital, but invisible, part of the internet we know today.
It's called DNS (Domain Name System), and I'd like to take you on a journey - showing you what DNS is, how it works, how it can be exploited, and what we can do about it. After all, privacy is important! How does relate to DNS you ask? Well, I'll show you - but we're getting a little ahead of ourselves. Let's introduce DNS first. I'll explain what it is, how it works, and why we need it.
Enter Stage Left
DNS is, in many ways, the backbone of the modern internet. While it isn't directly responsible for delivering billions of packets across the internet every day like the Internet Protocol is, its role is still vitally important. DNS is responsible for translating domain names, such as starbeamrainbowlabs.com,
billsboosters.net into an IP address that your device can connect to in order to do whatever else it needs to do.
It does this by sending a UDP datagram (comparison with TCP) to a DNS server ask it for a specific type of response - usually the IP address associated with a specific domain name. The following query types are most common:
A- Returns the IPv4 address(es) associated with the specified domain name
AAAA- Same as
A, but returns IPv6 addresses instead
CNAME- Acts as an alias to another domain name. Usually immediately followed by either an
AAAArecord in the DNS server's response to save time (a DNS server can return multiple items in a single response)
MX- A bit like a
CNAME, but returns a prioritised list of domains that handle email for the specified domain.
TXT- Contains an arbitrary text string. Usually used for easter eggs or for domain ownership verification by various analytics services (e.g. Google Analytics, Bing Webmaster Tools, etc.)
NS- Specifies which DNS servers can be queried about the domain.
SOA- Specifies what the primary DNS server is that holds the authoritative copy of the DNS records for the specified domain.
Let's try it out
With that in mind, lets try some queries.
(Can't see the above asciicast? Try viewing it over on asciinema.org, or entering the below commands into a computer with DiG)
dig starbeamrainbowlabs.com dig bbc.co.uk AAAA dig cloudflare.com MX dig contact.starbeamrainbowlabs.com TXT dig github.com TXT
DiG is a command-line DNS client for Linux-like operating systems (if you don't have it already, try
sudo apt install dnsutils, or equivalent for your distribution. If you're on Windows without access to a Linux-like machine, try following along with nslookup.). In the above asciicast I make a variety of queries for demonstrative purposes. Note the
QUESTION SECTION and
ANSWER SECTION bits - they tell us what the query was for, and what the response to that query was. For example, here's an extract from the question and answer sections respectively from the
bbc.co.uk lookup in the asciicast:
;bbc.co.uk. IN AAAA
bbc.co.uk. 300 IN AAAA 2a04:4e42:600::81
The bit in the question section is quite straightforward - it's asking for an
AAAA record for
bbc.co.uk.. The answer section is a bit more complicated. From left to right:
bbc.co.uk.- The domain name the response is for.
300- The time-to-live. In other words, the number of seconds that the response can be cached for.
IN- a legacy component. Stands for INternet - more information here
AAAA- The type of response record.
2a04:4e42:600::81- The IPv6 address that the domain name corresponds to.
Am I being spied on?
DNS works rather well, most of the time. The problems start to occur when you start thinking about privacy. With more websites than ever now serving their websites over https, the data that we transfer between these websites and our devices is now much more secure - and can't be intercepted, analysed, and modified in transit.
DNS, however, is not currently encrypted - which poses a rather serious problem. Anyone able to get a hold of your devices network traffic - such as another device of your network in promiscuous mode, your ISP, or literally anyone in between you and your DNS server - can spy on the DNS lookups your device is doing, and even poison your DNS cache - sending you to an attacker's website when you typed in a legitimate domain name!
(Above: A DNS timing cache poisoning in action. The attacker responds with a spoofed UDP datagram before the original server has a chance to reply!)
Thankfully, after 35 years of DNS, the internet has some solutions to some of these problems. First up: DNSSEC. Often misunderstood, the protocol tries to prevent man-in-the-middle and timing attacks (such as the one shown in the diagram above) by cryptographically verifying the DNS records returned to the client. Though it's actually 20 years old already, it's still overly-complicated - and subsequently hasn't been rolled out by an awful lot of people. It's also rather weighty - requiring the transfer of crytographical keys and other associated information.
Preventing cache poisoning is one thing, but it would be nice to prevent nosy onlookers from peering at the DNS queries we're making - and here's where it gets complicated. As of early 2018, there are currently no less than 3 competing standards to provide proper client-server connection encryption:
- DNS-over-HTTPS - Basically a protocol for sending DNS requests via a standard HTTPS web server. As you can imagine, this can be rather weighty.
- DNS-over-TLS - As the name implies - DNS queries over a raw TLS connection - which is, in short, a HTTPS connection without the HTTP bit. Now supported natively in Android.
- DNSCurve - An augmentation to the existing DNS protocol that adds encryption by way of elliptical curves. The supposed official website appears to be a bit biased and inaccurate, so I'm linking to the Wikipedia article here.
A bit of mess, isn't it? Furthermore, many applications don't yet have support for some (or any) of these protocols. In that regard, it's currently a waiting game. Still, it's interesting to compare the different approaches taken here. Most of these protocols carry significantly more weight that plain-old DNS - with DNS-over-HTTPS being the most weighty, and DNSCurve being the lightest I should imagine.
I find it especially curious that DNS-over-HTTPS is as popular as it is. Surely it's a bit flawed if you've got to look up the domain name of the HTTPS server that you need to contact in order to do a 'secure' lookup? A safe is only as strong as it's weakest point, after all....
But wait, there's more!
Encrypted and verified responses are all very well, but it's no good of the owner of the DNS server themselves are logging all the queries you send to them! Google's 184.108.40.206 service logs a percentage of queries made permanently to disk, and OpenDNS don't appear to have very many details on their website about what data they collect and what they don't!
Furthermore, some DNS servers (especially those controlled by ISPs) tend to have some domain names censored due to agreements with their country's government - preventing you from 'accessing' a website by stopping your device from figuring out where on the internet to talk to.
Clearly, these are serious issues - and the solutions boil down to trust. Who do you trust to send your DNS queries to? If you don't trust any of the aforementioned providers (Google Public DNS or OpenDNS), then you could always run a DNS resolver yourself.
How does it work if you run it yourself? Well, basically instead of your device sending queries to a remote DNS server, they send it to your personal DNS server instead. Your personal DNS server then performs a recursive resolve. Basically, this means that it traverses the requested domain name from right-to-left, analysing and resolving each part in turn. For example,
gateway.discord.gg. would be resolved like so:
For each successive part of the domain name, the DNS server asks the next one in the the chain that other DNS servers hold the authoritative records about that domain name (using
NS records), and then repeats the cycle with the servers provided in the response.
Quite quickly you can see that there's an issue here - how does it know where to start? That's where root servers come in. They contain the authoritative information on the Internet's top-level domains. These servers can be queried to figure out which servers hold information about the various country codes (or other codes). The servers that these root servers point to can then be queried to ask who holds information about the various domain names you and I are used to typing in our address bars, such as
billsboosters.edu for instance.
A simpler alternative
This brings me to the announcement by Cloudflare I mentioned at the beginning of this post. By now, you can probably guess what it is: they've set up a new public DNS server! Apparently, they did a deal with [APNIC]() to let them study the garbage traffic that ends up at 220.127.116.11 in exchange for running a DNS server on it.
Either way, I think it's a brilliant thing for the Internet at large to have another public DNS network to choose from. Especially considering how privacy-conscious they appear to have being in setting it up: They never store client IP addresses, and they delete the anonymised logs after 24 hours. Assuming what they've said is true, I think that it's rather great. For my own personal reference, here are the IP addresses of Cloudflare's new service:
That brings us to the end of our journey through DNS. We've seen what DNS is and how it works. We've also seen how it can be attacked, and what is being done about it. Lastly, we've taken a look at how running your own recursive resolver works, and looked at Cloudflare's new service.
If you'd like to continue on and explore DNS further, I've left some links below.
Found this informative? Still confused about something? Comment below!
Sources and Further Reading
- Why is there a dot at the end of my domain name?
- What is the IN bit in a DNS record?
- DNS Spoofing vs DNS Cache Poisoning
- What is a DNS Cache (and how can it get poisoned)?
- Security Now: The DNSSEC Challenge (Scroll to page 9)
- The DNS Privacy Problem
- Cloudflare announcement:
- Fix DNS resolution issues on Ubuntu by replacing systemd-resolvd with unbound
- Installing and configuring unbound on FreeBSD 10.1