Secure Your Network with DNS: Episode 3 – Ensuring Security Through Integrity

This blog is the third of four episodes which help describe best practices for utilizing DNS to protect your overall network.

End users most likely don’t care much about the domain name resolution process. It simply works – otherwise they feel their internet connection is broken. Yet, DNS is the key component of their network directing them to the service/content they expect to reach. But could they detect a trap if they were being routed by a fake traffic officer? In other words, is DNS trustworthy ? Maybe not as much as you might think.

If you had read our previous blog post, you are already familiar with the “AIC” triad (Availability, Integrity and Confidentiality) and probably wonder what’s behind the “I” of Integrity. Well, from DNS perspective, integrity is all about ensuring that the answer to a query comes from a legitimate source and remains unmodified when transiting over the network. This is all about ensuring that the answer to “www.google.com” comes from the authoritative name servers belonging to Google and that the answer is accurate. If that’s not the case, you might end up being redirected straight to a malicious service/content. Some would say that HTTPS is sufficient protection. Not at all. Stolen certificates can be bought on the black market, certificate issuers can also be tricked to issue a certificate to the wrong person (a good example being Let’s Encrypt), and weak ciphers leveraged to trick the browser itself.

Disappointingly, integrity mechanism was simply not considered during the specification of the original DNS protocol. It was only in the late 90’s that a final RFC introduced the basis of a viable solution – DNSSEC. Unfortunately, DNSSEC remains poorly deployed and only partially covers the needs of DNS security. Once again, minimizing risks requires compliance with several best practices until DNSSEC deployment becomes the norm.

First things first, a key practice when considering DNS security is to prevent anybody from answering queries on your behalf. This requires the following:

• Maximize DNS service availability and efficiency. Not answering a query, or taking too much time to provide the answer leaves the opportunity for someone else to answer in your name. This is mainly possible because, for performance reasons, DNS relies on UDP, which is a stateless protocol.
• On enterprise networks, filter DNS packets properly. Only internal DNS resolvers should be able to query public name servers, if necessary. Forgetting to do so will leave an open door to the internet on your network, undermining its overall security.

Second, prevent answers from being corrupted. Avoid mixing DNS recursive and authoritative functions to avert cache poisoning attacks, and leverage DNSSEC on both. On the authoritative side, this will give clients who consume your web services the ability to ensure that the DNS answers they receive came from your name servers and can be trusted. On the recursive side, this will allow you to ensure your internal client devices are directed to the legitimate service/content, and not to rogue ones.

Also, remember to prevent DNS updates from untrusted sources and avoid mixing the use of DNS zones. A client device must never be authorized to update a zone where you host critical resources such as your web server. If not properly secured, such a client could send a simple DNS update and change the IP associated to your web server’s FQDN – a simple, yet quite effective solution to intercept some information or perform a denial of service attack.

Lastly, keep your ears open about DNS privacy projects. Things are quickly evolving to secure the communication between the DNS client and the DNS resolver, in order to prevent the interception of DNS packets and on-the-fly corruption of the answers on the network (see the example given in our article “Breaking LTE on Layer 2”).

• Episode 1 – Best Practices Overview
• Episode 2 – Maximizing Application Availability & User Experience
• Episode 4 – How DNS Contributes to Global Network Security
• Glossary: DNS over HTTPS