DNSSEC is a security protocol that adds public key cryptographic signatures to DNS records so that they can be transmitted more securely over the internet.

Similar to HTTPS that encrypts web traffic so that malicious actors don’t have access to sensitive data, DNSSEC, or Domain Name System Security Extensions, authenticates responses from DNS servers with digital signatures to defend against data being transferred by malicious actors. It is a useful protection against several different types of DNS attacks, such as man-in-the-middle, cache poisoning and DNS replay attacks.

What is a DNS (Domain Name Server)?

A DNS or Domain Name System is the system that translates between human-readable domain names (e.g., www.amazon.com) to IP addresses (e.g,, since computers understand numerical addresses. When you type a URL into your browser, it makes a DNS query to map the unique domain name to the IP address. It first attempts to look up the IP address in the cache of the local browser or operating system, but if it fails to locate it, it moves the request to the DNS recursive resolver server.

This is a component of the DNS architecture that receives DNS requests from client devices (such as your computer) and “resolves” them by making requests to other servers.

Designed in the 80s, DNS protocol was flawed as it was not built with the idea of security in mind. Recursive revolvers send requests to name servers, they have no way of authenticating the response, which can be easily spoofed or forged. This redirects users to malicious servers and websites where they can easily steal sensitive information and launch malware and other types of attacks.

How a DNS Works

DNS has a complex hierarchy that includes many different servers, which is intended to both protect it against malicious actors and also makes it easier to scale DNS requests.

Here’s a high-level summary of the DNS architecture:

  • Root Zones. DNS root zones exist which are databases containing records which link domain names to IP addresses.The root zones are all over the world, managed by the Internet Assigned Numbers Authority (IANA). 
  • Root Servers. There are 13 root servers that  host the root zone all over the world. These root servers are managed by various organizations such as the Internet Corporation for Assigned Names and Numbers (ICANN), NASA and the University of Maryland. Each of these root servers has their own IP address. 
  • Top-Level Domain (TLD) Server. The root zones point at TLDs. There are two basic types of TLDs, (e.g, .com, .org, .net) and geographic (.au, .uk, .us., etc). They are managed by various registries. 
  • Name Servers. These TLDs point at name servers (e.g., www.amazon.com). They are the final authority on everything that has to do with the domain, including the IP address. 
  • Domain. The name servers host the zone for given domains.

A DNS is split into zones containing different types of resource records (e.g., AAA, MX, Cname, etc), each with its own functionality. For example, A records or address records map a hostname to a 32-bit IPv4 address, while CNAMES or canonical name records point multiple domain records to the same IP address. Groups of resource records with the same name and type are referred to as resource sets, or RRsets.

Examples of DNSSEC Record Types

The cryptographic signatures are stored next to the DNS records, waiting for verification to ensure that a malicious actor isn’t trying to point at a malicious domain.

These are the different types of DNS record types used to authenticate signatures:

  • Resource record signature (RRSIG): Contains a cryptographic signature
  • DNSKEY: Stores a public signing key, used to verify RRSIGs in the zone, such as the ZSK. 
  • DS: Contains the hash of a DNSKEY record
  • NSEC and NSEC3: For explicit denial-of-existence of a DNS record
  • CDNSKEY and CDS: For a child zone (e.g.,sub.domain.com) requesting updates to DS record(s) in the parent zone (e.g., domain.com).

How DNSSEC Signatures Work

DNSSEC ensures that these sets of records, or RRSETs, are from an authoritative source through cryptographic signatures. This signature is known as resource record signatures, or RRSIGs. Each RRSIG stores a digital signature of an RRSET.

The basic steps of verification include:

Step 1) Zone-signing keys (ZSK)

Each zone in the DNSSEC has a zone-signing key pair (ZSK), made up of a public and private key. Zone operators use private ZSKs to create digital signatures, storing them as RRSIG records. Basically, the ZSK is a method the DNS uses to say “Yes, these are my records from this DNS server, and this is what they look like!”

The Zone-Signing Key
The Zone-Signing Key

We can’t trust the DNS that the ZSK RRSIG records are authoritative, however. They may have been compromised. The resolver has to verify the records.

