Leaking data from DNSSEC


Published by Security Testing and Assurance on 3 February 2023

This blog post discusses how the NSEC and NSEC3 DNSSEC records can be abused by attackers to identify valid DNS entries. We introduce a toolΒ to allow penetration testers to carry out these attacks. We also present aΒ whitepaperΒ that examines attacks against NSEC3 in detail and demonstrates these attacks against top-trafficked Internet domains.

Attacking DNS

The Domain Name System (DNS) is the method by which domain names are resolved to IP addresses and other resources. Public (Internet-facing) DNS entries were never intended to be confidential, however entries that may be useful to attackers are routinely found in DNS records. If an attacker knows that a domain like πšπšŽπš–πš™-πšŒπš˜πš™πš’-𝚘𝚏-πš™πš›πš˜πš-πšπšŠπšπšŠπš‹πšŠπšœπšŽπŸΉπŸΎπŸΊπŸΏπŸΈπŸΊπŸΎπŸΉπŸΏπŸΈπŸΊπŸΈπŸΉ.πšŽπš‘πšŠπš–πš™πš•πšŽ.πšŒπš˜πš–Β exists, this is invaluable for them to target their attacks.

In the earlier days of the Internet, it was common to be able to get a list of all valid domains in a zone using a DNS query known as a Zone Transfer. To prevent leaking information about valid domains to attackers, it now commonplace for DNS servers to prevent zone transfers from unauthorised sources.

Even without the ability to perform zone transfers, attackers have several mechanisms available to identify valid DNS records, such as:

    • Brute-forcing DNS queries (using wordlists of likely domains to assist)
    • Certificate transparency logs
    • Domains embedded in code, leaked from APIs etc.

While these mechanisms may recover many records:

    1. They can be very noisy (brute-forcing / wordlists)
    2. There is no guarantee the results are complete
    3. It is difficult to find complex records e.g 𝚒𝚘𝚞-πš πš’πš•πš•.πš—πšŽπšŸπšŽπš›.πšπš’πš—πš-πš–πšŽ-𝟹𝟾𝟺𝟿𝟸𝟺𝟾𝟹𝟿𝟸𝟺𝟸𝟹.πšŽπš‘πšŠπš–πš™πš•πšŽ.πšŒπš˜πš–Β if there is no associated PKI TLS certificate that will identify the domain in certificate transparency logs.

If DNS servers make use of DNSSEC, this adds an additional mechanism that attackers can use to retrieve DNS records – in some cases entire zones.

DNSSEC Background

DNSSEC is a suite of extension specifications to DNS that provides authentication and data integrity to the DNS protocol (but importantly, does not provide availability or confidentiality protections). DNSSEC does this byΒ signing DNSΒ records in a way that is verifiable through a chain of trust. One issue the implementors of DNSSEC grappled with is how do you a sign the response to a query for a record that doesn’t exist?

In traditional DNS without DNSSEC, if you were to lookup aΒ non-existentΒ record, you’d get a DNSΒ NXDOMAINΒ (non-existent domain) error:

$ πšπš’πš πšŠΒ πš—πš˜πš—-πšŽπš‘πš’πšœπšπšŽπš—πš.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
𝚜𝚝𝚊𝚝𝚞𝚜: π™½πš‡π™³π™Ύπ™Όπ™°π™Έπ™½

With a DNSSEC-aware resolver, if you were to lookup anΒ existingΒ record you will get the answer, and theΒ RRSIGΒ (record set signature) to authenticate the answer and make sure it wasn’t tampered with:

$ πšπš’πš 𝚊 𝚠𝚠𝚠.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒΒ @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
𝙲𝙽𝙰𝙼𝙴 𝚠𝚠𝚠.πšπš•πš‹.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–.
πšπšπš‚π™Έπ™Ά 𝙲𝙽𝙰𝙼𝙴 π™Άπš…πš‚π™Έπ™Άπ™½π™°πšƒπš„πšπ™΄…𝟹𝚈=

Combining the two, what happens if you look up a non-existent record with a DNSSEC-aware resolver?

