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

Havard Eidnes <> Tue, 02 May 2023 23:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C9EFC151717 for <>; Tue, 2 May 2023 16:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DQATb974t-g0 for <>; Tue, 2 May 2023 16:43:12 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 8AD25C14CF1E for <>; Tue, 2 May 2023 16:43:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4236F43E9A0; Wed, 3 May 2023 01:43:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=he201803; t=1683070990; bh=hxOqycXbMEMlrxN3NiUg060iHNtcuEULJjltxrwfWAM=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=lU2UB0LaaslS/q1/hXmnlqQkNA5DUZyOYTDHR6SqsOFcwYVFfRRz/D99VUzdaT+bJ fBijs7cXWY3IXflFv6atXuIEYh8bplmLgy8unATnrbdBiEPePqvVWC3zgiOHeaEp9N IZ48mZMzU7muKZ7sYMAArMitCBpRUWTCU612Zmuc=
Date: Wed, 03 May 2023 01:43:10 +0200
Message-Id: <>
From: Havard Eidnes <>
In-Reply-To: <>
References: <> <> <>
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: <>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 May 2023 23:43:17 -0000

> My parent says that the NS for are,
> , but I ( say that my NS are,
> *and* I don't (personally) think that this
> is a lame delegation. Do others?

Nope.  Given this information, this is simply "inconsistent".

If both, and are
configured to serve the zone, and return answers with
aa=1 when queried for names in that zone, all is well and there
is no instance of a "lame" delegation.

However, if isn't set up to serve the zone,
and answers queries about names in the zone with aa=0, the
delegation to that name server would be "lame".

> Flipped around: My parent says that the NS for are
>, *and* I ( say
> that my NS are only and

At this point I'd again say "inconsistent".

> If you query, you get REFUSED. In that case I'd
> (personally) say that is lame for

You had to put that in there? :)

Thinking a bit about it: the REFUSED error code could be the
result of configuring a name server with recursion turned off,
and if you then query that name server about a name in a zone it
is not set up to serve, a REFUSED answer would be "natural" and
is these days fairly common for such a situation.

Now, as to whether that's an instance of a lame delegation?  I
would tend to say "yes".

> I don't think that I'd call "lame", as both ns1 and
> ns2 work OK.

Correct.  It's the particular delegation to ns3 which is "lame".

Another example: if both the parent / delegating zone and the
child zone lists, and, you have a perfectly consistent delegation.
However, if one of these are not set up to serve the zone, the
delegation of this zone to that particular name server would be

> I personally think that lameness is when a domain is delegated to a name
> server, but that server does not have the zone configured. A corner case is
> when the server is configured to not answer queries for that zone from that
> source address, and so returns REFUSED or possibly SERVFAIL.

If we're talking about the global DNS, restricting responses on a
publishing name server does not make much sense to me.


- Håvard