Why does DNS security matter?

Domain Name System (DNS) in simple layman terms is like the good old telephone directory where we get to find the phone number or digits by looking for names to reach them over telephone.

Similarly, every website is hosted on a server bearing a static IP at the given time to reach it. When you type in a domain name like technofaq.org in your browser, it looks for its IP address by asking the same to system’s DNS and this procedure of resolving or translating a domain name into an IP address which is useable at the lowest level i.e. TCP/IP, is known as resolving or name resolution.

No doubt, DNS is marrow of the Internet.

I am sure, you understand the significance of Domain name system by now. Since, we reckon on it for sending us to the right address we are looking for. There are two type of DNS servers, authoritative and non-authoritative DNS server or a recursive resolver or a caching server.

In order to get into the security aspect of DNS, we have to first unveil the whole procedure of name resolution which takes place in the background in a matter of microseconds in generic cases.

There are a couple of DNS servers in place that helps you translate or resolve an IP address from a given domain name. So, when you enter a Domain name for example technofaq.org in your web browser, it is resolved as follows:

Step (1)
Stub Resolver, a software on your system configured with DNS nameservers, sends your DNS query i.e. the IP address for domain name technofaq.org to the server.

|

Step (2)
The server to which your DNS query reaches is either your organization’s internal DNS server or an external DNS server for example your ISP’s DNS server on their site. In this case lets assume we are using our organization’s internal DNS server bearing an IP 192.168.0.101. Internal DNS server knows nothing about technofaq.org, but it has been configured to use one of the 13 logical root DNS server randomly. Logical root DNS servers is a cluster and there is no master. 192.168.0.101 now sends the query to a root DNS server for technofaq.org

|

Step (3)

The root DNS server knows the nameservers of authoritative DNS servers of each and every top level domains. In our case, since we queried for .org, it would pass on the name servers that knows about .org to our internal dns server i.e. 192.168.0.101

|

Step (4)

192.168.0.101 DNS server picks a name server from the list of authoritative TLD servers for .org randomly and resends the query for IP address of technofaq.org to it.

|

Step (5)

Authoritative TLD server for .org is again not so sure about the IP address, but it knows about the name server for our particular domain name technofaq.org, which are configured by an admin of the website, it is usually the DNS service of your domain registrar or external DNS service or your own DNS service in case of large organizations. So, the authoritative TLD server sends a list of name servers that know about specific DNS records of technofaq.org to 192.168.0.101

|

Step (6)

Similarly our internal DNS server again sends the same query to one of nameserver in the list received from the authoritative TLD server above. This nameserver finally know about all the DNS records of the domain name technofaq.org, including but no limited to IP addresses. This DNS server sends the IP address to our internal DNS server, 192.168.0.101

|

Step (7)

Our internal DNS server conveys the same to client in our PC, which originally has a query for the IP address of domain technofaq.org, and finally it gets resolved in web browser.

A single DNS query for an IP address of a domain name travels from your  stub resolver to internal/external DNS server (caching DNS server) to root DNS server to authoritative DNS server for that particular TLD to authoritative DNS server for that particular domain name and finally back to your client PC via a caching DNS server.

How DNS works

Seems like a perfect system? Isn’t it?

Well, you might not believe this, but even in 2017, majority of DNS queries is unauthenticated and unverified by default. A rogue DNS server run by bad guys or attackers can easily tamper with the replies you get from the DNS servers for your query, making you reach a malicious site instead of the real site causing damages. This allows attackers to phish for login information and payment details as well as perform man-in-the-middle attacks. The replies from a given authoritative server is spoofed before it reaches to your caching server owing to lack of any verification on caching server, the spoofed replies are forwarded to the resolver as it is. In order to fix this, DNSSEC is brought as an extension to the DNS.

DNS cache poisoning attack

DNSSEC, stands for Domain Name System Security Extensions.

While DNSSEC don’t address all the security issues that exists with DNS but it does let you verify the replies you get from an authoritative server at a caching server or recursive resolver. DNSSEC basically puts the DNS replies in a transparent envelope, which is sealed just like a regular mail envelope is, by the authoritative server that sends the replies. The envelope is not kept confidential and is purposely transparent because it has DNS replies which are to be read by every caching server or resolver with or without DNSSEC support. DNSSEC is backward compatible and even with this transparent envelope can still be used by normally. Just that DNSSEC enabled servers and client gets to verify the replies providing them with the security that DNSSEC aims to provide.

The above metioned seal on the envelope is technically cryptographic functions. DNSSEC enables clients that support it to verify the integrity of the DNS replies from authoritative servers and it does so by adding additional information to DNS replies. This information is a must to verify the validity of the DNS replies received. DNSSEC utilizes asymmetric public key encryption to sign zone data and it adds the signatures and other information to the zone file, in form of DNS resource records.

Upon successful verification of a DNS reply from an authoritative server by DNSSEC enabled server, you can be sure of the following:

a. The reply came from the authoritative server for the particular domain queried.
b. The reply has not been tampered in transit from the respective authoritative server to caching server
c. If you got a reply that a domain name do not exist (NXDOMAIN or Non-existent Internet Domain Names), you can reckon on DNSSEC as it uses a Next Secure (NSEC) resource record for the same.

By deploying or configuring a DNSSEC enable caching server in your resolver you can actually validate the DNS replies as sent from an authoritative server and rely on it to know if the DNS answer has or has not been tampered with or spoofed anywhere in transit before it reached a caching server or resolver. It also prevents DNS Cache poisoning other than DNS spoofing.

