I'm trying to understand how NSEC and NSEC3 records work in DNSSEC. When I query for an non-existent domain with supports NSEC3, I get the following output

$ dig +dnssec NSEC3 gggg.icann.org. | grep -F "NSEC3" | grep -Fv "RRSIG NSEC3"

    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec NSEC3 gggg.icann.org.icann.org.
    ;gggg.icann.org.icann.org.  IN  NSEC3
    l6bdbf682dc45lv4vrfmrfnithopmvm0.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 L6CPA6V9R9563KMQT2NF2NL4BE1DPO3U 
    dggsrhgbge97oj2ltjnpkieb951c9dsq.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 DGP62KNMI7ESBJ8BEKD60CEF9T7EUCO4 A RRSIG
    fke7dkh6es15igh27a4tl1fic0ukppkp.icann.org. 3599 IN NSEC3 1 0 5 9974AA028A677BF0 FKGU9H93DI168B3MQ3VK7VHTPNN67GA0 A RRSIG

My question is, why are there 3 NSEC3 records in the response? In case of NSEC I only get one NSEC record in response.


First, have a look at http://dnsviz.net/d/gggg.icann.org/WVLgMg/dnssec/ it may help to have things displayed graphically and over your mouse on top of the NSEC3 record at bottom to see all details.

NSEC3 is far more complicated than NSEC (and NSEC5 is far more complicated - but not yet deployed anyway - than NSEC3), and the behaviour will not be the same.

Basically you have 3 NSEC3 records because you are seeing here the authentication of the denial of existence of a wildcard record. The gory details are in §5.6 of RFC7129, but you will need to read the previous sections to first learn about the "closest encloser" concept.

In short, the problem is explained by this snippet:

The short answer is that due to the hashing in NSEC3, you lose the
depth of your zone and everything is hashed into a flat plane. To
make up for this loss of information, you need an extra record.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.