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

[Olafur Gudmundsson <[e-mail]>]

I agree with Paul this is not an error but a warning about abuse, we can not update RFC every time someone thinks of a possible “misuse” 
Olafur


> On Dec 12, 2025, at 13:03, Paul Hoffman <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> dnsext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]