IETF Logo Mail Archive

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Joe Abley <jabley@hopcount.ca> Tue, 02 May 2023 15:52 UTC

Return-Path: <jabley@hopcount.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 D2399C13AE28 for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 08:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lzftDnet2hl for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 08:52:41 -0700 (PDT)
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F81EC15C528 for <dnsop@ietf.org>; Tue, 2 May 2023 08:52:41 -0700 (PDT)
Date: Tue, 02 May 2023 15:52:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=protonmail; t=1683042758; x=1683301958; bh=1pZtcEpRnskm+d37M0RfIFhESyNbwLEHKStek7kSBL4=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=MT9n5HPj6+Vq24GPiJ0ibAqtD3H5V1FtRI1qgi8+TAfDCTw4xE3VN2yTUevV7IW0a Fd0hDLMNHoqc9YMJUOuM3o90/ubcmIBLE8dqpPR5blycCkvX/wFUo9D37zDFXAaNT1 nmTnt+exxKbqeRW081cpCbPwrDOK7xw1HQK9ngFiHuMDOfm1ecvsvDMXsHeiPPf9i3 TauVoy7eNZPRGi2O31DqE0ZwkQdd0amdCADrDeAZCkwq6IJkkShxorJZcvIg5mvmbN wGONZLD/MDQ3Leze4cmzv7xFDK0QsNoEo0Qj0/aovE1u4/NSC2RN7AudANDD/e81+k b9m4edzJaHwBQ==
To: peter@desec.io, dnsop@ietf.org
From: Joe Abley <jabley@hopcount.ca>
Message-ID: <kzbBDHNKGgZx8cblM37NuJUSbzcmYp5gjnEqY0j9FLSYnq8P3EeEN8xzBhcGUy7ygPravbyUCMPgNZ6wmx1jwprzNhRFCTtrPpMb8FVXiZI=@hopcount.ca>
In-Reply-To: <72c4391f-b1c8-3925-2bec-84b057cca577@desec.io>
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <B93A0E80-08F8-4FDB-81C2-47C465D8DDB4@verisign.com> <ZFD/zr7Qse5WzIQZ@registro.br> <0f956eb3-7d3e-2258-59f0-d0031c506835@nohats.ca> <e9e8515d-83b3-7b14-55d9-8b96d6acf3c1@desec.io> <72c4391f-b1c8-3925-2bec-84b057cca577@desec.io>
Feedback-ID: 62430589:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_M4frifOUSvJvwa9kPHIcV5mBx4eZ36lyXbXoQToFk"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n5GcVCM-C2tolcGtCLaxybAFXj0>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 02 May 2023 15:52:45 -0000

On Tue, May 2, 2023 at 11:09, Peter Thomassen <[peter@desec.io](mailto:On Tue, May 2, 2023 at 11:09, Peter Thomassen <<a href=)> wrote:

> If one of the NS answers non-authoritatively, then it doesn't serve a proper NS RRset, so it's not possible for that server's response to agree / be identical with that on the parent side. As a result, the delegation (to that server) is lame, isn't it?

A nameserver can answer authoritatively for a particular query without being listed in any zone's NS RRSet.

A response from a server doesn't necessarily include an NS RRSet anyway.

Whether or not two different servers that serve the same zone serve the same zone contents might be a sign of a problem, or it might be normal (e.g. a consequence of the loose coherence that is an accepted and acceptable consequence of DNS's standard replication mechanisms).

>

There are lots of things that can be wrong with DNS operations in general and with delegations in particular. A lame delegation is just one of them.

Joe

v2.23.0 | Report a Bug | By Email