Nowadays, you can also download and use an add-on available for major browsers to validate DNS records by using DNSSEC known DNSSEC/TLSA Validator, made available at https://www.dnssec-validator.cz/

There is yet another issue with DNS. Since the link between you and the caching server is not encrypted by default in most of the cases, it leaves enough room for attackers to snoop if not the spoof your DNS queries infringing your privacy and possibly threatening your security depending on the situations, especially when you are using an external caching server or accessing a public caching server hosted by you inside your secure network from a remote place. DNScrypt and identical DNS-over-HTTPS by Google comes to rescue.

DNSCrypt is a protocol that prevents tampering, eavesdropping, and spoofing, greatly enhancing privacy and security between a client and a caching DNS server or recursive resolver by authenticating communication between them. It is a protocol with open specification and implementations and is easily available on all the major platforms today. Beautiful thing about DNScrypt is that it does not require any alteration or configuration to the current domain name system. It encrypts regular DNS traffic just like TLS security does with your webserver traffic. Although, DNScrypt is not using SSL/TLS as per to encrypt the DNS traffic, instead elliptic-curve cryptography is deployed. Also DNScrypt can be configured using either protocol UDP or TCP which is additional mileage.

DNSSEC does wonderful things, but DNSCRYPT is as much required to protect and encrypt the DNS traffic from client to a caching server or a recursive resolver. If used together DNSSEC and DNSCRYPT could be one of the best buddies in DNS security field to avail end-to-end name resolution.

DANE or DNS-based authentication of Named Entities is a new protocol that utilizes DNSSEC’s alternative public key infrastructure and same is used to verify TLS certificates using DNS. DNSSEC can be used to store and retrieve cryptographic keying material including but not limited to public keys, X.509 certificates in the DNS records. The beauty of this protocol is that this can be in addition to the already existing verification of TLS certificates by traditional public CA infrastructure in place or can also replace it completely where the newer DNSSEC is fully working and has been deployed, which is the case with majority of popular TLDs.

DANE allows you to rely on the DNS (DNSSEC) by precisely specifying a TLS/SSL certificate that a given application or service should be using to connect to your site, and if a web browser that supports DANE happens to know that it is not doing so, it can warn you.

DANE has significantly improved security for protocols and application making use of TLS like HTTPS, SMTP, XMPP and many more. It facilitates finding keys for end users and system in a secure and scalable manner. It also fixes known defects in traditional public CA model. The problem with verification of TLS certificates by public CA is that a system blindly trusts all the current public CAs because this is how it works. Owing to design flaws any given CA from the list can issue a certificate for any server or client depending on their reputation, it could be by error or with malicious intent.

DANE protocol introduces TLSA DNS record type to the DNS, which is nothing but a simple record uniquely describing a key you will see and need when you connect and DNSSEC ensures and validates its authenticity. Use of DANE in SMTP over TLS has gained more attention owing to the checks it put on the downgrade attacks in SMTP over TLS. With DANE, TLSA records in the DNS confirms the intention to use TLS security and authenticates it DANE protocol based on the secure DNSSEC. More DANE DNS records types are in labs worldwide to avail the security offered by it to more applications.

A mass adoption of DANE and other DNSSEC based/enabled protocols and extensions is a must or else these verifiable security features would have no use.

Although, DNSSEC has already been deployed in majority of TLDs for us to make use of secure protocols like DANE over it, but it is not universal as of now and lacks mainstream or native support. It might be available as an add-on in popular web-browers and other applications. We have already talked about a plugin/add-on made available at https://www.dnssec-validator.cz/ which validates your DNS records using DNSSEC and now checks for TLSA records too.

It won’t be wrong to say that DANE protocol has managed to upgrade TLS authentication to a whole level.

As you have read, security features offered in DNS utilizes DNSSEC and other protocols based on it. Without support for it, you cannot really do much about DNS security. DNS security without DNSSEC cannot be imagined, the only issue is it being purely voluntary.

There is still things like DNScrypt or DNS-over-HTTPS which manages to securely encrypt your DNS traffic and is independent of DNSSEC. But this is not all, we also have DNS Certification Authority Authorization (CAA).

DNS Certification Authority Authorization (CAA), uses the Internet’s domain name system to allow the admin of a domain name to specific which Public CA(s) are allowed to issue certificates for that particular domain name by introduction of a new DNS record type know as CAA or Certification Authority Authorization. This removes the possibility of weak or rogue public-trusted CA to issue certs for your domain name. During the time of proposal it was made voluntary. But seeing the events of irresponsible and malicious attempts by a few public-trusted CAs in recent past, the CA/Browser forum in March 2017 has voted in favour of mandating all public-trusted CAs to implement a CAA checking. The whole industry gave a prompt green signal to it and starting 8th of September this year, all CAs are required to uphold CAA records.

As read, DNS security as of now starts with verification and authentication of DNS records by using DNSSEC and also ventures out in other prominent field like TLS security and much more with advent of new DNS records types like TLSA utilizing DANE protocol and simple DNS records like CCA mandating  CAs to be serious and technically verify things before they issue certs unlike in the past. And then there is encryption of link from client to a caching server or recursive resolver using protocol like DNScrypt or DNS-over-HTTPS which promotes end-to-end security, privacy and integrity of DNS data in transit.