Hi, I'm writing this as a DNS implementor, not as DNSOP co-chair.
I've read the drafts and here are my comments: ### draft-li-dnsop-resolver-resilience ### draft-qiu-dnsop-enhanced-bailiwick ### draft-li-dnsop-response-preprocessing ### draft-li-dnsop-deep-delegation-scrutiny These drafts describe attacks and provide implementation guidance. Personally, I think it should be left to the implementations to have their own mitigations against these types of attacks. The exact mitigations should not be specified as Internet Standard as they might differ implementation-by-implementation. I think the diversity of the DNS implementations is a strength and not weakness. ### draft-qiu-dnsop-rd-flag-clarification My understanding is that the draft says: DNS Resolver need to follow the existing standards. I don't understand why we would need extra RFC for that. RFC 1034 already says: > Note that the name server should never perform recursive > service unless asked via RD, since this interferes with trouble shooting > of name servers and their databases. ### draft-li-dnsop-ecs-aggregation-fix RFC 7871 is informational, this draft can't target the Standards Track. Moreover, the content of the draft was already described in: https://datatracker.ietf.org/doc/html/rfc7871#section-11.2 If there's enough interest in the working group, the RFC 7871 might be updated, but extra RFC for something that's already in the Security Section of an existing RFC doesn't make sense. Cheers, Ondrej -- Ondřej Surý (He/Him) [email protected] > On 12. 1. 2026, at 7:01, 仇渝淇 <[email protected]> wrote: > > Hi DNSOP, > > My name is Yuqi Qiu. My supervisor Xiang Li and I recently submitted six > Internet-Drafts. > > We wrote these documents based on recent academic research. This research > includes findings on TsuKing, MaginotDNS, DNSBomb, TUDOOR, and Phoenix > Domain. The results showed that many current resolvers have logic > vulnerabilities. > > Our goal is to provide clear operational guidelines to fix these issues. We > want to help implementers make their resolvers more secure. We have > summarized the drafts below for your convenience. > > 1. Resilience Against DoS and Amplification > • Resolver Resilience draft-li-dnsop-resolver-resilience-01 This draft > provides best practices for handling query timeouts and aggregation. It helps > prevent Pulsing DoS attacks such as "DNSBomb”. > Link: https://datatracker.ietf.org/doc/draft-li-dnsop-resolver-resilience/ > • RD Flag Clarification draft-qiu-dnsop-rd-flag-clarification-01 This > draft clarifies how resolvers should handle the RD flag when it is set to 0. > This standardizes behavior to stop loop amplification attacks like "TsuKing”. > Link: https://datatracker.ietf.org/doc/draft-qiu-dnsop-rd-flag-clarification/ > > 2. Strengthening Cache Logic > • Enhanced Bailiwick Checking draft-qiu-dnsop-enhanced-bailiwick-01 This > document defines stricter rules for accepting data into the cache. It > mitigates cache poisoning threats found in "MaginotDNS”. > Link: https://datatracker.ietf.org/doc/draft-qiu-dnsop-enhanced-bailiwick/ > • ECS Aggregation Fix draft-li-dnsop-ecs-aggregation-fix-00 This draft > improves how resolvers handle queries with ECS options. It restores the > effectiveness of query aggregation to prevent attacks like "RebirthDay”. > Link: https://datatracker.ietf.org/doc/draft-li-dnsop-ecs-aggregation-fix/ > 3. Handling Malformed Packets and Deep Hierarchies > • Response Pre-processing draft-li-dnsop-response-preprocessing-01 This > draft provides guidelines for validating incoming packets before processing > them. It prevents logic vulnerabilities exposed by the "TUDOOR" attack. Link: > https://datatracker.ietf.org/doc/draft-li-dnsop-response-preprocessing/ > • Deep Delegation Scrutiny draft-li-dnsop-deep-delegation-scrutiny-00 > This draft recommends checks for domains with an excessive number of labels. > It helps mitigate revocation evasion techniques like "Phoenix Domain”. > Link: > https://datatracker.ietf.org/doc/draft-li-dnsop-deep-delegation-scrutiny/ > We believe these drafts fill important gaps in DNS security. We will attend > IETF 125 in Shenzhen and look forward to discussing these topics with the > working group. > > We welcome any feedback on the mailing list. > > Best regards, > Yuqi Qiu > Nankai University > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
