[dnsext] Re: [Technical Errata Reported] RFC6672 (8677)

[Paul Hoffman <[e-mail]>]

This is not actually an erratum (given that it is for "missing text"), it is a plea to start an update to RFC 6672, which already has errata. It should be marked as "hold for update" so that it is remembered when someone updates RFC 6672.

--Paul Hoffman

On 12 Dec 2025, at 7:55, RFC Errata System wrote:

> The following errata report has been submitted for RFC6672,
> "DNAME Redirection in the DNS".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8677
>
> --------------------------------------
> Type: Technical
> Reported by: Petr Špaček <[e-mail]>
>
> Section: 8
>
> Original Text
> -------------
> <missing text>
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6672 (draft-ietf-dnsext-rfc2672bis-dname-26)
> --------------------------------------
> Title               : DNAME Redirection in the DNS
> Publication Date    : June 2012
> Author(s)           : S. Rose, W. Wijngaards
> Category            : PROPOSED STANDARD
> Source              : DNS Extensions
> Stream              : IETF
> Verifying Party     : IESG