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

"C. M. Heard" <heard@pobox.com> Fri, 14 June 2024 16:00 UTC

Return-Path: <heard@pobox.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC33AC14F6AB; Fri, 14 Jun 2024 09:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o89zUmk4Zqi7; Fri, 14 Jun 2024 09:00:51 -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 56315C14F6A8; Fri, 14 Jun 2024 09:00:51 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5D13B232A6; Fri, 14 Jun 2024 12:00:42 -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=dEcPD1xwD1nC/dBqblEQQaw+E3TPNBIZ YcpsbhStq1Y=; b=qqTYDxEIgUCHIp1N0l4/MAFa/yd8WcWAXYptoDbnZRf6+gP7 9UrpFls8q18MHA3cgVWdC9Fcck5LRQ/bbidOguluQoHoOwYBqIvAqikp4bDNPAls p0PTXD7bJAAJNQu5MVufxxOZc4wcOGVvI7/92peV9XI+JikcUFQvujj+0Xk=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 526BA232A5; Fri, 14 Jun 2024 12:00:42 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-ed1-f49.google.com (unknown [209.85.208.49]) (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 AA822232A2; Fri, 14 Jun 2024 12:00:41 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-57a44c2ce80so2752247a12.0; Fri, 14 Jun 2024 09:00:41 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWNWIEIUfKV0ZK6xbNqRAc7OzkgonFKzsv8KpcIEB0j2VVzmJspACi5c7lfWAYdJcFGqsjYYUY9IjCUjebjIScbwLayxXrZJp1gtVgntQY=
X-Gm-Message-State: AOJu0YyJIt83VugWmMDcfMnhadgUoP0yLoYmMMkufB4Y7+YgzFPTIl3l GnDM1Vc7d6tkcjIED6sVM1a/AzBt6EnJbVkXvn+ZrocNw9mQ7XawTJ2xOfKp6mS7IRWzqQlQWYU w/sVvMEJrplSRZW40ITrXH7wYHAE=
X-Google-Smtp-Source: AGHT+IGoO8eQrj2hqpEucFZvCqGdfb5URqvsQ85i2If2z/Dc4k75xF3RDZ8OpF/zNMXmTEDHxevLyh5WEn1MQp9KmJ0=
X-Received: by 2002:a50:8d4c:0:b0:57c:bd49:9969 with SMTP id 4fb4d7f45d1cf-57cbd8e73f4mr2101381a12.39.1718380840726; Fri, 14 Jun 2024 09:00:40 -0700 (PDT)
MIME-Version: 1.0
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <DU2PR02MB10160CCA998D5A86B9F11F2C388C22@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160CCA998D5A86B9F11F2C388C22@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 14 Jun 2024 09:00:28 -0700
X-Gmail-Original-Message-ID: <CACL_3VGzQfn9Gp+Wvx6HDZt=Gbyurirgt8Sa3qah7TpNgLiQug@mail.gmail.com>
Message-ID: <CACL_3VGzQfn9Gp+Wvx6HDZt=Gbyurirgt8Sa3qah7TpNgLiQug@mail.gmail.com>
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary="00000000000099bc4b061adbb70f"
X-Pobox-Relay-ID: 401912E4-2A67-11EF-ADDA-965B910A682E-06080547!pb-smtp2.pobox.com
Message-ID-Hash: F7XSKZTL2DU7IJAWZHZI367X3XRCNK5E
X-Message-ID-Hash: F7XSKZTL2DU7IJAWZHZI367X3XRCNK5E
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: 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: [v6ops] Re: [tsvwg] 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/Bx_i433q3603_y63xJ4CFhph5u0>
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>

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.

Respectfully,

Mike Heard

On Fri, Jun 14, 2024 at 7:12 AM <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>
> > Envoyé : vendredi 14 juin 2024 13:56
> > À : 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%2Fdoc%2Fdraft-hinden-v6ops-
> > dns%2F&data=05%7C02%7Cmohamed.boucadair%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
> > To unsubscribe send an email to 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.
>
>