IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Wed, 28 July 2021 16:10 UTC

Return-Path: <paul@nohats.ca>
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 AEB5E3A162D for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 09:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=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=nohats.ca
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 0hUsbb9dxNOL for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 09:10:29 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 1A67F3A162A for <dnsop@ietf.org>; Wed, 28 Jul 2021 09:10:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GZdtB1H6Lz4Kc; Wed, 28 Jul 2021 18:10:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1627488626; bh=t1Lp7YIzLUO8XK521UgO2T9mIrg2ZiQEd0YkO8UVNw8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gjKmnIX1GDsWiwFtRNkhdawtyIqaLQDGWjgRWjc3vYdbjVu2QTA02sCCqtipSPt6q HB4t7HVGlVUDehYvsogYtd6bB0WgIhztj6cBgcT6N5QCKF0ZRUub5Sqgij1k5xHdUI ZhAY3kS4mzjlgHzWIZjk+t3Y1Peg/+28S1vAtRq0=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oJ8oz6U0Ebqq; Wed, 28 Jul 2021 18:10:24 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 28 Jul 2021 18:10:24 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 85C9CD248A; Wed, 28 Jul 2021 12:10:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 818C4D2489; Wed, 28 Jul 2021 12:10:23 -0400 (EDT)
Date: Wed, 28 Jul 2021 12:10:23 -0400
From: Paul Wouters <paul@nohats.ca>
To: Geoff Huston <gih903@gmail.com>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <372D08DF-8FD5-48EF-9D1F-261F8E185DFC@gmail.com>
Message-ID: <e88632f0-15cb-21d5-efb0-49a915d0604@nohats.ca>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1O6G8hjHx38lx_SdgjP1PZdGVN4>
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 16:10:34 -0000

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?

> 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

v2.23.0 | Report a Bug | By Email