Cis Bind V100 8 8

CIS 8.8 — Ensure Zones are Signed with NSEC or NSEC3

Profile Applicability

• Authoritative Name Server Level 2

Description

The NSEC records are used to prove that a name does not exist, by providing the name before it, and the name after it. NSEC3 records are similar, while using a hash to link records in order to make zone enumeration much more difficult. Either record type will securely validate a negative answer that a name does not exist.

Rationale

The DNSSEC RRSIG records allows verification of the integrity and authenticity of answers for names which exist. However when the authoritative name server answers that a name does not exist. The nonexistent answer is not signed, and cannot be securely signed. An attacker could take advantage of this by spoofing nonexistent name answers to prevent resolving legitimate names. The NSEC and NSEC3 records provide a means for a DNSSEC validating resolver to verify the authenticity of nonexistent answer.

Impact

Not specified.

Audit Procedure

To audit the authoritative name server, use the delv command on a independent DNSSEC validating resolver to query a nonexistent name of the authoritative name server. The response should be a "negative response, fully validated" similar to the following example.

$  delv @8.8.8.8 nosuch-name.isc.org
;; resolution failed: ncache nxdomain
; negative response, fully validated
; nosuch-name.isc.org. 3200171710 IN  \-ANY   ;-$NXDOMAIN
; isc.org. SOA ns-int.isc.org. hostmaster.isc.org. 2020031004 7200 3600
24796800
. . .

A non-compliant response will not contain the "fully validated" response. For example:

$ delv @8.8.8.8 nosuch-name.example.com
;;    validating example.com/SOA: no valid signature found
;;    validating example.com/NSEC: no valid signature found
;; resolution failed: ncache nxdomain
; negative response, unsigned answer
; nosuch-name.example.com. 3200171710 IN \-ANY ;-$NXDOMAIN
. . .

Remediation

An NSEC record and NSEC signatures are generated automatically by BIND for DNSSEC signed zones. If the audit fails, then verify that the zone has a valid signature and has delegated trust from the parent domain as in the previous recommendations "8.5 Ensure each Zone has a Valid Digital Signature" and "8.6 Ensure Full Digital Chain of Trust can be Validated" The signed zone file, or a zone transfer can also be checked for NSEC signatures. With a command such as:

$ dig @127.0.0.1 example.org AXFR | grep -w 'NSEC'
example.org.   86400   IN      NSEC    www.example.org. A NS SOA RRSIG NSEC DNSKEY TYPE65534
example.org.   86400   IN      RRSIG   NSEC 8 2 86400 20200325222408 20200224212408 4236
. . .

Converting NSEC signing to NSEC3 signing is helpful to prevent zone walking of the linked NSEC records which easily reveal all of the names in a zone. The NSEC3 algorithm creates a linked list of signed hash values, instead of names to prevent the simple disclosure of all names. The rndc signing command can be used to convert NSEC signing to NSEC3 signing. For example:

#  rndc signing -nsec3param 1 0 10  auto example.org
nsec3param request queued
<wait, check the named logs to ensure the zone has been re-signed>
. . .
zone example.org/IN (signed): sending notifies (serial 2020031005)
. . .

# dig @127.0.0.1 example.org AXFR +onesoa | grep NSEC
example.org.    0       IN      RRSIG   NSEC3PARAM 8 2 0 20200422125535
20200323125407 42363 example.org. CCHlbQud0W2XrNlmYHO. . . Kg7ltg==
example.org.    0       IN      NSEC3PARAM 1 0 10 74139101AD2E623E
. . .

Default Value

For signed domains the NSEC records and signatures are generated by default.

References

1. https://www.dnsinstitute.com/documentation/dnssec-guide/ch07s03.html#recipes-nsec-to-nsec3
2. https://weberblog.net/how-to-walk-dnssec-zones-dnsrecon/
3. https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2#securing-the-dnssec-setup-from-zone-walking

CIS Controls

MITRE ATT&CK Mappings

Profile

• Level 2 - Authoritative Name Server