Return-Path: X-Original-To: dnsop@mail2.ietf.org Delivered-To: dnsop@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B2A8727F213B for ; Tue, 13 May 2025 05:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=mails.tsinghua.edu.cn Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKH-oQ5FUKPY for ; Tue, 13 May 2025 05:58:59 -0700 (PDT) Received: from azure-sdnproxy.icoremail.net (azure-sdnproxy.icoremail.net [52.229.168.213]) by mail2.ietf.org (Postfix) with ESMTP id A27AF27F2134 for ; Tue, 13 May 2025 05:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mails.tsinghua.edu.cn; s=dkim; h=Received:From:Message-Id: Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To: References; bh=5jRkrh0v8Ww+uWTuzc5HPI7/KrtksZFmWDznIU45Ga0=; b=Q 1OqLOsJcAfhs5csJkOUKMjshwiTaiaT6Gr83XtzwmrId45RFo99/3h+CgQowNmPb t87cHvg7D5BU3Gcr1DC3LlRmeefMglAZC5vWZ24dQmfQt8Y773NP5y4bLMdrScp8 vUxHi1jVwHti0ZevVzAUUntHG4LOikaC4/uY5VXc0M= Received: from smtpclient.apple (unknown [58.206.207.141]) by web2 (Coremail) with SMTP id yQQGZQAncrvEQSNoPGZCCg--.27946S2; Tue, 13 May 2025 20:57:41 +0800 (CST) From: zhangsh Message-Id: <435B4496-6908-4A76-8EBE-E07F710CA465@mails.tsinghua.edu.cn> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B2DC4BD-9D65-4F12-B039-C89054216BA9" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Date: Tue, 13 May 2025 20:57:32 +0800 In-Reply-To: <695715eb-cb85-2d4d-ec8b-c889bac9bc11@nohats.ca> To: Paul Wouters References: <716aa40e.1ddc2.196aac757f4.Coremail.zhangsh22@mails.tsinghua.edu.cn> <695715eb-cb85-2d4d-ec8b-c889bac9bc11@nohats.ca> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-CM-TRANSID: yQQGZQAncrvEQSNoPGZCCg--.27946S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw4xCr15JFyUWrW7uryfZwb_yoWruFyUpF WIgF4akrWDJw4xAw4kAw48XFW8u3s5Xw17JrnxJ342kw4Yqr12yr1fta4avF13JrWxKF42 va12qr4DZ34DZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAac4AC62xK8xCEY4vEwIxC4wAS0I0E0xvYzxvE52x0 82IY62kv0487McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72 CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkI ecxEwVAFwVW5JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c 02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_ JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5 QqXJUUUUU== X-CM-SenderInfo: x2kd0wdvksjqxpdlz2oowvx0pjkxthxhgxhubq/ Message-ID-Hash: OO3JHEZTWS3PFH2MBHN6FWLC7DO2J4SB X-Message-ID-Hash: OO3JHEZTWS3PFH2MBHN6FWLC7DO2J4SB X-MailFrom: zhangsh22@mails.tsinghua.edu.cn X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: dnsop@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5Bdnsop=5D_New_Draft=3A_Handling_Unvalidated_Da?= =?utf-8?q?ta_during_DNSSEC_Troubleshooting_=28draft-zhang-dnsop-dnssec-unva?= =?utf-8?q?lidated-data-00=29?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_4B2DC4BD-9D65-4F12-B039-C89054216BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 2025=E5=B9=B45=E6=9C=888=E6=97=A5 01:13=EF=BC=8CPaul Wouters = =E5=86=99=E9=81=93=EF=BC=9A >=20 > On Wed, 7 May 2025, =E5=BC=A0=E6=B7=91=E6=B6=B5 wrote: >=20 >> It=E2=80=99s my honor to share our recently submitted draft titled = =E2=80=9CHandling Unvalidated Data during DNSSEC Troubleshooting=E2=80=9D = (draft-zhang-dnsop-dnssec-unvalidated-data-00). >> Draft link: = https://datatracker.ietf.org/doc/draft-zhang-dnsop-dnssec-unvalidated-data= / >> Given the design complexity and the prevalence of misconfigurations = of DNSSEC, many DNS resolvers support troubleshooting mechanisms by the = public, during which the >> received DNS data are not enforced to be validated. However, as this = draft demonstrated, this could open a new attack surface, where = attackers can abuse the >> troubleshooting mechanism to inject forged data to the resolver=E2=80=99= s cache, and trigger persistent domain resolution failure due to the = reuse of the cached unvalidated >> data. To mitigate such risk, this draft proposes recommendations for = DNSSEC-validating resolvers on how to cache and reuse DNS data = introduced during DNSSEC >> troubleshooting. This draft indicates that the data intended for = troubleshooting can have severe but overlooked impact on the routine = functioning of DNS. Hence, it >> aims to raise the community=E2=80=99s awareness on handling DNSSEC = troubleshooting data with more cautious, so as to prevent any potential = abuse. >=20 > I think DNS resolvers are already handling this properly? >=20 > paul@bofh:~$ dig +cd +short dnssec-failed.org 96.99.227.255 > paul@bofh:~$ dig +short dnssec-failed.org paul@bofh:~$ >=20 In Section 3 of our draft, we particularly focus on the record types = that are *indirectly* involved in resolving a DNSSEC-signed domain, = i.e., DNSKEY, DS records, and the IP addresses of domain=E2=80=99s = nameservers. As these records are transparent to DNS clients and are = usually not directly hit by routine queries, many DNS resolvers fail to = discard them even if they have been proven invalid. For example, when a = client queries the A record of foo.com and demands validation, while the = DNSKEY of foo.com is bogus, many resolvers just discard foo.com=E2=80=99s = A record after validation failure, whereas the DNSKEY of foo.com remains = in cache and will be reused in subsequent resolutions. Hence, the = resolver encounters persistent resolution failure until the bogus record = expires from cache, i.e., the DoS vulnerability proposed in our draft. = Another similar case is that when the nameserver IP address of foo.com = is bogus, even if the nameserver domain is DNSSEC-signed, many resolvers = do not force DNSSEC validation on the nameserver domain when resolving = foo.com, but keep to reuse the bogus nameserver IP address. >> Summary of key points: >> - Clarification of unvalidated data in DNSSEC, as a complement to RFC = 4033-4035 >=20 > I'm not sure if this is unclear? >=20 We notice that the BAD cache proposed in Section 4.7 of RFC 4035 is for = caching records that =E2=80=9Cfail to validate=E2=80=9D, or = =E2=80=9Cinvalid=E2=80=9D, i.e., the records have already gone through = the validation process and have been proven invalid. It seems to be = ambiguous about whether the records that *have not been validated* = (e.g., records introduced via CD=3D1 queries) should be included in the = scope of the BAD cache. That=E2=80=99s why we clarify the definition of = =E2=80=9Cunvalidated=E2=80=9D records in Section 2 of our draft. We = suggest that DNSSEC-validating resolvers group all records that have not = passed DNSSEC validation and set a special short TTL and reuse scope for = them. The remaining records are those that have successfully passed = validation, which can be cached according to their original TTL and be = reused in subsequent resolutions without being re-validated. >> - Demonstration of a new Denial-of-Service attack surface on = DNSSEC-validating resolvers due to their reuse of cached unvalidated = data >=20 > Which DNS resolvers are currently misimplementing things for this to = be a concern? >=20 We systematically tested representative DNS resolvers in November 2024, = and found that popular DNS software (BIND, PowerDNS) and mainstream = public DNS services (Cloudflare, Quad9, OpenDNS, etc.) were affected by = the proposed attack surface. After disclosure, BIND (version >=3D9.20.7), = Cloudflare and OpenDNS have patched their products according to our = suggestions. > Paul >=20 >> - Recommendations on how to cache and reuse DNSSEC-unvalidated data = to mitigate the DoS risk >> We welcome feedback from the community. We would be happy to discuss = this in a future DNSOP session. >> Best regards, >> Shuhan Zhang >> Tsinghua University >>=20 --Apple-Mail=_4B2DC4BD-9D65-4F12-B039-C89054216BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


