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

Geoff Huston <> Thu, 29 July 2021 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F23A73A0A9C for <>; Wed, 28 Jul 2021 18:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d2Jej8Dah3ah for <>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 947B53A0A99 for <>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
Received: by with SMTP id d17so4976144plh.10 for <>; Wed, 28 Jul 2021 18:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ( [2001:44b8:110b:5100:440:191b:b1e3:3449]) by with ESMTPSA id w22sm1262031pfn.188.2021. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 18:45:31 -0700 (PDT)
From: Geoff Huston <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 29 Jul 2021 11:45:28 +1000
References: <> <20210727201504.2939B25365A4@ary.qy> <> <> <> <> <>
To: " WG" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jul 2021 01:45:38 -0000

> On 29 Jul 2021, at 10:33 am, Mark Delany <> 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.