Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

Geoff Huston <gih903@gmail.com> Thu, 29 July 2021 01:45 UTC

Return-Path: <gih903@gmail.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 F23A73A0A9C for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 18:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Jej8Dah3ah for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947B53A0A99 for <dnsop@ietf.org>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id d17so4976144plh.10 for <dnsop@ietf.org>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Fw/X/bjk7wmtrx9Y6tLui/7ppCxHFr1LDX7CrZDAxc4=; b=tEsb0VRGlSPG/gVWcw/l6tJ6kc4q29cMT08vpnNkOERzvpQ51wJ0pXwOMXfbh6GD59 O/Klf0cAfSPYbluLrfkNZvNXTYPPNZOnVGHQZQIkIMLmrbugurw4xImNVMcBJuEKPKmr 8d+25dnWNtth/PJIq48fOFe6F2tUWCz0o4tRv+9IJtbjMAd80zbXJipxwUBVO+x+dJg3 QRmnjGL/1p5rXjujxfHOlwKqIpIXb9IJSSTOl6nlqQChIxmjeFRdRUQ5Ifgl+i/zxMko +iEV4uRdvbaRFYghOd/5W/3Y2Z8Cor8Zat0pTxA+Uo0e88rETq25X+QiDDFAQ9M0Qefj mecw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Fw/X/bjk7wmtrx9Y6tLui/7ppCxHFr1LDX7CrZDAxc4=; b=PYHG8HBqmZPslqAOlRUb5Mbs4KRfw0AW6mCzQYdTd0DVLQsCmHH5t/x/X7eDmthFLh q4xigqO7qikPIN1ZzAAz5+KOYiXBUChIMeLNmLUbKOWJpOrVSUYNuuJGwoboUSvUQzam 5BEGpBFqFKxsV5/puUF0sPM8QnU4wj9JHNTvn+JRDqbXW4jws8vdxdW5Dru5vsQa3lym f2VVqGKYjVxlbbSf1+WGL3XuFkFC6sjUaFRCUOiLKhi4UNC39V34gXVyTd4784z/0WI6 q8UvnEZerK/SaiSuFCSwBoWizOnr+AFCdZwwzBGJzdN7duurqXRzpSotRSazXzc/HO0t FT7w==
X-Gm-Message-State: AOAM532ZPaYIHhe6DWgJMlCeVqN2lfKUHMgC7gb2hk9DqGPB9t0Nfw74 O8jkAM5ysDFeZartRxwAbm9s5GBE0f8=
X-Google-Smtp-Source: ABdhPJwgNNGgQfNeHQ8T97tI3q/GYGU7BWva8nSI71zfFR3i0uqldW7guR/uGme4vJ0l3fXZYCdnOw==
X-Received: by 2002:aa7:88d4:0:b029:329:be20:a5c with SMTP id k20-20020aa788d40000b0290329be200a5cmr2573077pff.61.1627523132258; Wed, 28 Jul 2021 18:45:32 -0700 (PDT)
Received: from smtpclient.apple (2001-44b8-110b-5100-0440-191b-b1e3-3449.static.ipv6.internode.on.net. [2001:44b8:110b:5100:440:191b:b1e3:3449]) by smtp.gmail.com with ESMTPSA id w22sm1262031pfn.188.2021.07.28.18.45.29 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 18:45:31 -0700 (PDT)
From: Geoff Huston <gih903@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 29 Jul 2021 11:45:28 +1000
References: <CA+9_gVstayRZufjKbi3TgKxnsg-Jt52y1Z3Znnmocyf_iSdoiQ@mail.gmail.com> <20210727201504.2939B25365A4@ary.qy> <CAHPuVdX4jwn=U9ONkuGd_LU0cgcGVyNpy7=aHnjqtX8MHTj2tg@mail.gmail.com> <372D08DF-8FD5-48EF-9D1F-261F8E185DFC@gmail.com> <e88632f0-15cb-21d5-efb0-49a915d0604@nohats.ca> <738E8C69-FB67-47C6-9EB9-FA980A2A658C@gmail.com> <0.2.0-final-1627518790.482-0x111b95@qmda.emu.st>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <0.2.0-final-1627518790.482-0x111b95@qmda.emu.st>
Message-Id: <97B5600F-B3FD-4BF1-8892-6639F96F4826@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mlyvIOk0UVLIevvtUmrYBoHKVC8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Jul 2021 01:45:38 -0000


> On 29 Jul 2021, at 10:33 am, Mark Delany <m9p@india.emu.st> wrote:
> 
> On 29Jul21, Geoff Huston allegedly wrote:
> 
>> For me it appears to depend on the actions of the resolver as to whether this would be faster
>> or not. If all resolvers blindly re-query using TCP for all UDP responses where TC=1 is seen in
> 
> I'm not sure I follow this bit. Are you merely implying that the resolver should first
> consider a larger edns0 bufsize before resorting to TCP?

Seems that the DNS Flag Day 2020 precluded that option, so I don’t think its available.

> 
> Or are you suggesting that responses with TC=1 should include as much of the answers as
> will fit and then the resolver can decide whether enough is enough?

Well no. Because RFC2181 says "When a DNS client receives a reply with TC set, it should
ignore that response, and query again, using a mechanism, such as a TCP connection, that
will permit larger replies.”, which, unless there is some later RFC that quietly countermanded
this directive then I don't think the resolver has a choice here.

(digression into the interpretation of the term “should” in a document that pre-dates normative 
language. Is that “should” used then in the way we use MUST today? Or is that a SHOULD? I interpreted
it as a MUST but as I don't write resolver code for a living or as a hobby (and you should all be thankful
for that!) I'm definitely not an authoritative sources as to how resolvers SHOULD or MUST interpret
TC=1 responses.


Geoff