2025=E5=B9=B45=E6=9C=888=E6=97=A5 01:13=EF=BC=8CPaul = Wouters <paul@nohats.ca> =E5=86=99=E9=81=93=EF=BC=9A

On Wed, 7 May 2025, = =E5=BC=A0=E6=B7=91=E6=B6=B5 wrote:

It=E2=80= =99s my honor to share our recently submitted draft titled =E2=80=9CHandli= ng Unvalidated Data during DNSSEC Troubleshooting=E2=80=9D = (draft-zhang-dnsop-dnssec-unvalidated-data-00).
Draft link: = https://datatracker.ietf.org/doc/draft-zhang-dnsop-dnssec-unvalidated-data= /
Given the design complexity and the prevalence of misconfigurations = of DNSSEC, many DNS resolvers support troubleshooting mechanisms by the = public, during which the
received DNS data are not enforced to be = validated. However, as this draft demonstrated, this could open a new = attack surface, where attackers can abuse the
troubleshooting = mechanism to inject forged data to the resolver=E2=80=99s cache, and = trigger persistent domain resolution failure due to the reuse of the = cached unvalidated
data. To mitigate such risk, this draft proposes = recommendations for DNSSEC-validating resolvers on how to cache and = reuse DNS data introduced during DNSSEC
troubleshooting. This draft = indicates that the data intended for troubleshooting can have severe but = overlooked impact on the routine functioning of DNS. Hence, it
aims = to raise the community=E2=80=99s awareness on handling DNSSEC = troubleshooting data with more cautious, so as to prevent any potential = abuse.

