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

Bob Hinden <bob.hinden@gmail.com> Sun, 16 June 2024 16:08 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3A1EFC169406; Sun, 16 Jun 2024 09:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.104
X-Spam-Status: No, score=-6.104 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lhHdE1gcQivF; Sun, 16 Jun 2024 09:08:09 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7B8C1516E9; Sun, 16 Jun 2024 09:08:09 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-dfac121b6a6so2818172276.0; Sun, 16 Jun 2024 09:08:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718554088; x=1719158888; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=0irGtrODO8wP7KzgAmWj2D6+z17ucA4E8Mgivfa/cHY=; b=cLKaksnzZEKpdM6zMd2NHi2BZY77iIM91NsAsj126Nbs/wcldxziTxOnLPJQ1eyq6W XeEMrR2rzRSiGri36ffaR/0d/6mOQP52kX5YTUHPrT4biuw1zRnWLpuGFDM00IRK1XLC 2E+w0rEecYg8rm2ANfjcF/iwebXu3nZRvsBSS7/K1SpgD0SJDouyAXhfi3mC4Jsv2mpO j6tidSM9gFj9n2vDL/eNAYcakLagSM66R9BlTtCY0tPapaxrAtchBPKfDWI1yDpnxx2H qLCDbUuSBnVabjyMzQn3+yTAIj0r6cN5qDAA0qcqZVR/A/uT0ckPOr/Dd257TpiiXf24 EukA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718554088; x=1719158888; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0irGtrODO8wP7KzgAmWj2D6+z17ucA4E8Mgivfa/cHY=; b=qopd1BfKsuuDCChH43gKw8fEJtrxy4ORqFY05IR8kqONkfeBhnRWJoC6BoEqZ6zrXv Cf6nKxJce8l+gJtr+kYjZ2Pxm2gbDBPxqSPTzAnpiwnUwdFDyX6TC0sS/rcre64Eyyfi xjjmySHOUZoFuFlR16JGWimV37HCRd7faaHOCvlXjlFHCvo0moddrHwoR5KQR1c9tII5 7ZI8kiTgu7qvr5e2IjZjnKTK9RQgnJrZ0tavOWeP57YBAmQVSbjiUrC/p0n9N0ggy8Kg dS+HChAHWKfpoiruEBmhdWmFGuwkyNaMqruWf90U76KuTH8ppHoC3buOUWT1hzYJL//4 VENg==
X-Forwarded-Encrypted: i=1; AJvYcCV+QDUVq3lQgqsjhwTQF2Hl1icYSUw1uNRd0sGfrUwxizkravJ7wU+Ng/ykGuzBPMIQCtQaGmAEKjGmQLxU7O13a0LidJnRmp8yXZd8FhE=
X-Gm-Message-State: AOJu0YxXY+DRq6IZZoW6ZpBvrGo+yObIPXqVl/qOIv5oHGNhYakFLzOS IVSCQ8J56PJc14UWJoe2RwFIP6D2+TqEUv4VlyI+pB/IjeBnSi76
X-Google-Smtp-Source: AGHT+IHz+i/+eATtfseY0S6xfJB3dvMjSU9KidYbrJeOnEhWEXTKEFsj0r75hN5uAtYTqCgBllDoNw==
X-Received: by 2002:a25:906:0:b0:dfb:b03:b34d with SMTP id 3f1490d57ef6-dff1387fa85mr4919370276.15.1718554088306; Sun, 16 Jun 2024 09:08:08 -0700 (PDT)
Received: from smtpclient.apple ([2600:1700:4383:c05f:1149:f720:4a17:9b90]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-dff2f2bcac5sm753265276.59.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jun 2024 09:08:07 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <BAEBA468-9B3E-41ED-B609-1D0A9D4A0F6E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DDECC303-4B8F-4BF7-AF74-F5E3B402C7E7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Date: Sun, 16 Jun 2024 09:07:44 -0700
In-Reply-To: <CACL_3VGzQfn9Gp+Wvx6HDZt=Gbyurirgt8Sa3qah7TpNgLiQug@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <DU2PR02MB10160CCA998D5A86B9F11F2C388C22@DU2PR02MB10160.eurprd02.prod.outlook.com> <CACL_3VGzQfn9Gp+Wvx6HDZt=Gbyurirgt8Sa3qah7TpNgLiQug@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.600.62)
X-MailFrom: bob.hinden@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Suresh Krishnan <suresh.krishnan@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: [v6ops] Carrying large DNS packets over UDP in IPv6 networks
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/OkdHRkAq7Qu5lkDt40O1Xn6748A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>


