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

Havard Eidnes <he@uninett.no> Thu, 04 May 2023 18:03 UTC

Return-Path: <he@uninett.no>
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 D683CC169510 for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 11:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=uninett.no
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 iuQxmS522v0t for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 11:03:14 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) (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 54DD3C17B32A for <dnsop@ietf.org>; Thu, 4 May 2023 11:03:13 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9A0A443ECED; Thu, 4 May 2023 20:03:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1683223390; bh=VD5QKRj1y7wwtYPfLv+YB4Fc78YDH37DH7WlVnyRT4c=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=rVxY8SVouR2laonJqmYLkWKktyF9VOveQQfFgOrOzK9d2giKFoR0zXSNMs8qTYLYo EcJrX9ZPFoYFGUudIZMEFDs3XlUqjMHVGVi9wH22G1khV0PcMd79PXuu+gsrQyc0v1 EGqHjY+jEyBL49uKJ4oNIQQwxzlqIGEJ+QXSx39g=
Date: Thu, 04 May 2023 20:03:10 +0200
Message-Id: <20230504.200310.1067157690233114254.he@uninett.no>
To: m9p@india.emu.st
Cc: dnsop@ietf.org
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st>
References: <0.2.0-final-1682972681.287-0xd4930e@qmda.emu.st> <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st>
X-Mailer: Mew version 6.9 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/x4zM4srmlXFzMYSi3Ovd9Uertf0>
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: Thu, 04 May 2023 18:03:18 -0000

> I have one last question. Regardless of whether we agree
> precisely on what "lame" means, what is the call to action when
> a zone or its name servers are declared lame?

"Get your ducks in a row!"

A domain owner is presumably normally interested in name
resolution for names in his/hers domain to be "quick and
consistent".

When a recursive resolver tries to resolve a name and tries to
query a name server which doesn't handle the zone (a "lame
delegation"), this goes against the recursor's expectation, and
it can put the (domain,NS) tuple on a "bad, don't use for a
while", and will have to re-try the query with another of the
NSes in the delegation RRset.  This takes needless extra time.

Some delegating authorities actually refuse to update a
delegation if one of the NSes in the new delegation RRset doesn't
respond for the zone at the time when you request an update of
the delegation.  The .NO registry is among them.  Yes, I think
this is a good idea (and, no, this doesn't prevent deterioration
of this status over time, but at least it was correct and
consistent at the time of delegation update, and can be said to
be a "teaching aid").

> And how is that different from any other form of miscreant auth
> behaviour such as inconsistency?

Inconsistency is orthogonal to "lameness".  If all the NSes in
the union of the parent NS RRset and the child NS RRset serve the
zone, name resolution will not take "extra" time even if an
"extra" NS from the child NS RRset is queried about a name in the
given zone.  It's still inconsistent, though.

> I mean if "lame" is a precious historical term that warrants
> considered clarification, surely it has a very specific value
> that we can all act on, right? So what is that very specific
> value?

As a domain owner, ensure that you have all your delegated-to
name servers properly configured to serve your zone, aka. "get
your ducks in a row!"

Regards,

- Håvard