Skip to main content

Last Call Review of draft-ietf-tsvwg-udp-options-39
review-ietf-tsvwg-udp-options-39-dnsdir-lc-blacka-2025-02-15-00

Request Review of draft-ietf-tsvwg-udp-options
Requested revision No specific revision (document currently at 45)
Type Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2025-02-10
Requested 2025-01-27
Authors Dr. Joseph D. Touch , C. M. Heard
I-D last updated 2025-02-15
Completed reviews Secdir Early review of -22 by Paul Wouters (diff)
Intdir Early review of -19 by Carlos Pignataro (diff)
Genart Last Call review of -38 by Robert Sparks (diff)
Dnsdir Last Call review of -39 by David Blacka (diff)
Intdir Telechat review of -38 by Antoine Fressancourt (diff)
Dnsdir Telechat review of -40 by David Blacka (diff)
Assignment Reviewer David Blacka
State Completed
Request Last Call review on draft-ietf-tsvwg-udp-options by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/iff42mm96jfGwndBrgG1EHa97GE
Reviewed revision 39 (document currently at 45)
Result Ready
Completed 2025-02-15
review-ietf-tsvwg-udp-options-39-dnsdir-lc-blacka-2025-02-15-00
This specification is well-written, well-organized, and clear.  This
specification sits at a layer below the DNS and thus does not depend on DNS in
any way.  However, DNS is a significant *user* of UDP and may benefit from the
adoption of UDP transport options.  In fact, the draft mentions DNS in this
context:

Section 5, paragraph 2:
> Among the use cases where this approach could be of benefit are
> request-response protocols such as DNS over UDP [He24]

He24 is "draft-heard-dnsop-udp-opt-large-dns-responses", which describes using
the MRDS and FRAG UDP options to (optionally) return larger DNS responses over
UDP without incurring the same security and usability issues as standard IP
fragmentation.  I don't know if DNS implementations would take advantage of this
or not, but the idea is reasonable. This is perhaps the most obvious application
of UDP transport options to DNS, but may not be the only options that could be
used.

I can't think of anything that would prevent DNS implementations from using UDP
transport options if they were available.