Search Here



DNS Protection

Why is DNS security important?
Standard DNS queries, which are required for almost all web traffic, create opportunities for DNS exploits such as DNS hijacking and man-in-the-middle attacks. These attacks can redirect a website’s inbound traffic to a fake copy of the site, collecting sensitive user information and exposing businesses to major liability. One of the best known ways to protect against DNS threats is to adopt the DNSSEC protocol.

Like many internet protocols, the DNS system was not designed with security in mind and contains several design limitations. These limitations, combined with advances in technology, have made it easy for attackers to hijack a DNS lookup for malicious purposes, such as sending a user to a fraudulent website that can distribute malware or collect personal information. The DNS Security Extensions (DNSSEC) is a security protocol created to mitigate this problem. DNSSEC protects against attacks by digitally signing data to help ensure its validity. In order to ensure a secure lookup, the signing must happen at every level in the DNS lookup process.

This signing process is similar to someone signing a legal document with a pen; that person signs with a unique signature that no one else can create, and a court expert can look at that signature and verify that the document was signed by that person. These digital signatures ensure that data has not been tampered with.
DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in the case of a ‘’ lookup, a root DNS server would sign a key for the .COM nameserver, and the .COM nameserver would then sign a key for’s authoritative nameserver.

While improved security is always preferred, DNSSEC is designed to be backwards-compatible to ensure that traditional DNS lookups still resolve correctly, albeit without the added security. DNSSEC is meant to work with other security measures like SSL/TLS as part of a holistic Internet security strategy.

DNSSEC creates a parent-child train of trust that travels all the way up to the root zone. This chain of trust cannot be compromised at any layer of DNS, otherwise the request will become open to a man-in-the-middle attack.

To close the chain of trust, the root zone itself needs to be validated (proven to be free of tampering or fraud), and this is actually done using human intervention. Interestingly, in what’s called a Root Zone Signing Ceremony, selected individuals from around the world meet to sign the root DNSKEY RRset in a public and audited way.

Here is a more detailed explanation of how DNSSEC works >>>

What are some common attacks involving DNS?

DNSSEC is a powerful security protocol, but unfortunately it is not currently universally adopted. This lack of adoption coupled with other potential vulnerabilities, on top of the fact that DNS is an integral part of most internet requests, makes the DNS a prime target for malicious attacks. Attackers have found a number of ways to target and exploit DNS servers, here’s some of the most common:

DNS spoofing/cache poisoning: This is an attack where forged DNS data is introduced into a DNS resolver’s cache, resulting in the resolver returning an incorrect IP address for a domain. Instead of going to the correct website, traffic can be diverted to a malicious machine or anywhere else the attacker desires; often this will be a replica of the original site used for malicious purposes such as distributing malware or collecting login information.

DNS tunnelling: This attack uses other protocols to tunnel through DNS queries and responses. Attackers can use SSH, TCP, or HTTP to pass malware or stolen information into DNS queries, undetected by most firewalls.

DNS hijacking: In DNS hijacking the attacker redirects queries to a different domain name server. This can be done either with malware or with the unauthorized modification of a DNS server. Although the result is similar to that of DNS spoofing, this is a fundamentally different attack because it targets the DNS record of the website on the nameserver, rather than a resolver’s cache.