I think DNS resolvers are already handling = this properly?

paul@bofh:~$ dig +cd +short =  dnssec-failed.org 96.99.227.255
paul@bofh:~$ dig +short =  dnssec-failed.org = paul@bofh:~$


In Section 3 of our draft, we = particularly focus on the record types that are *indirectly* involved in = resolving a DNSSEC-signed domain, i.e., DNSKEY, DS records, and the IP = addresses of domain=E2=80=99s nameservers. As these records are = transparent to DNS clients and are usually not directly hit by routine = queries, many DNS resolvers fail to discard them even if they have been = proven invalid. For example, when a client queries the A record of = foo.com and demands validation, while the DNSKEY of foo.com is bogus, = many resolvers just discard foo.com=E2=80=99s A record after validation = failure, whereas the DNSKEY of foo.com remains in cache and will be = reused in subsequent resolutions. Hence, the resolver encounters = persistent resolution failure until the bogus record expires from cache, = i.e., the DoS vulnerability proposed in our draft. Another similar case = is that when the nameserver IP address of foo.com is bogus, even if the = nameserver domain is DNSSEC-signed, many resolvers do not force DNSSEC = validation on the nameserver domain when resolving foo.com, but keep to = reuse the bogus nameserver IP address.


Summary of key = points:
- Clarification of unvalidated data in DNSSEC, as a = complement to RFC 4033-4035

I'm not sure if this is = unclear?


We notice that the BAD = cache proposed in Section 4.7 of RFC 4035 is for caching records that = =E2=80=9Cfail to validate=E2=80=9D, or =E2=80=9Cinvalid=E2=80=9D, i.e., = the records have already gone through the validation process and have = been proven invalid. It seems to be ambiguous about whether the records = that *have not been validated* (e.g., records introduced via CD=3D1 = queries) should be included in the scope of the BAD cache. That=E2=80=99s = why we clarify the definition of =E2=80=9Cunvalidated=E2=80=9D records = in Section 2 of our draft. We suggest that DNSSEC-validating resolvers = group all records that have not passed DNSSEC validation and set a = special short TTL and reuse scope for them. The remaining records are = those that have successfully passed validation, which can be cached = according to their original TTL and be reused in subsequent resolutions = without being re-validated.

- Demonstration of a new Denial-of-Service attack surface = on DNSSEC-validating resolvers due to their reuse of cached unvalidated = data

Which DNS resolvers are currently = misimplementing things for this to be a = concern?


We systematically tested = representative DNS resolvers in November 2024, and found that popular = DNS software (BIND, PowerDNS) and mainstream public DNS services = (Cloudflare, Quad9, OpenDNS, etc.) were affected by the proposed attack = surface. After disclosure, BIND (version >=3D9.20.7), Cloudflare and = OpenDNS have patched their products according to our = suggestions.

Paul

- = Recommendations on how to cache and reuse DNSSEC-unvalidated data to = mitigate the DoS risk
We welcome feedback from the community. We = would be happy to discuss this in a future DNSOP session.
Best = regards,
Shuhan Zhang
Tsinghua = University


<= /html>= --Apple-Mail=_4B2DC4BD-9D65-4F12-B039-C89054216BA9--