> On Jun 14, 2024, at 9:00 AM, C. M. Heard <heard@pobox.com> wrote:
> Greetings,
> I recently circulated an individual draft https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses on the DNSOP list that discusses how UDP options could be used to send large DNS responses without UDP fragmentation. The one comment that came back was not favorable, arguing that it would increase the surface for reflection attacks, which TCP (and QUIC) would not. See https://mailarchive.ietf.org/arch/msg/dnsop/EhUq8tZF8Qm-iZk4eUAnjsCGXUg/ and subsequent messages in the thread.
> As for https://datatracker.ietf.org/doc/html/draft-hinden-v6ops-dns, it seems to cover much of the same territory as https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation, which has been submitted for publication. My sense is that getting the latter document published would be a better path forward for the IETF community than a new draft.

We were aware of the avoid fragmentation draft and discuss it:

A recent dnsop working group document titled "IP Fragmentation Avoidance in DNS over UDP" [I-D.ietf-dnsop-avoid-fragmentation] also describes the issue, and recommends as best current practice to disable IPv6 fragmentation for sending DNS packets over IPv6. Specifically:

	3.1. Recommendations for UDP responders

	R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].

This document is aligned with the recommendation in [I-D.ietf-dnsop-avoid-fragmentation], but focuses on DNS over IPv6, and also recommends and provides additional details on running DNS over TCP or QUIC.


> Respectfully,
> Mike Heard
> On Fri, Jun 14, 2024 at 7:12 AM <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> wrote:
>> Hi Suresh, all,
>> (ccing tsvwg)
>> FWIW, large DNS packets was the main driver for the FRAG UDP option: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-32#section-11.4. 
>> On the reco in the draft, I'm not sure how this can be put into effect given that the client does not know whether the reply will be large or not when it reaches out a resolver.
>> Also, when you mention "DNS over QUIC" are you referring to DoQ per RFC 9250? If so, I'm afraid that there are many implications (e.g., authentication, compatibility with the presence of local forwarders). Also, if DoQ is recommended, why not DNS over TLS or DNS over HTTPS? You may refer to DNR/DDR (RFC9463/9462) for the discovery matters of whether local resolvers support DoQ, DoH, DoT, etc. + which authentication domain name to be used to authenticate a server.
>> Cheers,
>> Med
>> > -----Message d'origine-----
>> > De : Suresh Krishnan <suresh.krishnan@gmail.com <mailto:suresh.krishnan@gmail.com>>
>> > Envoyé : vendredi 14 juin 2024 13:56
>> > À : v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > Objet : [v6ops] Carrying large DNS packets over UDP in IPv6
>> > networks
>> > 
>> > 
>> > Hi all,
>> >   At the last 6man meeting in Brisbane, Jared Mauch brought up an
>> > issue with large DNS packets carried over UDP in IPv6 networks.
>> > Bob and I have written a draft recommending the use of TCP or
>> > QUIC for such large packets instead of UDP.
>> > 
>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> > Fdatatracker.ietf.org <http://fdatatracker.ietf.org/>%2Fdoc%2Fdraft-hinden-v6ops-
>> > dns%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com <http://40orange.com/>%7Cbdb1f68f5a
>> > a84a89263a08dc8c690ce2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
>> > %7C638539630010730229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
>> > a=ts2PogUeq3dRA0NulYmQaJaCydLLhhJeM463qV%2BHgVU%3D&reserved=0
>> > 
>> > We would greatly appreciate your comments on this draft.
>> > 
>> > Thanks
>> > Suresh
>> > _______________________________________________
>> > v6ops mailing list -- v6ops@ietf.org <mailto:v6ops@ietf.org>
>> > To unsubscribe send an email to v6ops-leave@ietf.org <mailto:v6ops-leave@ietf.org>
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.