Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

"C. M. Heard" <heard@pobox.com> Thu, 02 May 2024 18:03 UTC

Return-Path: <heard@pobox.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0FAC14F5FC for <dnsop@ietfa.amsl.com>; Thu, 2 May 2024 11:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5amLDDt3RD63 for <dnsop@ietfa.amsl.com>; Thu, 2 May 2024 11:03:41 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEE8C14F5F1 for <dnsop@ietf.org>; Thu, 2 May 2024 11:03:40 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7E8051E4FE for <dnsop@ietf.org>; Thu, 2 May 2024 14:03:37 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=Huh8Lat8XOgfPhQvU7ZQt/Zv+JYujo3x lt1oCKUvs1w=; b=Q3QzEGqgxUG9bAl3wKvupKe4VKgJSh/89WfxcOPb1OPw7PsY TfaLpA5ZFHEiI+wZHoG3w2xrpJDRbnEqT3QgoaVcBtA4IobJZi+15mKSurphjCFy Rx5rnU8+nLFQT+vM/NufbdRnPsfEeYBtbH6yOqhLgkmpAvPkn+OmKLz6JwM=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 747C21E4FD for <dnsop@ietf.org>; Thu, 2 May 2024 14:03:37 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-ej1-f48.google.com (unknown [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D8C761E4FA for <dnsop@ietf.org>; Thu, 2 May 2024 14:03:36 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a58c89bda70so896079866b.3 for <dnsop@ietf.org>; Thu, 02 May 2024 11:03:36 -0700 (PDT)
X-Gm-Message-State: AOJu0YyZx0bfh67MOgw46ASy5nz/AQGbIFq2n0W4RZ1pCpRfFIiJXaDT 3/wLDHKJavdal7kjQUTegTdB5BUyyREetRCj1wiSJiPNitLCyJNbO+bJcHhOiOHZ1rkP3xldX9h uXAu6Z7vKIWqCSKs2vOoLJB6p09c=
X-Google-Smtp-Source: AGHT+IHTN3Gy7D/oHYG29HWJCM2WROWhjRlc5ANMK7z+8mjdJPQjU6yQLREmca5uweKcy3uOboIM7t7giavnTcAD1W4=
X-Received: by 2002:a50:a456:0:b0:572:7280:89db with SMTP id v22-20020a50a456000000b00572728089dbmr116423edb.30.1714673015999; Thu, 02 May 2024 11:03:35 -0700 (PDT)
MIME-Version: 1.0
References: <171433397008.17524.11626453219339950552@ietfa.amsl.com> <CACL_3VF7uNwvXFzyE5DvAet1sLVDNhtxp04hc1zsO0TH90R8AQ@mail.gmail.com> <SA1PR15MB4370ADAF4B4DDCCB8F5F5709B3182@SA1PR15MB4370.namprd15.prod.outlook.com>
In-Reply-To: <SA1PR15MB4370ADAF4B4DDCCB8F5F5709B3182@SA1PR15MB4370.namprd15.prod.outlook.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 02 May 2024 11:03:23 -0700
X-Gmail-Original-Message-ID: <CACL_3VEMu7wWLrX6-sWqYjYtGe54d6oeVwSN5kcP41sJ6xd8NQ@mail.gmail.com>
Message-ID: <CACL_3VEMu7wWLrX6-sWqYjYtGe54d6oeVwSN5kcP41sJ6xd8NQ@mail.gmail.com>
To: Ben Schwartz <bemasc@meta.com>
Cc: DNSOP <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000065c7706177c6c71"
X-Pobox-Relay-ID: 4C4AAFBC-08AE-11EF-B0F7-25B3960A682E-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TiT55DJtYr4cLLNCDi9A7_xoh6Y>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2024 18:03:45 -0000

Thank you for your reply. I have added some comments in-line.

On Thu, May 2, 2024 at 10:42 AM Ben Schwartz wrote:

> It seems like this draft says that the indicated MRDS overrides the EDNS
> BUFSIZE value.  This seems likely to create problems if the MRDS value
> could be set by a lower layer in the stack or a downstream processing
> component (without knowledge of DNS), resulting in responses that are too
> large for the DNS client's allocated buffer.  In other words, just because
> I am capable of receiving very large UDP packets does not mean that I am
> capable of processing very large DNS responses.
>

This actually should not be a concern, as the intent is that UDP options
are sent, or responded to, ONLY at the explicit behest of the upper layer.
In other words they are always opt-in. In this instance, the upper layer
would have to explicitly ask for the MRDS option to be included in the
outgoing request, and would have to set the MRDS size appropriately (which
would mean, the lesser of its own buffer capacity and what the system would
support).


> In general, support for very large DNS responses in UDP is considered
> harmful because of the potential for reflection-amplification attacks.  For
> this reason, as well as concerns about legacy compatibility and general
> complexity, I think we would be better off not attempting to use UDP
> Options with DNS.
>

Point taken - fallback to TCP does not have this particular vulnerability.

Respectfully,

Mike Heard