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

Philip Homburg <pch-v6ops-13@u-1.phicoh.com> Sun, 23 June 2024 14:11 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.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 ECD29C14F5E0 for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 07:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3lnrlSgRe-mA for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 07:11:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EB0C14EB19 for <v6ops@ietf.org>; Sun, 23 Jun 2024 07:11:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1sLNvn-0000MhC; Sun, 23 Jun 2024 16:10:59 +0200
Message-Id: <m1sLNvn-0000MhC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-13@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <CAN-Dau0q+XJzrVWayCfVuTiMfUJVXVZmzZLQ4A6WOMaJApV1fA@mail.gmail.com> <m1sKjT4-0000JpC@stereo.hq.phicoh.net> <CAN-Dau252ufFeMh2JaxY=r+PmoQOQbBMDNteRs2kYJmd3LhKaA@mail.gmail.com> <m1sKv62-0000MEC@stereo.hq.phicoh.net> <a1d57fda-f0c3-66d6-446e-2637807ef15f@redbarn.org>
In-reply-to: Your message of "Sat, 22 Jun 2024 12:41:23 -0700 ." <a1d57fda-f0c3-66d6-446e-2637807ef15f@redbarn.org>
Date: Sun, 23 Jun 2024 16:10:58 +0200
X-MailFrom: pch-b538D2F77@u-1.phicoh.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: Paul Vixie <paul@redbarn.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/6gYE3rnbSpMWuXBdSNUND3Tt4XA>
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>

>i think you're not up to date on security risks to fragmented dns 
>messages. and i'm not going to try to fill you in since you're making 
>ignorant assertions rather than asking questions.

I tried to make a different point. It got side tracked a bit. The point I
was trying to make was that current DNS servers do not set the DF flag and
it is unlikely that this is going to change.

This is v6ops, so there is no need to discuss the security of DNS over IPv4

So for DNS over UDP on IPv6, if the DNS implementation is sending packets
that are large than 1280, then tunnels are likely to experience backholes on
IPv6 and get fragments on IPv4. It is unlikely that DNS implementations are
going to filter out IPv4 fragments. 

The net result is that for tunnels, DNS over UDP is likely to become worse
on IPv6 than on IPv4. This is something that should concern v6ops.

>the idea that the future must look like the past or present is both 
>common in the ietf and bizarre in human affairs. are we falling into a 
>progressive-vs-conservative mindset?

In this case it seems that many implementors of DNS decided to not engage in
the discussion in the first place and just do their own thing.