IETF Logo Mail Archive

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

Ralf Weber <dns@fl1ger.de> Tue, 27 July 2021 23:18 UTC

Return-Path: <dns@fl1ger.de>
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 9435E3A0EE2 for <dnsop@ietfa.amsl.com>; Tue, 27 Jul 2021 16:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AdCadsuLKdcW for <dnsop@ietfa.amsl.com>; Tue, 27 Jul 2021 16:18:49 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE713A0EE1 for <dnsop@ietf.org>; Tue, 27 Jul 2021 16:18:48 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 844A95F40F96; Tue, 27 Jul 2021 23:18:47 +0000 (UTC)
Received: from [169.254.0.1] (p4ff53b1a.dip0.t-ipconnect.de [79.245.59.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 7062C5F402E7; Tue, 27 Jul 2021 23:18:46 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Mark Andrews <marka@isc.org>
Cc: John Levine <johnl@taugh.com>, dnsop@ietf.org, puneets@google.com
Date: Wed, 28 Jul 2021 01:18:45 +0200
X-Mailer: MailMate (1.14r5820)
Message-ID: <6A6C1BAF-9640-4A6C-9220-3B0A97209C93@fl1ger.de>
In-Reply-To: <D6F6C939-5FD2-4687-8D73-E4F03181C566@isc.org>
References: <20210727201504.2939B25365A4@ary.qy> <D6F6C939-5FD2-4687-8D73-E4F03181C566@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/W99D01NRIIT7X6oCyNTHvAjeSZE>
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: Tue, 27 Jul 2021 23:18:54 -0000

Moin!

On 27 Jul 2021, at 23:19, Mark Andrews wrote:

>> On 28 Jul 2021, at 06:15, John Levine <johnl@taugh.com> wrote:
>> We say that authoritative servers MUST return all the glue, which is true
>> for real glue, but not true for sibling glue (unless the sibling is in
>> a loop which is not something to encourage.)  Let's not confuse people,
>> please.
>
> The MUST is an instruction to developers.  It is not a comment on whether
> the record is actually required or not because there is a circular dependancy.
So if I see a MUST in an RFC it does not mean that this bit is required for
the protocol to work? That is not how I understand it. I agree with what
others have said that for DNS to work all real glue have to be presented.
Everything else, including sibling glue is optional and will make the
additional section bigger an hence more likely to get truncated.

I have no problem with authorities sticking sibling or even out of
zone glue in the additional section if they see fit. Resolver will
use or ignore that as they see fit and all of that if fine. However
requiring authorities to put unnecessary data in the additional section
(the sibbling glue) is not something I support.

So ong
-Ralf
——-
Ralf Weber

v2.23.0 | Report a Bug | By Email