This is what you should know about DNSSEC

If the modern internet has a critical infrastructure, this is definitely the Domain Name System (DNS). This system was developed at a time where cybersecurity was not a real thing. While the internet was growing, involving ever more activities and data, the importance of a secure DNS became clear. To ensure safe communication, technical engineers developed the Domain Name System Security Extensions (DNSSEC): a system that protects the DNS cache, thus making the internet a safer space. We invite you to continue this reading to learn more about DNSSEC and its essential role in protecting the DNS.

DNS was not created with security in mind

In 1983, internet pioneer Paul Mockapetris invented the Domain Name System (DNS) to make the newly born internet network more accessible to humans. Thanks to his invention, we can now surf using easy-to-remember URLs instead of long numeric IP addresses.

This is what the DNS does: when you enter the URL in the internet browser, it enquires a DNS server whose task is to redirect the query to the IP address that corresponds to the domain name entered. This process at the base of the DNS is called domain name resolution.

Unfortunately, during the communication, serious security risks hide. The DNS was created within an academic setting at a small scale; therefore, it did not envision the necessity to avoid cybersecurity-related problems. With time, it was discovered that hackers could easily infiltrate the name server and the DNS client and, for example, poison the server cache. One of the main problems has been that DNS was not developed to verify the sender’s identity, so the recipient cannot determine if the received DNS response comes from the server being queried. To counter this issue, DNSSEC is seen as a valuable solution to stop attacks and certify that the domain name is exactly what it claims to be.

What is DNSSEC?

The DNSSEC (Domain Name System Security Extensions) is a set of various network standards approved by the IETF (Internet Engineering Task Force). It adds source authentication to the DNS, thus guaranteeing the authenticity and integrity of the data. Furthermore, it ensures the security and reliability of the information provided by the DNS.

This set of extensions allow DNS resolvers to authenticate in particular:

• The actual origin of the DNS data.
• The integrity of data received (but not confidentiality or availability).
• The assertions of non-existence.

Without DNSSEC, it is impossible to determine if the DNS responses are correct or falsified, but especially if the connection has been established with the desired partner. The verifiable “correctness” offered by DNSSEC has allowed DNS to become a reliable source of information.

How did we get there?

Research into securing the DNS began in 1990 when Steve Bellovin discovered the first critical flaw. Since then, the IETF has been working on the development of DNSSEC. This protocol was first outlined in 1997 in RFC 2065, with an improved specification published in 1999 as RFC 2535. This version, believed to be fully workable, was proved to be unsuitable for large networks. In 2005 three RFCs (RFC 4033, RFC 4034, and RFC 4035) defined a new DNSSEC version able to scale up the modern internet. This trilogy had a side effect on the zone contents creating issues against data privacy obligations. In 2008, RFC 5155 introduced an alternative resource record, NSEC3, to protect zone enumeration and expand delegation-centric zones.

The adoption of the DNSSEC has helped to create a safer space, but there are still several technical issues on different matters, including:

• A protocol scalable to the size of the growing internet network without breaking backward compatibility.
• Prevention of invalid DNS zone enumerations.
• Development of the DNSSEC on a variety of different DNS servers and clients.
• An increased awareness about DNSSEC and dispelling the myth of its complexity.
• Finding an agreement about who should control the TLDs keys.

While implementation procedures have been taking place, these are the aspects that DNS experts are trying to address and solve.

DNSSEC was created to avoid DNS cache poisoning

DNSSEC was created primarily to avoid the so-called DNS cache poisoning attacks. The critical and fragile situation of the DNS became evident once the internet started to grow. The first flaws were discovered in 1990 by Steve Bellovin and published in 1995 in the paper “Using the Domain Name System for System Break-Ins“. The internet community was shocked when, in 2008, Daniel Kaminsky discovered a critical flaw that affected almost every DNS server on the planet. A joint task force fixed this vulnerability before disclosing it to the public.

How does DNSSEC work?

