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

[Petr Špaček <[e-mail]>]

Of course I'm fine with "hold for update".

If there was a bug tracker for RFCs I would use that, but to the best of 
my knowledge errata process is closest we have, so here we go.

IMHO better than relying on the 'tribal knowledge' as Warren puts it.

Petr Špaček
Internet Systems Consortium

On 13. 12. 25 5:02, Olafur Gudmundsson wrote:
> 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]
> 
> _______________________________________________
> dnsext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


-- 
Petr Špaček