[v6ops] Re: Carrying large DNS packets over UDP in IPv6 networks

"C. M. Heard" <heard@pobox.com> Sun, 23 June 2024 21:07 UTC

Return-Path: <heard@pobox.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 27FE2C14F5EE for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 14:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Status: No, score=-2.806 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gvpOrOQFmAUf for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 14:07:08 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97EBC14F5E9 for <v6ops@ietf.org>; Sun, 23 Jun 2024 14:07:08 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown []) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7E28E333A7 for <v6ops@ietf.org>; Sun, 23 Jun 2024 17:07:07 -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:content-transfer-encoding; s=sasl; bh=L08Dt+ vg0Cr7Nah1N+h1uAW6H2DbkJX6grkwck1lZk8=; b=LaV0CaGK+3OMqQl5LnsN4Y OrbwvH32lVHp4ux87/PBlynoom+8Ng4KmIKFDfiKS5FrUmil1Rh27e+0ODGqjn3R Wr/8NYGBm/KKjVaAJ/tt6XMSan8bQsxnawdDYdcSzuFSuomdoOej+VdyQd0mKoLz pCKRiN4ZPbOih7RjKyXkc=
Received: from pb-smtp2.nyi.icgroup.com (unknown []) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5837D333A6 for <v6ops@ietf.org>; Sun, 23 Jun 2024 17:07:07 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-ed1-f43.google.com (unknown []) (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 B7923333A5 for <v6ops@ietf.org>; Sun, 23 Jun 2024 17:07:04 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-57cc1c00ba6so4360533a12.1 for <v6ops@ietf.org>; Sun, 23 Jun 2024 14:07:04 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVEJs9zz8Q0f3VptJGV3uo9njakfQZoBQUedHfe8NoSnxOlaOlun6sjD6JcSdt0zSzrsSiu1itDbEUtDwAc3Q==
X-Gm-Message-State: AOJu0Yw231VGy5YDpjpovMHCLF772xjYZ/jgEHIUfLiPxnZWWNaXj6Lh 6fiFk3HMEZjqDt41ODup64f8OsVERd1YP7d9zGSel6H6giXfIm5QJ3KN8Kxg42kXu2B02xPJEfW BT42NB0W2v/1AWVt8OTUAa5vCKS0=
X-Google-Smtp-Source: AGHT+IHHingnnjGuYlSOAOHmsIqYEVP/NKf1OSAOFpk665/x03r54diDFxi26zz33E9XaHZ50tiT4olvtjFIINpe7sI=
X-Received: by 2002:a50:cd59:0:b0:57c:6a1f:11d5 with SMTP id 4fb4d7f45d1cf-57d4bd63249mr1733410a12.15.1719176823561; Sun, 23 Jun 2024 14:07:03 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VFuWhqLQ2xnKh33tsnx6fpk39zqs0Kb49AP6yrpU1wuzg@mail.gmail.com> <f838c517-95e4-a4f5-1401-cc1880f3a0ed@redbarn.org>
In-Reply-To: <f838c517-95e4-a4f5-1401-cc1880f3a0ed@redbarn.org>
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 23 Jun 2024 14:06:55 -0700
X-Gmail-Original-Message-ID: <CACL_3VGAS0abO5__Eouus9J4SkNdFxQZcWQniiY+vobV=KvxBw@mail.gmail.com>
Message-ID: <CACL_3VGAS0abO5__Eouus9J4SkNdFxQZcWQniiY+vobV=KvxBw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: 8AF931EC-31A4-11EF-9CFB-965B910A682E-06080547!pb-smtp2.pobox.com
X-MailFrom: heard@pobox.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "v6ops@ietf.org" <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Carrying large DNS packets over UDP in IPv6 networks
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/W7CemGvztOzNYNSMbUJnagJ7BFY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

On Sun, Jun 23, 2024 at 1:32 PM Paul Vixie wrote:
> C. M. Heard wrote on 2024-06-23 13:06:
> > ...
> >>> If I remember the discussion correctly, quite a few open source DNS servers
> >>> do not set the DF flag for IPv4 and have no plans to do so.
> >
> > It would be more correct to say "do not plan to do so for the time being." The
> > issue seems to be that many or most versions of Linux systems do not provide a
> > means to set the DF bit without turning on IPv4 PMTU discovery, which is seen
> > as problematic owing to the ease with which ICMP messages can be forged. See
> > https://mailarchive.ietf.org/arch/msg/dnsop/Z0LeUQRBKqRwgTA12tq5Z7g8pWA/
> i think the Linux syscall API has been and could still be revised from
> time to time, but that even if it could not be revised, that would not
> be an excuse to freeze the protocol at the API's current capability level.

Indeed not, and what I was implicitly suggesting there (and explicitly
that INTAREA and V6OPS could profitably write documents urging implementors of
APIs to "do the right thing" and make it possible for application maintainers to
implement the recommendations now in draft-ietf-dnsop-avoid-fragmentation.

> > It is granted that the DF issue that Linux has does not affect IPv6.
> > But security issues with forged ICMP PTB messages certainly do.
> if we're going to change the ICMP specification to address security
> risks, i'll join that discussion. until we do that, i don't expect any
> existing DF=1 sender (such as some TCP stacks) to stop trusting PTB. in
> other words this is a distraction.

Your point is understood, though I'm willing to bet that others (including some
operators and many in the security community) strongly disagree that the issue
is a distraction. Resolving such disagreements is part of making progress.

Mike Heard