Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional

Paul Vixie <paul@redbarn.org> Fri, 22 May 2020 01:36 UTC

Return-Path: <paul@redbarn.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 2D1F83A0D68 for <dnsop@ietfa.amsl.com>; Thu, 21 May 2020 18:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pave2OlESzxx for <dnsop@ietfa.amsl.com>; Thu, 21 May 2020 18:36:03 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27553A0C3D for <dnsop@ietf.org>; Thu, 21 May 2020 18:36:02 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4737CB074A; Fri, 22 May 2020 01:35:59 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Fri, 22 May 2020 01:35:58 +0000
Message-ID: <2579854.HOIbhPnuQa@linux-9daj>
Organization: none
In-Reply-To: <380a2b8e-0680-5caf-401f-b7b4f1bafb1f@necom830.hpcl.titech.ac.jp>
References: <CADyWQ+Ee0qXCVA+xarfaWc-BnDmBPHkvRx2dTOKOr_kU_1MNRA@mail.gmail.com> <380a2b8e-0680-5caf-401f-b7b4f1bafb1f@necom830.hpcl.titech.ac.jp>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B9rOeHBlgcE2H94NXfs0GhuJnvI>
Subject: Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
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: Fri, 22 May 2020 01:36:07 -0000

On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote:
> ...
> 
> While I'm not against the clarification, the draft should mention
> that rfc1034 already states:
> 
>     To fix this problem, a zone contains "glue" RRs which are not
>     part of the authoritative data, and are address RRs for the servers.
>     These RRs are only necessary if the name server's name is "below" the
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     cut, and are only used as part of a referral response.
>                  ^^^^^^^^^
> 
> which means the glue RRs are necessary for a referral response.
> Though not very obvious, it logically means that they MUST be
> included as part of a referral response, because it is the only
> reason to make them necessary.

i agree. this is why later versions of BIND would return referrals rather than 
answers when queried for these names, which were in-bailiwick but below-zone. 
by implication, they can only be retrieved from the delegating server as part 
of a referral, and they will be in the additional section not the answer 
section even though they do match the qname. this distinction is also 
necessary in the assignment of credibility levels in the downstream cache.

-- 
Paul