Message-ID: <3855054a-08e4-4ec6-9c51-97826003ad10@isc.org>
Date: Mon, 15 Dec 2025 09:30:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Olafur Gudmundsson <ogud@ogud.com>, Paul Hoffman <phoffman@proper.com>
References: <20251212155555.DF41CC000CC9@rfcpa.rfc-editor.org>
 <F2DD3248-E198-4B0E-A75A-84D464A4F45E@proper.com>
 <74055991-5D57-4F3F-BF64-7AD22AC569B4@ogud.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata=
 xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB
 CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N
 nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY
 KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP
 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK
 hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I
 FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH
 V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII
 ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh
 UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE
 jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B
 AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmkt8P0FCQtoiX8ACgkQq9WHzfBlga4m
 OxAAhBZyC7vnxl3kjFPFRT39ocbZy1jJX4fiaJmiIgKma06c9Eled/w2IN9pzRc0+iI6jSQa
 40NfHFV8g2KZfZUNEVE3BOliWdEFi61OcwxB/UeryGDJUFYfK4un7ibYv4Rzvrfpz13aQ0/z
 MVm2HA3OVwkTqnK+dJL//d3AmED66oJKUFXU9tG5kUGNqbVrZNSiegZXC/TloO0+eYYN63Fm
 EHvWE20NcgdciG4y/pdtBXcWSwt21tSeqiZqN5L8LvfAGmJ1gdi6p4eHvPEH1WSOqUEZmy5l
 +5BE6xA2z4bfNpCYSir6GwFTOQwxHeekLKJktgsLjYY8oHbmPjIIdEzkcV8dD8czJEPo0sqe
 VB4qTun8cCE4AkVofpo5MMwni/3DLlm9bgV8tKJ3sAqwo6bEWk8dU9QqlcwiYb5S1KPbWrwO
 89cIJNLIu9rO3nemWFDwNq6mFuNdNWSDciLV434P5xZ0y5Xy09n5dGhCgYZTRv1JTLmXEO+H
 aw6iRgLNZmImYB0VpoPPHBjIavsY211qyLIwDRaUykELhGaBk7P1zKhC91ZD866CbR3x6ptv
 EuFuJ2myZT1dIalWiFf0HaVhrMHm8y8ih1sn9Ezdxnle7Hxyjgp//CtM92GCjU8iuqYQOzNq
 B9LWBU6NTtGx5Tktf2/Vin2ADqiiVN1EDOQd9tvOwU0EX84n/gEQANARNXihDNc1fLNFZK5s
 O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM
 VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr
 gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4
 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ
 yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU
 dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj
 EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9
 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr
 xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP
 wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC
 aS3xCAUJC2iJigAKCRCr1YfN8GWBrgJJD/4oabL/T67M7GNPB1Q+1ghSpi3LJEwDqeaULNZv
 2exo7N59cChW5DXD5e/rkvQM7yOsaKJBwkpjY2+vk4+Tw9iU1iqzS0iavr9A3i9mHJjlp4it
 u6oDBHCGMqBGZHHGP4O9xPuIoW6s50yP31NLbIGP4KGD03S1JtOBrETlTyr6a0mN4HrRnAkz
 nOa2l7npRvgkRpdr/vDmbAkyZYXcUCQSWsOKzRrcCrqRxzF7Ob39Xw+SrPv7hMBShzOVJCj6
 XwOsu+F/hmRK5TML8+yZ+wGbrcTyxJ8qkKtwtDJXPMVY993f1k50/bquRdjX5wHTthvf6o9A
 2cmZtbL0fVm2KEWNV3xDk52cJj7MqBk1M/mj1q8+6UzN9hTxN0N77u1sosgguW/8PWu/v2yy
 kUs2huxaqDkdrPc6kKuKbCGpkT5/89S6gvQSNx5IlVl0uWzJRat1h9HkdkO0CBYRX51Rv33W
 BF4qJ73o2dfrUchs70rher6734c21z8DUhDkvnPGIgLh4tYrYHNcM4akBTUt9k38xMGrj6yo
 kRjP6Pq9jhLwJBxxBRDEXn3vse8uy1s1sp9rhBxSS7bEHfmyz71h6ccALCFBlBzqfMediCAE
 0PEMOPrXM0NU+o25vNC8BuWWpPf+fzvkLf+sEyYcIdwbHZ/V2qv97JvYX0FpMwmeyw4O2g==
In-Reply-To: <74055991-5D57-4F3F-BF64-7AD22AC569B4@ogud.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: T5S72ATQPOD2UYGAFQA4VQKDZ6CCKRDU
CC: RFC Errata System <rfc-editor@rfc-editor.org>,
 Scott Rose <scott.rose@nist.gov>, ek.ietf@gmail.com,
 Eric Vyncke <evyncke@cisco.com>, dnsext@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bdnsext=5D_Re=3A_=5BTechnical_Errata_Reported=5D_RFC6672_=288677?=
	=?utf-8?q?=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsext/SFoSsWojL5ivPsZs-Oix840kmTM>

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 <phoffman@proper.com> 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 <pspacek@isc.org>
>>>
>>> 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 -- dnsext@ietf.org
>> To unsubscribe send an email to dnsext-leave@ietf.org
> 
> _______________________________________________
> dnsext mailing list -- dnsext@ietf.org
> To unsubscribe send an email to dnsext-leave@ietf.org


-- 
Petr Špaček