NSEC enumerates your zone

DNSSEC has to be able to prove a name does not exist, and it has to do so with a signature prepared in advance. The first solution to that problem hands out the contents of the zone.

Why denial is hard

A signed positive answer is easy: sign the RRset once, serve it to everyone. A negative answer is different — there are infinitely many names that do not exist, and you cannot pre-sign a response for each. RFC 4034 solves it by signing the gaps instead.

How NSEC works

Zone contains:  api, mail, vpn, www

NSEC records:
  api.example.com.   NSEC  mail.example.com.   A RRSIG NSEC
  mail.example.com.  NSEC  vpn.example.com.    A MX RRSIG NSEC
  vpn.example.com.   NSEC  www.example.com.    A RRSIG NSEC
  www.example.com.   NSEC  api.example.com.    A RRSIG NSEC

Query for "beta.example.com"?
  -> return the api->mail NSEC. It proves nothing exists
     between them, and "beta" falls in that gap.

The proof is sound and signed once. It also states, as a matter of public record, that mail is the next name after api.

Walking the zone

Each NSEC names its successor, so the records form a ring. Ask for any name that does not exist, read the successor from the NSEC you get back, ask for a name just after it, and repeat until you return to where you started.

for each answer:
   read the "next name" field
   query for <next name> + a character that sorts after it
   until you loop back to the first name

You now have every name in the zone, and the record
types at each one — because NSEC lists those too.

• It is not an attack. Nothing is broken, no control is bypassed, and the server is answering correctly. The information is simply a consequence of the design.
• The type bitmap is the interesting part. It tells you which names have MX, TXT or SRV without querying for them.
• It is fast. A zone of a few thousand names walks in seconds.