NSEC Resource Record
With NSEC Resource Records , DNSSEC signed zones are used to concatenate all labels (names) in alphabetical (canonical) order. The type NSEC replaced the almost identical type NXT in 2004.
background
Signing DNS records can be used to verify that these records have not been tampered with and come from the correct authoritative zones. What is not possible is to prove the non-existence of DNS records. If, for example, a client asks for the name test.example.com, an attacker can remove the relevant data from the server's response packet without the client becoming aware of this.
To prevent such denial of service attacks, all the names of a zone are linked in alphabetical order using NSEC records, with the last entry pointing to the first. Example:
name1 NSEC name2 name2 NSEC name5 name5 NSEC name1
Each NSEC record is signed by an RRSIG resource record so that it cannot be falsified. A DNS server provides the associated NSEC entry in its response packets. "Name2 NSEC name5" is also supplied when requesting the non-existent name name3. The client can thus be sure that the name3 actually does not exist and that it was not removed during the transport.
The NSEC record has a second function: It lists all types with the same name (see example).
construction
An NSEC-RR consists of the following fields:
- Label
- Name of the owner of the key
- Type
- NSEC (47)
- Next domain name
- the name following alphabetically
- List of types
example
name2 NSEC ; Typ
name5 ; alphabetischer Nachfolger
NS DS RRSIG NSEC ; Liste der Typen des Labels name2
Security of the procedure
An important disadvantage of this method is that an attacker can step through the NSEC chain and thus determine all entries in a zone. This process is known as zone walking (also DNSSEC walking ). A comparable reading of a complete zone is not possible with conventional DNS and secure zone transfer.
Measures to prevent zone walking were discussed (e.g. RFC 4470 ). The problem was solved by a new resource record NSEC3 , in which the names involved are no longer represented in plain text but as a hash ( RFC 5155 ).