IETF Last Call Review of draft-ietf-dnssd-multi-qtypes-11
review-ietf-dnssd-multi-qtypes-11-secdir-lc-nir-2025-12-16-00
| Request | Review of | draft-ietf-dnssd-multi-qtypes |
|---|---|---|
| Requested revision | No specific revision (document currently at 14) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-01-02 | |
| Requested | 2025-12-12 | |
| Authors | Ray Bellis | |
| I-D last updated | 2026-05-20 (Latest revision 2026-02-27) | |
| Completed reviews |
Dnsdir Early review of -06
by Vladimír Čunát
(diff)
Secdir IETF Last Call review of -11 by Yoav Nir (diff) Dnsdir IETF Last Call review of -11 by Ralf Weber (diff) Genart IETF Last Call review of -11 by Stewart Bryant (diff) Artart IETF Last Call review of -11 by Barry Leiba (diff) Dnsdir IETF Last Call review of -12 by Vladimír Čunát (diff) |
|
| Assignment | Reviewer | Yoav Nir |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-dnssd-multi-qtypes by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/ck6kSOi0S2tBxlL497TFaiESF9c | |
| Reviewed revision | 11 (document currently at 14) | |
| Result | Ready | |
| Completed | 2025-12-16 |
review-ietf-dnssd-multi-qtypes-11-secdir-lc-nir-2025-12-16-00
Hi I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. The document is clear and straightforward. The Security Considerations states that this extension document does not change the security properties of DNS itself, and I agree. It also makes the following statement: It should however be noted that this method does increase the potential amplification factor when the DNS protocol is used as a vector for a denial of service attack. I'm not sure this is correct. Servers could (and often did) send large responses already when QTYPE=ANY was specified even if - as the draft acknowledges - RFC 8482 allows sending just one. So I don't think this document really makes the amplification problem worse.