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

Geoff Huston <gih903@gmail.com> Wed, 28 July 2021 23:58 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 BB0543A0CD9 for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 16:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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, RCVD_IN_DNSWL_BLOCKED=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 ArHQpW4AZ5kO for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 16:58:33 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 2F8F03A0CD1 for <dnsop@ietf.org>; Wed, 28 Jul 2021 16:58:33 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id k1so4704309plt.12 for <dnsop@ietf.org>; Wed, 28 Jul 2021 16:58:33 -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=PXng7lbhlSEQX9iVgNbfmAM40vB/M65cB4Sg4dkqnVI=; b=t/Okw01Z31TQnCSl4nyRHJuTz5k5jiNlE9WhkBUapRRLwbnWYfcCGoAMUfqv7jquei PGw+4b0TPc+J1W1eIWW0Z0/zf3Ca7A9hzRQNLNzyp6J1F61TiVVpdl8H6RRf6lorScuZ ridDaVKB6ztBjg3Dv+s8BL0YAbMNvfa816wPpCfAGO260s/kqdyD7CjYLpq+U64nEpoJ 0v0HM9O9stkvFj18Vg56exdS3yz2XZdxGJhIYS11s/bqwvfr301m0n+4HI0ZTkFBl9sj liHY0kucHihV0IKICC2VIgtXHKUKWTor+97WxJzkk/fQBfLG4A6KX7decltpYf6AHuVk DTbg==
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=PXng7lbhlSEQX9iVgNbfmAM40vB/M65cB4Sg4dkqnVI=; b=px4GFk6T5hO9D9bnmIp39k2fBlv7ptxA7JItjx+oRFid/fm4FDYeNUmYTTFoL3yMae u0+mkLP+oRHEanjBIQbzypYTftpVPXZBSLls2pKGUitEA1eqd4u5flz/PtHRzkv2d9eS mBrzMf0Ry3CB1q025Tdy08hn1f2VBV9UbX0wl36aqpIhIGPbQaPlCwSKungA3BaxtPrI Wk5tMWnFV/tJyPUL7BFgN++PznVjjPQhVuDw19uSBCGexI8vawb4lEbrTjFts3hzFEXZ MaNowUxckiZeUo6QUzAYTBtwhZyUBruRVcBFgCXt9Upt+bstC3hRileTwBCpcycpIE7E nxKA==
X-Gm-Message-State: AOAM533Nnu8c7km519zUspoU0px9Tp+F/+VKJpJWKlYWGcepjCBus+ZY ozlepRBrPUKQSoXKlF75RAsJiRcVK1w=
X-Google-Smtp-Source: ABdhPJxLGavxwrZyRsGNURslq6vMoG7GvixafRDZrdrs77MFOGJP/bgDGGsU8OFwzDegdHr4KCZHpw==
X-Received: by 2002:a62:36c5:0:b029:32b:83fa:3a3e with SMTP id d188-20020a6236c50000b029032b83fa3a3emr2327526pfa.52.1627516712017; Wed, 28 Jul 2021 16:58: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 fv19sm866909pjb.34.2021.07.28.16.58.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 16:58:31 -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: <e88632f0-15cb-21d5-efb0-49a915d0604@nohats.ca>
Date: Thu, 29 Jul 2021 09:58:26 +1000
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <738E8C69-FB67-47C6-9EB9-FA980A2A658C@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>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MnfjJ_N8Vi2I9T_kWhZOA8HnYdM>
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: Wed, 28 Jul 2021 23:58:43 -0000

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. 

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