When a specific record is requested, the name resolver responds with the corresponding RRSIG, while the resolver responds with the DNSKey and public ZSK to validate the response.

There’s a small caveat here, however. What if the DNSKey, or the public ZSK in particular, was compromised? We need a way to validate the public ZSK.

Step 2) Key-signing keys (KSK)

DNSSEC name servers have both a ZSK and a KSK, or key-signing key. The KSK works the same way that the ZSK does to validate RRSETS.

The Key-Signing Key
The Key-Signing Key

The KSK has a private and public key, just like the ZSK.

The private KSK signs DNSKey record sets by signing the public ZSK (stored in the DNSKey record), creating an RRSIG for the DNSKey.

The private KSK signs both the public KSK and the public ZSK. Resolvers can validate the public ZSK with the public KSK.

How to Verify a Zone-Signing Key
How to Verify a Zone-Signing Key

KSKs are signed by themselves, however, so they don’t offer another layer of verification. In addition, old and compromised KSKs are difficult to replace, however, which is why it’s easier to replace the ZSK instead.

KSK verification is only sufficient for security and authorization within the zone. We need another step to connect this zone (child zone) with the parent zone.

Step 3) Delegation Signer (DS) record

Delegation Signer, or DS records enable the transfer of trust from child to parent zones. A parent zone is the authoritative server for the domain that contains all of the data for a particular zone (e.g. domain.com) while a child zone is the sub domain of that zone (e.g, blog.domain.com).

Whenever a DNSKEY record with the public KSK needs to be verified from a child zone, the server resolver hashes it (e.g. maps data to fixed value) and compares its DS record to that of its parent zone by verifying the child zone’s public KSK. If they match, it means that all of the records in the chain can be verified and trusted (i.e. the chain of trust).

Transferring Trust from a Parent to Child Zone
Transferring Trust from a Parent to Child Zone

The Types of Attacks DNSSEC Defends Against

DNSSEC, or Domain Name System Security Extensions, helps to protect your website and prevent attacks before users even interact with your site.

  • Spoofing (Cache poisoning). A legitimate answer to a DNS query is replaced by a forged one. DNSSEC defends against this with cryptographic signatures. 
  • Man-in-the-middle attacks. Malicious actors can intercept the DNS queries and point users to malicious sites, making it seem as though the address is that of an authoritative DNS server.  The complex DNSSEC architecture has multiple methods of verifying DNS servers and data are authoritative. 
  • DNS replay attacks. These attacks retransmit authorized data in a fraudulent way. DNSSEC defends against this type of attack by using timestamps in its signatures.

The Limitations of DNSSEC

While the signatures help to verify the authenticity of the records, they do not defend against certain types of security flaws.

These include:

  • Protection against the last mile. The integrity of responses from the point of the resolver to the user remain unverified. This means that home routers can be compromised by different exploit kits, such as Novidade.  
  • Confidentiality and privacy. DNSSEC is not encrypted, and the records are available by examining DNS queries.

How Panorays Helps You Manage Third-Party Risk

While DNSSEC helps protect you against third-party risks in your DNS server, it’s only one of many types of methods malicious actors have for infiltrating your network and server. Panorays delivers comprehensive and contextualized third-party cyber risk management to pinpoint early threat indications within the unique business context of every relationship, enabling companies to adapt their defenses, minimize risk and proactively prevent the next breach from affecting their business.

Its platform modules include:

  • Supply chain mapping. Discover third parties in your IT environment and map the business relationship of each supplier to your organization. 
  • Risk DNA Assessment. Combine internal and external assessments along with your unique risk appetite, business priorities, and compliance and regulation to get the most accurate cyber rating of your suppliers that exists in the industry today. 
  • Continuous threat detection. Get third-party threat intelligence and receive exclusive critical findings of breaches or other security incidents and prevent them from escalating with a contextualized view of your supply chain. 
  • Remediation and collaboration. Receive an aggregated remediation plan to close security gaps with each vendor that minimizes dependence on third-party vendors.

Want to learn more about how Panorays can help your organization manage third-party risks? Get a demo today.