[DNSOP] Re: [dnsop] New Draft: Handling Unvalidated Data during DNSSEC Troubleshooting (draft-zhang-dnsop-dnssec-unvalidated-data-00)

[zhangsh <[e-mail]>]

> 2025年5月8日 01:13，Paul Wouters <[e-mail]> 写道：
> 
> On Wed, 7 May 2025, 张淑涵 wrote:
> 
>> It’s my honor to share our recently submitted draft titled “Handling Unvalidated Data during DNSSEC Troubleshooting” (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’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’s 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’s 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’s 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 “fail to validate”, or “invalid”, 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=1 queries) should be included in the scope of the BAD cache. That’s why we clarify the definition of “unvalidated” 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 >=9.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
>>