DNSSEC protects your domains, but how? Put simply, it blocks unauthenticated communication. Suppose a hacker attempts to change the IP address of a domain name in a DNSSEC-protected DNS server during the domain name resolution. In that case, the server will reject the unauthenticated request and the communication will stop.

DNSSEC is based on asymmetric cryptography and, consequently, uses a public-key system. Private keys digitally sign all DNS information called Resource Records. While the clients use the public key to verify the signature and thus confirm the authenticity of the data source. DNSSEC can specifically protect critical DNS data such as text record (TXT) and record mail exchange (MX).

If DNSSEC is deployed, the keys allow the server to verify that the information received is identical to the record on the authoritative server for the designated domain name. If the recursive server determines that the address record from the authoritative server has not been changed during the communication, the domain name is resolved, and the user can access the site.

In the case of a modified record or if the record did not come from the indicated source, the recursive server wouldn’t allow the browser to reach what is considered a fraudulent address.

What DNSSEC cannot do

DNSSEC is an excellent means to secure data exchange in the DNS in IP networks. We can say DNSSEC is safe, and it should be included in internet safety best practices. At the same time, it is essential to understand it clearly to avoid wrong expectations, since DNSSEC is not a solution for all DNS-related vulnerabilities:

• It cannot guarantee the confidentiality of data since it is not encrypted. DNS responses are only authenticated DNS.
• It cannot protect directly against DDoS, phishing, or spoofing attacks.

Are there any reasons why you shouldn’t use DNSSEC?

There is no specific reason why you should not consider deploying DNSSEC for your domain. If you value data protection, DNSSEC is a wise choice. Nonetheless, there are few arguments we could raise that might make this technology unattractive. First of all, the DNSSEC protocol requires extensive processing capabilities, which can reduce website performance. Secondly, although DNSSEC adds a protection layer to DNS, the creation of further processes in the communication chain create new possible vulnerabilities and raise the chances of communication failures.

Organizations are often the target of malicious or fraudulent activity, and they collect sensitive data and need to rely on safety measures. Potential risks connected to DNSSEC are minimal, so all in all, there is not a critical reason why you shouldn’t deploy for your domains.

Can all TLDs be protected with DNSSEC?

As of today, not all TLDs support DNSSEC, and registries are legitimized to do so. The DNSSEC is still a draft and not a recognized single-standard model TLDs are required strictly to adopt. DNSSEC is currently enabled for more than 90% of the TLDs in the DNS, with .se, the Swedish ccTLD, being the first TLD globally to do so in September 2005.

Two parties must enable DNSSEC: on one side, the registrars responsible for publishing DNS information must ensure that DNSSEC signs their DNS data. On the other side, network operators must enable DNSSEC validation on their resolvers that handle DNS lookups for users.

Unfortunately, it is still not widely deployed or used today, and when deployed, it is not done in the right way. The rate of DNSSEC validation in June 2021 is estimated at 26,53% worldwide.

Since DNSSEC makes the internet a safer place, why isn’t it so extensively used? The reason is that implementing it on a global scale is a huge undertaking. It requires commitment, consensus, and significant spending. There are new protocols nowadays that rely on DNSSEC, such as DNS-based Authentication of Named Entities (DANE) that allows the publication of Transport Layer Security (TLS) keys in zones for applications such as email transport. During the process, the internet community is learning and many resolver operators are becoming more aware of DNSSEC. The more it will be used, the more we will be sure this protocol will become a real standard to get authentic DNS answers to queries.

What happens to my domain name without DNSSEC?

When a domain name does not have DNSSEC active, the hacker can find a leak in a DNS server and change the communication between the domain name and the IP address. If such a scenario occurs, the user will be redirected to another website with different content. We recommend activating DNSSEC to protect the authenticity of the response provided by the DNS server and thus ensure the users land on the actual website they want to see.

Activate DNSSEC in AutoDNS

Snapshot

@Newsletter

No spam.
Just quality content.

Subscribe ->