$ πšπš’πšΒ πš—πš˜πš—-πšŽπš‘πš’πšœπšπšŽπš—πš.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒΒ @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
πš—πšπš–-πšœπšœπš™.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. π™½πš‚π™΄π™² πš—πš˜πšπš’πšπš’πšŒπšŠπšπš’πš˜πš—πšœ.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. 𝙲𝙽𝙰𝙼𝙴 πšπšπš‚π™Έπ™Ά π™½πš‚π™΄π™²

NSEC (Next Secure) Records

What happened in the response above? The server can’t sign an empty record, but it also can’tΒ notΒ authenticate the empty response, because while a Person-in-the-Middle might not be able to tamper with DNS responses, they could respond withΒ NXDOMAINΒ to all requests in a “denial of existence” attack.

DNSSEC’s first solution to authenticate non-existent records, known as NSEC (Next Secure), is to return a range for which there are no records. In the example above, we looked up non-existent and the Paypal DNS resolver responded with “𝙸 πšπš˜πš—’𝚝 πš‘πšŠπšŸπšŽ πšŠπš—πš’ πš›πšŽπšŒπš˜πš›πšπšœ πš‹πšŽπšπš πšŽπšŽπš— πš—πšπš–-πšœπšœπš™ πšŠπš—πš πš—πš˜πšπš’πšπš’πšŒπšŠπšπš’πš˜πš—πšœ”. The RFC requires these ranges are returned in alphabetical order, and that they wrap. As a bonus, it also gives all the record types for the start of the range, now we πš”πš—πš˜πš  πšπš‘πšŠπš πš—πšπš–-πšœπšœπš™ πš˜πš—πš•πš’ has a CNAME record (ignoring the RRSIG and NSEC records).

The fact that looking up aΒ non-existentΒ domain revealsΒ existentΒ domains in the response is extremely useful to an attacker trying to identify valid domains. In fact, it is possible to iteratively look up non-existent domains, collect the ranges, then look up the records to retrieve every record for a domain:

$ πšπš’πš 𝚊 𝟢.πšπšŽπšŸπš‹πš•πš˜πš.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
πšπšŽπšŸπš‹πš•πš˜πš.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. π™½πš‚π™΄π™² πšπšŽπšŸπšŽπš•πš˜πš™πšŽπš›.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. 𝙰 πšπšπš‚π™Έπ™Ά π™½πš‚π™΄π™²
$ πšπš’πš 𝚊 𝟢.πšπšŽπšŸπšŽπš•πš˜πš™πšŽπš›.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
πšπšŽπšŸπšŽπš•πš˜πš™πšŽπš›.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. π™½πš‚π™΄π™² πšπš’πšœπš™πšžπšπšŽπšœ.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. 𝙲𝙽𝙰𝙼𝙴 πšπšπš‚π™Έπ™Ά π™½πš‚π™΄π™²
$ πšπš’πš 𝚊 𝟢.πšπš’πšœπš™πšžπšπšŽπšœ.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @πš—πšœπŸ·.πš™πŸ»πŸ½.πšπš’πš—πšŽπšŒπš.πš—πšŽπš.
πšπš’πšœπš™πšžπšπšŽπšœ.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. π™½πš‚π™΄π™² πšπš•.πš™πšŠπš’πš™πšŠπš•.πšŒπš˜πš–. 𝙲𝙽𝙰𝙼𝙴 πšπšπš‚π™Έπ™Ά π™½πš‚π™΄π™²


To address these obvious shortcomings with NSEC, DNSSEC offers an alternative mechanism known as NSEC3. NSEC3Β attempts to prevent the leaking of valid records by hashing returned ranges. Importantly, the ranges still correspond to valid domain records.

$ πšπš’πš πšŠΒ πš—πš˜πš—-πšŽπš‘πš’πšœπšπšŽπš—πš.πšπš’πšœπšŒπš˜πšŸπšŽπš›.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @𝚊𝟹-𝟼𝟺.πšŠπš”πšŠπš–.πš—πšŽπš.
πŸ½πššπš–πšŽπšŠπššπš˜πš–… π™½πš‚π™΄π™²πŸΉ πŸ½πšƒπŸ½πŸΌπŸΉπšπšƒπ™·… 𝙲𝙽𝙰𝙼𝙴 πšπšπš‚π™Έπ™Ά

