[dnsdir] Dnsdir last call review of draft-ietf-tsvwg-udp-options-39

David Blacka via Datatracker <noreply@ietf.org> Sat, 15 February 2025 21:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsdir@ietfa.amsl.com
Delivered-To: dnsdir@ietfa.amsl.com
Received: from mail2.ietf.org (mail2.ietf.org [166.84.6.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 03B2AC1D4A8F; Sat, 15 Feb 2025 13:54:10 -0800 (PST)
Received: from mail.ietf.org (mail.ietf.org [50.223.129.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPSA id 4749A101C40; Sat, 15 Feb 2025 21:54:09 +0000 (UTC)
Received: from [10.244.8.212] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD0C1D4A72; Sat, 15 Feb 2025 13:54:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: David Blacka via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <173965644784.1263979.7154002679490207060@dt-datatracker-75c44cbbdf-pxnd6>
Date: Sat, 15 Feb 2025 13:54:07 -0800
Message-ID-Hash: RLPYZTMZ4UGN2CTVAS4IKITE7GYDM4RI
X-Message-ID-Hash: RLPYZTMZ4UGN2CTVAS4IKITE7GYDM4RI
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-tsvwg-udp-options.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: David Blacka <davidb@verisign.com>
Subject: [dnsdir] Dnsdir last call review of draft-ietf-tsvwg-udp-options-39
List-Id: DNS Directorate <dnsdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsdir/iff42mm96jfGwndBrgG1EHa97GE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsdir>
List-Help: <mailto:dnsdir-request@ietf.org?subject=help>
List-Owner: <mailto:dnsdir-owner@ietf.org>
List-Post: <mailto:dnsdir@ietf.org>
List-Subscribe: <mailto:dnsdir-join@ietf.org>
List-Unsubscribe: <mailto:dnsdir-leave@ietf.org>

Reviewer: David Blacka
Review result: Ready

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.