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

Geoff Huston <gih903@gmail.com> Thu, 29 July 2021 01:23 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 D3F9F3A0972 for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 18:23:50 -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 7ndSwRc27lc7 for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 18:23:46 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 3F97A3A0970 for <dnsop@ietf.org>; Wed, 28 Jul 2021 18:23:46 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id n10so4958783plf.4 for <dnsop@ietf.org>; Wed, 28 Jul 2021 18:23:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=803a8xGzQ+cg74ZXAIYD7Mb++r6m9JsPdOybJoJUArk=; b=BWMS2phP8l+xhw/XhbYUc/4yXco/HmJPuXyQn6OIR9AulTUV2TpvrYhHO5WdLDfWvV j9FEwSycw0H3aX51nyFf0ffq3FfegHcn195aeDTZFVJdbkkCe1+zWHc6ZU/zzG0HHOI/ kvpFrTURRdiCGB8s/pXhEeJ8RDmKxctlOhcduD4IYWQS3Q5raFY1W1qWmSbSLmazP0kW YYrjS+BGnOS0GD3WetxCWl/U6eyNbu5Wm/tQJLHACwaR0b+qNOTIeFg9koF6C/4lBTnZ zdWj2hE+sL0+ZiVcFxAkc6xsS0yX86Y/ZIb91Z6yiIzRVkIoFyBLUq2W+mQkXYsNMyCx RKKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=803a8xGzQ+cg74ZXAIYD7Mb++r6m9JsPdOybJoJUArk=; b=Un/CxfRyeBqQsNTcRP4ix00Va+JWUZjqN0v28am/WphK/prZheQnuEVcPzKP2khSs5 dPJHGYWrnRGd4A26NCcRtDmaHN8fK9El4DnVPruH2gslbdXw0T9Ocqwr3TNLr6RKWSn1 ezxxhOa049ItjLzixQkf06Q00zsJYeq9r+W/kdCdy83YBuhgAcPWtsNc0Y28jfLjFmgW DUN8pbmFYlcV0CGPEqjql7ULcbNmIhWvEi/MtAisnsjaPa6ilYKevd0OwvoD/YJVTp/V 9//j370TkdYqYL6SrPiH3fZNw+6zbQsf1BjXtQn+GXYpmfpJ/DxdohVqHYYiCKmZqV9S gsyw==
X-Gm-Message-State: AOAM532nk7wHKtiOiwoWl/8wjgzE/WozAGEuW0eZQ2VlnSaIi91wDMkO 33lvtyOdeocu4nUxwEvOwlI=
X-Google-Smtp-Source: ABdhPJwbO6MlGJC8E1ktKv1Gf8Sd5dhOWVeaVw77Rf0fimvV2efY7MeZIm9D86Tdjy5/qopQXPnxlQ==
X-Received: by 2002:a17:90a:e56:: with SMTP id p22mr2578676pja.73.1627521824920; Wed, 28 Jul 2021 18:23:44 -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 lt15sm7245256pjb.1.2021.07.28.18.23.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 18:23:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Geoff Huston <gih903@gmail.com>
In-Reply-To: <42145164-3872-4FEC-B2EF-FAB2587DEF4A@isc.org>
Date: Thu, 29 Jul 2021 11:23:35 +1000
Cc: Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A015BE66-4801-469C-81E8-55D5B07BB4C3@gmail.com>
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> <42145164-3872-4FEC-B2EF-FAB2587DEF4A@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uAHthj1fH4ZJZBoqb1ezzccsUNM>
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:23:51 -0000


> On 29 Jul 2021, at 10:12 am, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 29 Jul 2021, at 09:58, Geoff Huston <gih903@gmail.com> wrote:
>> 
>> Hi Paul,
>> 
>>> On 29 Jul 2021, at 2:10 am, Paul Wouters <paul@nohats.ca> wrote:
>>> 
>>> On Wed, 28 Jul 2021, Geoff Huston wrote:
>>> 
>>>> i.e. amend section 3 to read:...
>>>> 
>>>> 3. Recommendations
>>>> 
>>>> This document clarifies RFC1034 in that in-bailiwick [RFC8499] glue (being part of all
>>>> available glue records) MUST be returned in referral responses, and there is a requirement
>>>> to set TC=1 if all in-bailiwick glue cannot fit in the response.
>>> 
>>> I think the reasons for returning non-in-bailiwick are the same as for
>>> in-bailiwick glue. You want to give the client as many DNS servers as
>>> possible to increase resilience of the zone. What is your argument for
>>> making this less resilient?
>> 
>> The current version of the draft proposes a mandatory (“MUST”) inclusion of all
>> in-bailiwick glue records, all “sibling” glue records and is silent on all other
>> (non-in-bailiwick) glue records.
>> 
>> I had suggested text that was intended to maintain the approach already used in
>> the draft but I suggested dropping the mandatory (MUST) inclusion of the so-called
>> “sibling” glue records, and leaving the mandatory to include provision only
>> relating to in-bailiwick glue records.
>> 
>> Now the draft/operational advice could go in many directions at this point:
>> 
>> a) for basic functionality of DNS resolution it should be mandatory (MUST) to include
>> in-bailiwick glue records (it’s not clear if “all”) is appropriate for the basic
>> functionality of the DNS resolution protocol.
>> 
>> b) for more robust resolution performance it would be a good idea (SHOULD? MUST?) to include _all_
>> in-bailiwick glue records.
>> 
>> It's unclear to me that a compelling case can be made to MUST include _all_ glue records in a referral
>> response, particularly relating to non-in-bailiwick glue records. 
> 
> Take the case where only one of the servers for the delegated zone is available.  If it is not a
> MUST you end up with resolution failures despite the server being available.  The MUST ensures that
> the requisite bootstrapping record is available.
> 
>> 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
>> responses, then the additional query could be seen as wasted time that could contribute to
>> slower resolution times. If resolvers actually treat TC=1 in a more optional manner, as in “more
>> information is available, but if you've got what you needed to move on, then don’t bother
>> with the TCP followup query.” I suppose it depends on how strictly one interprets the guidance in
>> Section 9 of RFC2181, which appears to state that TC=1 means requery, to paraphrase the text
>> in that RFC.
>> 

It's a tradeoff. If TC=1 mandates a requery using TCP then this additional robustness is gained at the
expense of a slower resolution of a referral response.

I would normally expect such tradeoffs to be described in terms of MAY or even SHOULD to guide
the implementer / operator as to a suggestion resolution of these factors while still leaving room
for some folk to tailor their DNS enviroment to meet a different set of priorities.

A MUST pre-ordains a particular set of priorities (in this case an improved robustness for all at
the cost of resolution time), which seem to be to be somewhat presumptive.

When we have a situation that negatively impacts a small proportion of use cases, then it is reasonable
to impose some time / performance penalty on _all_ use cases by making mandatory (MUST) changes to the protocol
to address such corner cases? (No, I don't have a simple answer to this question, either in this specific
case of the more general situation, but it seems that this question is at the core of what we are talking
about here.)

Geoff