Attacking NSEC3

Because results are hashed, it is no longer possible for an attacker to simply enumerate valid domains. However, the hashesΒ are still hashes of valid domains. The hashing algorithm, salt, iterations, and plaintext are all known, so it is possible for an attacker to hash candidates locally. Recovering valid domains becomes a two-step process:

  1. The attacker can enumerate all range hashes by iteratively generating hashes locally. Once a hash is generated that falls within a range that is yet to be observed in a response, that request is sent to the nameserver to get new hashed ranges. This process is repeated until all hashed ranges have been retrieved.
  2. The retrieved hashes can be cracked offline

An example showing the retrieval of multiple hashed ranges is shown below:

$ πšπš’πš 𝚊 𝟢𝟢𝟢𝟢.πšπš’πšœπšŒπš˜πšŸπšŽπš›.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @𝚊𝟹-𝟼𝟺.πšŠπš”πšŠπš–.πš—πšŽπš.
πšœπš‹πŸΆπŸ·πŸ·πŸΎπšπšœ… π™½πš‚π™΄π™²πŸΉ πš‚π™±π™±π™»πšƒπ™°πŸ½πŸΆ… 𝙲𝙽𝙰𝙼𝙴
$ πšπš’πš 𝚊 𝟻𝟺𝟹𝟷.πšπš’πšœπšŒπš˜πšŸπšŽπš›.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @𝚊𝟹-𝟼𝟺.πšŠπš”πšŠπš–.πš—πšŽπš.
πš‹πš‘πŸΎπš™πŸ·πš™πŸΈπš‹… π™½πš‚π™΄π™²πŸΉ π™±π™Έπ™½π™Ίπ™°πŸ½π™Άπ™Ύ… 𝙲𝙽𝙰𝙼𝙴

$ πšπš’πš 𝚊 𝚏𝚍𝟾𝚎.πšπš’πšœπšŒπš˜πšŸπšŽπš›.πšŒπš˜πš– +πšπš—πšœπšœπšŽπšŒ @𝚊𝟹-𝟼𝟺.πšŠπš”πšŠπš–.πš—πšŽπš.
πšžπŸΉπšŠπš‹πŸΈπšŒπšπšž… π™½πš‚π™΄π™²πŸΉ πš„πŸΊπ™Όπš…πŸΆπŸΏπš€πŸΈ… 𝙰 π™Όπš‡ πšƒπš‡πšƒ

There are a few items to note about attacking NSEC3:

  1. Hashes are salted with a salt and the domain, so rainbow tables are of no use
  2. NSEC3 uses the SHA-1 hashing algorithm, so cracking is fast compared with more modern cryptographic hashing algorithms
  3. It is possible to estimate the number of valid records in a DNS zone from the hash range returned in NSEC3 responses. For example, if a returned hash range covers 5% of the possible hashes, it can be deduced that there will be roughly 20 records in the domain. The more hash ranges that are observed, the greater the certainty of this calculation.

Tooling to attack NSEC3

To allow security testers to more easily validate issues with NSEC and NSEC3 configuration, we are releasing a tool to automate these attacks –Β “NSEC(3) Walker πŸšΆβ€β™‚οΈ. It has 3 modes (theΒ READMEΒ has far more detail):

  1. NSEC walking + dumping
  2. NSEC3 walking
  3. NSEC3 post-crack dumping


In the associated WhitepaperΒ Taking the DNS for a Walk; NSEC3 Prevalence and Recoverability, we also take a deeper dive into the theory behind attacking NSEC3 and demonstrate practical use of these methods against real-world targets. It demonstrates a GPU-based attack on NSEC3 that recovered 44% of names for the internet’s top 20,000 NSEC3-protected DNS zones, partially invalidating NSEC3’s privacy and security goals.



This blog post, associated whitepaper, and tool are the work of Harrison Mitchell of CyberCX. The research builds on previous attacks against DNSSEC. For a full list of references, please see the associatedΒ Whitepaper.

Ready to get started?

Find out how CyberCX can help your organization manage risk, respond to incidents and build cyber resilience.