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

Mark Andrews <marka@isc.org> Thu, 29 July 2021 00:12 UTC

Return-Path: <marka@isc.org>
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 050773A0D89 for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 17:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=isc.org header.b=bET/DjfE; dkim=pass (1024-bit key) header.d=isc.org header.b=Iqan48r3
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 1pixV5zrulgB for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 17:12:19 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE8D3A0D81 for <dnsop@ietf.org>; Wed, 28 Jul 2021 17:12:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 3CCA53AB01F; Thu, 29 Jul 2021 00:12:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1627517538; bh=MHNLgqAInmGnPM362gbYIIKCqDJZ9WyEb2QHWSsS1jw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bET/DjfE8+Dw5gq4w+KiTwBWRLiY17AtMAZb6HH7728K3n5TutIO21P98TSmLN5ip sj2II2RcR9bo82NF6Elf4pn9yZMLDC0e+9DK2d7E6HL/fUxjUAHhXxboIQEJ5z1tg5 ZIGCY+D1uVG6VCRSyHxfX/jVgDp+rX0+SUQ+umyU=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CCC2F160042; Thu, 29 Jul 2021 00:12:17 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7BF9716004B; Thu, 29 Jul 2021 00:12:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 7BF9716004B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1627517537; bh=7rWMC3OgCfXLX9+UZV8uZb7QTy21b57wVa3tJe0gTYQ=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=Iqan48r3AqGLCci2S8R8MRqpM/FC+M301NnSQMkXP5GG7F6fstYlAc2eiah3uyPUb xY9k19Cu3WKYH4Clexyiomr+O1g5ZdlrXSoKUQjU1CuH+f668Q2Dx6VKjl347B9h+Z RG76PsfBbolJ9MVM2jW92yU179+hQ93Kq1uqfu10=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W9riax88DYjg; Thu, 29 Jul 2021 00:12:17 +0000 (UTC)
Received: from smtpclient.apple (n49-177-247-47.bla4.nsw.optusnet.com.au [49.177.247.47]) by zmx1.isc.org (Postfix) with ESMTPSA id 3DD13160042; Thu, 29 Jul 2021 00:12:16 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <738E8C69-FB67-47C6-9EB9-FA980A2A658C@gmail.com>
Date: Thu, 29 Jul 2021 10:12:13 +1000
Cc: Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <42145164-3872-4FEC-B2EF-FAB2587DEF4A@isc.org>
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>
To: Geoff Huston <gih903@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KsPIU5JeKxK_QFZXSkz8p9aDd7Q>
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 00:12:25 -0000


> 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.
> 
> And there is of course the ever-present issues with the resolver’s treatment of non-in-bailiwick
> glue records.
> 
> 
> Geoff
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>>> Section 5 deviates away from protocol requirements into registry practice and
>>> the deviation appears to be at best a somewhat random thought!
>>> 
>>> It makes no sense to me to even include sections 4 or  5 in this document.
>> 
>> I guess what the document is trying to say is "this glue that is not
>> optional also applies to records that are technically not glue because
>> it is authoritative data". We really only want to mention that these
>> should still be added and TC=1 should still be set if it does not fit.
>> 
>> Paul
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org