Weakness of NSEC in DNSSEC

Some zone administrators might have heard that an obstacle to DNSSEC implementation is that the early design of DNSSEC provided the resource record of NSEC (next secure record) which tells interrogating resolvers that the domain names they are asking do not exist at all. When a zone file is signed, all the original resource records will be arranged in alphabetical order and the NSEC records are properly inserted indicating which domain name to be followed after each other. This is a huge vulnerability giving rise to zone walking and a bad guy can dig out all domain records. The illustrations are below:

[Please click on the link to see the second screen dump]


In the screen dump above, I tried to find the a record of "a.ripe.net" and the query was dnssec-enabled. The remote side just told me that this one did not exist and the next available record which best matches my query is "adder.ripe.net". Please note that I have already installed the the public key of ripe.net so all data returned are tagged with "ad" which means "authenticated data".

Next, I tried to find the a record of "ooo.ripe.net" and the result told me that the next available was "openpgp.ripe.net" as below:

[Please click on the link to see the second screen dump]


By trying different alphabetical combinations, thanks to NSEC, I can find out all domain names in a zone. NSEC is now replaced by NSEC3 for zone signing. It is quite new indeed and Windows 2008 Server R2 and Bind 9.6 or above can support it.

The IETF has recommended that all early implementations of DNSSEC signed zones must be resigned with NSEC3 for security reason.