RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 6672, "DNAME Redirection in the DNS", June 2012

Source of RFC: dnsext (int)

Errata ID: 5297
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pieter Lexis
Date Reported: 2018-03-23
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2018-03-26

Section 5.3.4.1 says: 

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME 
   bar.example.com. RRSIG NSEC [valid signature]

It should say:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

Notes:

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap.

Edit: Thread: https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html

Errata ID: 5298
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pieter Lexis
Date Reported: 2018-03-02
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 5.3.4.2 says: 

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME
   bar.example.com. RRSIG NSEC [valid signature]

It should say:

   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

Notes:

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap

Edit: Thread - https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html

Status: Reported (1)

RFC 6672, "DNAME Redirection in the DNS", June 2012

Source of RFC: dnsext (int)

Errata ID: 8677
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2025-12-12

Section 8 says: 

<missing text>

It should say:

DNAME redirects can be used to amplify the impact of successfully spoofing a
single DNS response. An attacker can generate an arbitrary query name in the
form of "$random.example." and simultaneously try to spoof a response. The
"$random" label provides the attacker with an unlimited number of spoof
attempts. A successful spoofing can include a DNAME RR with a QNAME's parent
name. Such a spoofed RR can redirect the whole parent zone to a malicious
target, or create a resolution loop.

Consumers of DNS responses might consider the trustworthiness of DNAME RRs: Are
they DNSSEC-secure? Were they received via a non-spoofable transport (TCP, TLS,
UDP with DNS cookies, etc.)? Depending on security posture, consumers might
choose to not use untrustworthy DNAME RRs, or choose to re-query using a secure
transport like TCP.

Notes:

I believe Security Considerations should mention higher risk associated with DNAME spoofing. Hardening described in the proposed text was deployed as (part of) fix for CVE-2025-40778 in BIND 9.

Report New Errata



Advanced Search