./intro
Domain Name System (referred to as DNS from here onwards) is one of the oldest protocols/technology’ stacks that we still use on our Networks.
Its origins date back to 1987 when its original RFCs were made public (they were two, RFC1034 and RFC1035).
Back then, no security controls were added to the DNS specification.
Over a decade went by, the WEB took over (and neither the Information at your fingertips or Information Superhighway projects saw their market release) and as a result, DNS started being used in large scale on the internet. Only then — in the early 90s — after many political discussions around cryptography and internet privacy (and internet security — see RFC6973) took place, it was decided that some Security controls for the protocol were needed.
The purpose of this document is to expose what the proposed solutions were and where we stand nowadays with regards to Security for the DNS infrastructure. This will serve you as a guide for further research on the subject, I’ve made sure to share a substantial amount of references and sources on the topics so that you do that later.
./dnsfoundation
Before you move on, it may be worth a review on how DNS works.
DISCLAIMER: I DO NOT intend to take an in-depth look at this, if you’re looking for a detailed explanation on how DNS works, I recommend thisexplanation.
In a nutshell, DNS is a system to translate domain names to IP addresses on the internet (people like the analogy that DNS is the phone book of the internet — and so do I :) ).
At the end of the day, though, a DNS is ultimately going to provide an IP to a Domain query, this is called DNS resolution.
Some actors involved in the DNS resolution process are:
a. Web-enabled Device
b. DNS resolver (either Local, or Internet-based)
c. Root DNS servers (internet) — These are known as “Authoritative Name Servers” and they are the “source of truth” for the:
Top Level Domain Authoritative Name Servers (internet) — these are the .com , .net and country specific .br , .ar , .nz domains (there are over 1500 TLD as seen here). These redirect users to the intended domain IP address.
From the DNS specification, there are 3 possible DNS resolution scenarios: (1) stub to recursive resolver, (2) recursive resolver to authoritative server, and (3) server to server. I’ll refer to these scenarios in a broader way, for scenarion (1) as :User to resolver” and for (2) and (3) as “DNS Infrastructure resolution”.
From a User perspective, there’s nothing to know besides the IP address of its DNS server responder and that is shared by the DHCP server of the network.
This communication happens by default through a UDP packet in port 53, as defined in the original DNS protocol.
Image 1 represents the user perspective of a DNS resolution.
Image 1 — Host DNS query to DNS server
From a Network admin perspective, you’ll have to decide whether to: (1) deploy and maintain a Recursive DNS server interfacing with Root/TLD, or; (2) to deploy a DNS forwarder and rely on public (recursive) resolvers who will do that for you.
For whatever model the network admin chooses to deploy it’s worth understanding the 2 methods a DNS server can operate: Recursive and Iterative.
Recursive
This is when the server receiving the request will do all the fetching related to the Original Query.
The fetch includes this DNS server checking:
- Its Cache Database, if response is not found, then:
- Liaising with Authoritative and Root DNS servers on the internet, using the next DNS resolution method (iterative).
It will then respond back to the original query with the IP address of that domain.
This infers that all the load for resolving a DNS query is on the DNS (recursive) server.
Iterative
This method is when the server simply checks its own DNS records Database and replies to the original query.
Response from this sort of DNS server will include:
- Final response, if not found, then;
- Referral to next Authoritative Name Server that will be able to assist.
It’s up to whoever is querying then, to make a new request to this new referred DNS server.
This method then, puts the load of resolving domains on whoever is querying a domain.
From a network admin perspective, then, it’s definitely worth investigating if a public recursive resolver isn’t the best solution for your environment.
In most cases they will be, since these generally provide some sort of DNS sinkhole feature for protecting your users from known malicious domains — and they need less maintenance from an IT perspective. I will not cover this feature of recursive DNS resolvers in this article.
This all comes together for a DNS request resolution, in a similar fashion to what image 2 shows.
Basically, the User device interacts with a resolver, who in turn interacts with multiple nodes (Root/TLD/Authoritative Name Servers) resolving each section of a URL with the appropriate Party.
image 2- example of DNS query resolution
It’s a High-level explanation (missing details about the use of cache for fetching info, root servers exposition) of what could happen in a given DNS query resolution.
Another few key concepts:
At the top level Domain, there will be a number of DNS Resource Records (RR) stored in the Start Of Authority (SOA) of a domain.
The SOA, therefore, is a list of Resource Records of a given domain including Time To Live for DNS information for that domain and even hostname information.
Resource Records, in turn, are the many services provided by a domain, such as WEB server, EMAIL server, Canonical Names (CNAME) and a lot more.
I recommend this list (http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml) for “all things DNS Resource Records”.
./dnssecurity
When it comes to Security for DNS, this is -historically- an unheeded subject.
In recent years — largely due to the widespread use of internet in portable devices, political and privacy scandals and attacks happening against DNS servers — there have been many developments in the subject.
./dnssecurity/why
Why would you ever consider implementing any of the solutions below?
Privacy, Espionage, User navigation history, Denial of Service, Data exfiltration and other security concerns.
To put in better perspective, common attacks against DNS systems include (but are not limited to) can be seen in the chart below.
chart 1 — example of attacks that abuse the DNS
There are attacks that leverage the DNS infrastructure such as Typosquatting (when malicious actors will register a fake domain changing a few characters of the valid one, used for phishing), and Domains Generation Algorithm (known simply as DGA, when hackers use algorithms to automate and to register new domains to host their payloads or other attack-relevant pages).
./dnssecurity/history
The DNS did not have security controls in-built (much like the Web itself I must say). With the large scale adoption of the protocol and after security flaws were discovered the industry started paying more attention to the need of enforce security controls in it.
At first, it was decided to address the issue of authenticity of the DNS records stored on Root/Authoritative servers.
A proposed solution started being discussed circa 1995, the DNS Security Extensions (DNSSEC) protocol, with the first RFC for it coming later, in 1997 (RFC2065).
The protocol was finalized (or ready to be deployed) with the release of RFC2535. BIND was the first DNSSEC-compatible DNS server.
However, deployment remained stalled for years, due to unexpected problems in performance, this led to new RFCs being released in 2005 (RFC4033,4034,4035).
DNSSEC never proposed a solution to DNS exchange encryption, and this led to the developments of many options for DNS exchange confidentiality in the following years.
Around 2008 a security researcher and the open source community developed DNScurve and DNScrypt to tackle both — encryption and authenticity of DNS records.
Around 2011 DNS started being used to verify the validity of a TLS certificate with the introduction of the protocol DANE (DNS-based Authentication of Named Entities).
By 2013, DNSSEC became the official solution for generic Top Level Domains (TLD), since then the Internet Corporation for Assigned Names and Numbers (ICANN) started requiring the use of DNSSEC on these TLDs.
As of 2014, the Internet Engineering Task Force (IETF) created the DNS Private Exchange (DPRIVE) working group — originally to lead the research in the field of securing Client DNS to Iterative DNS servers (since then its scope is expanding, looking for DNS security solutions for other DNS servers and even End-to-End security to the protocol).
As of 2019 many large Web services providers started supporting different DNS privacy protocols. For instance, “Mosaic Killer” Firefox started supporting DoH officially this year (2019) though it still isn’t set by default; while Chrome still has no official support for it, but its public DNS resolver does support DoT.
./dnssecurity/solutions
Due to the large number of systems involved in a DNS query resolution, going over all the potential points of flaw and the security holes becomes an extensive task quite rapidly.
In order to better organize the solutions we have for the matter, I find it easier to separate the DNS in 2 main “zones” since each has their own security challenges and effectively their own security solution goals. This is by no means an official and widespread separation of these solutions, but merely the best way I found to address the topic until now.
These zones cover 2 of the 3 information security triad “CIA” (Confidentiality, Integrity and Availability).
Firstly in what I’ll call zone 1, taking care of the Confidentiality of DNS queries. This is relevant for user as well as infrastructure queries.
And Secondly in zone 2, the Integrity and Authentication of the DNS queries and records — generally performed on the back end of the infrastructure.
The Availability component is not addressed by any of these protocols (rather, it’s taken care by solutions such as Anycast).
A few noteworthy mentions:
- There are solutions that envision to secure End-to-End DNS queries. They effectively provide answers to resolve both concerns above.
- All solutions mentioned herein require software running in both/all parties to work, i.e.: DNScrypt requires clients and servers to be running some sort of software to be able to exchange DNS securely.
To better represent these 2 zones I re-imagined the image 2 with the zones on top the devices, this can be seen in image 3, below.
image 3 — zones that are addressed by DNS security solutions
./Confidentiality
To protect User queries to DNS servers, we need solutions that can provide Confidentiality between these peers.
This means encrypting the DNS transport traffic. So the main driver for choosing among the options below will be:
- Encryption ciphers available;
- Efficiency while running in host devices;
- Ports used to communicate with upstream DNS servers (if a port is blocked between your host and your DNS resolver, many times the host will fallback to regular unencrypted DNS through port 53 — defeating the purpose of privacy).
These are some of the most common solutions for this:
2008 — DNScrypt
2013 — Confidential DNS
2015 — DNSoD — DNS over Datagram Transport Layer Security
2016 — DoT — DNS over TLS
2017 —DoQ — DNS over QUIC
2018 — D0H — DNS over HTTPS
./DNScrypt
One of the most used protocols for DNS transport security is one that’s basically been built by the Open Source community, not a standard as some people would expect.
It was first introduced in 2008 and it relies in DNScurve to securely exchange keys and encrypt DNS queries between Users and DNS servers.
Around 2011 it was adopted as one of the security mechanism for the Internet-based DNS resolver “OpenDNS” (now Cisco Umbrella).
It works by having a stub client (an application/process) listening for DNS (UDP port 53) queries in a system. This requires having the device routing all DNS queries to the localhost (127.0.0.1).
Once a DNS query is seen, the stub then encrypts traffic and sends to specific resolver.
Does not focus on end-to-end DNS security, rather, its implementation aims at protecting User to DNS server communication.
Specification: https://dnscrypt.info/protocol
./ConfidentialDNS
Released back in 2013, the first draft for the “Confidential DNS” protocol promised confidentiality by adding 2 new functions to a DNS resolution workflow.
These 2 functions were:
- The use of a new DNS Resource Record (RR), called ENCRYPT which is cacheable, and;
- A (optionally cacheable) Shared secret between stub and resolver to ensure confidentiality.
These changes allow for opportunistic encryption of DNS requests to DNS resolvers. This means that when using “confidential DNS” a stub (host) will check if the Resolver supports the resource record “ENCRYPT”, if it does, stub and resolver will exchange a shared secret encrypted via a public certificate specified in the ENCRYPT RR, after this all communication is then encrypted between parties.
If while no ENCRYPT RR is found in the resolver, then the DNS exchange does not use encryption, thus why this is an “opportunistic” method. This , effectively, allows for an active attacker to exploit and force stubs to use unencrypted resolutions — deeming it useless for privacy purposes.
Confidential DNS also allows for authenticated operation, in this scenario leveraging DNSSEC to authenticate both parties in an exchange.
This protocol was not adopted in large scale. There are many drawbacks to the different methods it allows (opportunistic/authenticated) thus posing some challenges in deploying it.
./DNSoD
DNS over DTLS is the use of DTLS to secure user to DNS traffic.
DTLS is Datagram over Transport Layer Security and was designed prior to its use for DNS resolution, see IETF’s RFC4347 from 2006.
Without getting in much details on what DTLS is, it is the ability to provide the same level of TLS encryption over Datagrams.
Quick recap on what Datagrams are, they’re the traffic that is not reliable (as opposed to its counterpart, Transport Control Protocol (TCP), which provides reliable traffic exchange in the transport layer, and thus, the DTLS protocol was mainly designed to be the secure implementation for unreliable traffic (Datagrams) since TLS cannot be implemented over unreliable transport protocols.
It was released at a time when multiple protocols were being released for this sort of transport traffic such as SIP and others, and the main reason for this was that developing secure protocols relying on application layer protocols required a lot of effort.
DNSoD had its first draft in 2015, since then, it never reached a final RFC. The latest draft dates back from 2017.
This last [and experimental] draft mentioned how DNSoD should use port 853 for secured DNS over DTLS.
The motivations for using DNS over DTLS are 2:
- In case a TCP connection suffers from packet loss the whole following segment is lost and requires retransmission.
- DTLS sessions resumption require one round trip whereas TLS resumption requires the TCP handshake to be completed before done.
DNSoD was never adopted in large scale.
./DoT
DNS over TLS leverages encrypted TCP packets to wrap the DNS queries and send to a supported Resolver.
The standard is defined in RFC7858 and states that by default, stubs should connect to resolvers through port number 853. The stub should have previous access to the resolver’s TLS certificate. By using the certificate, then the stub handshakes with the resolver and creates an encrypted tunnel so that DNS queries are resolved through it.
The good thing about this protocol is that it relies on the encryption ciphers provided on the TLS protocol — and yes, TLS 1.3 is supported here.
This protocol has Google’s support (their public DNS resolver supports it), matter of fact, Android supports DoT since the “P” release.
Requires the stub to have access to the resolver’s certificate and the network to allow access to internet through port 853.
./DoQ
DNSoverQUIC
First of all, what is “QUIC”? It’s a multiplexed secure transport protocol that runs on top of UDP. It’s an alternative transport protocol aimed at compatibility with legacy clients and middleboxes. It encrypts most of the data it exchanges. It dates back to 2012, but up until now is still a draft with IETF.
DNS over QUIC is then leveraging this new secure transport protocol to resolve DNS queries. This is relatively new standard hasn’t seen wide adoption yet, thus is limited in terms of where you can deploy it.
It is a promising solution for the next iteration of DNS security since HTTP over QUIC is backed by Google and IETF, which it has agreed on it becoming HTTP/3.
./DoH
DNS over HTTPS, or DoH in short, has seen the light of (RFC) days in 2018, backed by Mozilla and other companies.
The way it works is by using an HTTP exchange to carry a DNS query-response pair, using HTTPS (thus TLS encryption).
Where this solution really shines is in its mere simplicity, leveraging a regular known port (443) that is already allowed in most organizations, using an application protocol that every host already has through browsers (HTTPS) using an encryption protocol that is proven and that can be modified as the standards evolve. A perfect combination to solve the challenges we’re trying to solve.
Just a minor note, in terms of network management and visibility, having your users’ DNS queries being done through the HTTPS port is seen as a limitation rather than a feature, due the fact that as the admin, you cannot keep track or control of DNS traffic.
Its Standard proposal can be seen in full in RFC8484.
./Integrity&Authentication
When it comes to securing DNS servers’ records exchange and its Integrity the main goals we need to achieve is basically:
- Validation of peer
The most popular proposed solution is:
1997— DNSSEC
./DNSSEC
DNSSEC is the “grandfather” of DNS security. IETF have an RFC about that topic dating back to 1997 — when the first RFC about DNSSEC was ever issued. This was RFC2065.
Ever since its conception, DNSSEC was all about securing DNS servers’ responses integrity and authentication. It was never intended to enforce privacy on the DNS exchanges.
You can check how it works in depth here. Basically, it uses Public keys to sign, thus authenticating, all DNS records exchanges — adding to the DNS exchange: origin authentication and integrity assurance.
This solves the issue of DNS cache poisoning — where a malicious actor injects a forged DNS record into the cache of the DNS resolver.
After 20 years of the initial protocol proposal, adoption for DNSSEC still hasn’t reached the in the industry. Certainly is has been widely adopted by Top-Level Domain Zones as seen here but there’s still a long way to go with the second level domains.
However, there have been many relevant companies supporting and implementing it on their infrastructure a few examples of registrars are Google, GoDaddy among others and even resolvers like Quad9 and Cisco Umbrella.
Currently, the most exciting aspect of DNSSEC is that it is the underlying technology powering a new protocol called DANE (DNS-based Authentication of Named Entities).
./noteworthymentions
There are 2 technologies that are important to many of the protocols mentioned above. DNSCurve is an important encryption method developed by Dan Bernstein — it allowed for the creation of DNScrypt. The second one is seen as a great solution to authentication using DNSSEC (and thus TLS). They are:
2008 — DNSCurve
2011 — DANE
./DNScurve
This is a DNS encryption method developed on top of an Elliptic Curve Cryptography developed by Information Security Professional and cryptographer Daniel J. Bernstein.
The ECC is called “Curve25519” and was designed following IEEE criteria for Public Key Exchange. It then uses the algorithm XSalsa20poly1305 for encryption.
You can go crazy technical about it here: http://www.dnscurve.org/crypto.html
DNSCurve uses the Public Key of both parties to encrypt and secure the DNS exchange between them.
OpenDNS started using this method circa 2010 to encrypt its users request and still uses it as part of DNScrypt.
./DANE
This is such a good example of the use of DNSSEC. DANE leverages public key infrastructure contained in adomain certificate to validate the authenticity of a web request.
When you’re connecting to a domain via TLS when you see the padlock close to the URL field of browser you expect to be connected to the domain you entered, right?
Well, that’s not necessarily the case. That padlock sign only means that your browser trusts whatever certificate is being sent by the network to your browser.
So users may think that they’re directly connected to a website, when in fact all their interaction/conversation is being proxied (monitored/recorded) by a Man-in-the-middle.
Here’s where DANE comes in handy, a protocol introduced to validate device to domain connections, thus looking to prevent interception between both parties.
It was introduced around 2011, with the bold premise of taking TLS authentication to a next level by using DNSSEC.
It’s been adopted by major vendors as an additional layer of security for Email security platforms, where DANE allows for the check of all email sender domain’s infrastructure.
./conclusion
DNS Security is by no means an easy topic, to get a complete picture of everything we need to address when discussing the topic requires an immense amount of knowledge on the many number of possible protocols to achieve the ultimate goal of privacy and assurance of Domain resolution.
In general, it seems that to address Privacy, the future is looking good for DoH due to its implementation through a regular HTTPS port and support by major browsers — DNS over QUIC is my long-term bet though. As for the Integrity, DNSSEC is seeing an industry resurgence due to newer solutions relying on it, such as DANE.
Hopefully this has given you a good idea of what you need know to design a secure DNS infrastructure. Now it’s up to you to decide whether you want to be a master in all these topics or you want to rely on a consultant.
./sources
- Tools — diagrams have been made with https://draw.io
- IETF DNS RFC 1034 https://www.ietf.org/rfc/rfc1034.txt
- IETF DNS RFC 1035 https://www.ietf.org/rfc/rfc1035.txt
- IETF internet Privacy https://tools.ietf.org/html/rfc6973
- How DNS works — recursive vs iterative https://www.slashroot.in/difference-between-iterative-and-recursive-dns-query
- How DNS works — Detailed explanation on DNS actors/functioning http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
- How DNS works — deployment models https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/reviewing-dns-concepts
- How recursive DNS works https://www.verisign.com/en_US/website-presence/online/how-dns-works/index.xhtml
- How DNS works — Resource Records http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
- Why DNS security best practices https://www.cisco.com/c/en/us/about/security-center/dns-best-practices.html
- Why DNS security by cloudfare https://www.cloudflare.com/learning/dns/dns-security/
- Why DNS — abuses https://abusedns.com
- Why Amplification attack https://www.us-cert.gov/ncas/alerts/TA13-088A
- Why Domain hijacking http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
- Why DNS hijacking in action https://www.wired.com/story/sea-turtle-dns-hijacking/
- History — DNSSEC timeline https://www.dnssec-deployment.org/history/timeline/
- History — DPRIVE working group https://datatracker.ietf.org/doc/charter-ietf-dprive/
- History — Mozilla supports DoH https://www.zdnet.com/article/how-to-enable-dns-over-https-doh-in-firefox/
- History — Google public DNS supports DoT https://developers.google.com/speed/public-dns/docs/dns-over-tls
- Confidentiality — DNScrypt protocol specification https://dnscrypt.info/protocol
- Confidentiality — Dnscrypt use in OpenDNS https://github.com/opendns/dnscrypt-proxy
- Confidentiality — Confidential DNS first draft https://datatracker.ietf.org/doc/html/draft-wijngaards-dnsop-confidentialdns-00
- Confidentiality — Confidential DNS https://datatracker.ietf.org/doc/html/draft-wijngaards-dnsop-confidentialdns-03
- Confidentiality — DTLS protocol specification https://datatracker.ietf.org/doc/html/rfc4347
- Confidentiality — DNSoD [experimental] protocol specification https://datatracker.ietf.org/doc/rfc8094/
- Confidentiality — DoT protocol specification https://tools.ietf.org/html/rfc7858
- Confidentiality — DoT https://www.infoblox.com/glossary/dns-over-tls-dot/
- Confidentiality — DoT protocol https://developers.cloudflare.com/1.1.1.1/dns-over-tls/
- Confidentiality — DoT supported on Android https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
- Confidentiality — DoH RFC https://datatracker.ietf.org/doc/rfc8484/?include_text=1
- Confidentiality — DoH how it works https://blog.apnic.net/2018/10/12/doh-dns-over-https-explained/
- Confidentiality — DNS over QUIC first draft https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/01/
- Confidentiality — QUIC transport protocol https://tools.ietf.org/html/draft-ietf-quic-transport-02
- Integrity — DNSSEC details https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
- Integrity — DNSSEC how it works https://medium.com/iocscan/how-dnssec-works-9c652257be0
- Integrity — DNSSEC adoption https://www.internetsociety.org/resources/doc/2016/state-of-dnssec-deployment-2016/
- Noteworthy — Dnscurve technical details http://www.dnscurve.org/crypto.html
- Noteworthy— dnscurve https://dnscurve.org/in-benefits.html
- Noteworthy— dnscurve 2 https://umbrella.cisco.com/blog/2010/02/23/opendns-dnscurve/
- Noteworthy— Daniel J. Bernstein https://en.wikipedia.org/wiki/Daniel_J._Bernstein
- Noteworthy— DANE description https://www.internetsociety.org/resources/deploy360/dane/
- Noteworthy— DANE taking TLS authentication to next level https://www.ietfjournal.org/dane-taking-tls-authentication-to-the-next-level-using-dnssec/
