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

Havard Eidnes <he@uninett.no> Tue, 02 May 2023 23:18 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 852AAC151B2D for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 16:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 toW62AwjOB0e for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 16:18:52 -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 19CB5C15155B for <dnsop@ietf.org>; Tue, 2 May 2023 16:18:50 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 40BFB43ED0B; Wed, 3 May 2023 01:18:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1683069527; bh=4eHcxmj9N9+LHUh5gPq9YQoYLstPGn/ENOEx4FremJo=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=SAcnXSgKWYzXZGINHKU/PsyJN8u71HzyIe3p+lay4dMLOzAnynKT6xzKX0jx7AkED 2dtARoSMOm1T2eNe3Wd7KwNLq4kSs3SG3oAzYNYpxGiwYRD/IBqQiPT1yYGsOvyOpP y3gmLyTOR9c3PrizzLwSLmb4b8OYbDEvK0pNIBsY=
Date: Wed, 03 May 2023 01:18:47 +0200
Message-Id: <20230503.011847.1602129642320046589.he@uninett.no>
To: paul@nohats.ca
Cc: peter@desec.io, paul=40redbarn.org@dmarc.ietf.org, jabley@hopcount.ca, m9p@india.emu.st, dnsop@ietf.org
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <ae57e5d7-a3e7-d06f-db1a-ce78aa2c8065@nohats.ca>
References: <c5cf66ab-716f-6a9f-1572-444e88a12a6c@redbarn.org> <2011730a-1206-63fb-bc98-019e53a5ea4a@desec.io> <ae57e5d7-a3e7-d06f-db1a-ce78aa2c8065@nohats.ca>
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/pTWlhIvSBPMnLXmXqE9vKBvFFIg>
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 23:18:57 -0000

>>    "A lame delegation is said to exist when one or more authoritative
>>    servers designated by the delegating NS RRset or by the child's apex
>>    NS RRset answers non-authoritatively [or not at all] for a zone".
>>
>> ... without the "or not at all" part (so, an answer is required for
>> "lameness").

I'm agreeing with the above, and think it is a precise
description of the term under discussion.

> I don't think that is complete.

I disagree.

> If all the parental NS records point to properly working
> nameservers, but the authoritative nameservers claim an
> additional NS record, I would also call the delegation
> lame.

In that case (and no other conditions given), I would simply call
the delegation inconsistent.

As has been said elsewhere, many recursors will let the NS RRset
from one of the authoritative name servers for the child zone
override the NS RRset received from one of the name servers of
the parent zone.

However, at this point in the description, the "additional" name
server *could* be have been configured to serve the zone, and
nothing untoward would happen operationally as a result.
However, the delegation would still be inconsistent.

> Especially if that additional nameserver specified in the
> authoritative NS RRset is responding non-authoritatively.

Then that response will be an indication that the delegation to
that name server would be characterized as being "lame" (even
though the corresponding NS record doesn't come from the parent
zone; this is covered by the quoted text above).

> This might not be lame on the initial queries, but if the
> resolver is child centric or validating, that broken
> authoritative NS will end up getting queried and a lame answer
> would be given.

Correct.

> How about:
>
>     "A lame delegation is said to exist when the NS RRset of a zone is
>      different at the parent and child nameservers, with the mismatched
>      authoritative servers either listed at the parent or child answering
>      non-authoritatively for that zone."

I don't think this is a good definition because to me this over-
focuses on the "inconsistent" aspect, and it is not so that every
inconsistent delegation includes an instance of a lame
delegation.

On the other hand, you can have a perfectly consistent delegation
(NS RRsets from parent and child zone are identical), but still
have an instance of a lame delegation because one of the
delegated-to name servers answers non-authoritatively for the
zone in question.

I think the quoted definition at the top of this message more
precisely describes my perception of the term.  And, yes, I think
that you need to get a (non-authoritative) response in order to
say that the delegation of a given zone to a given name server is
lame.

Regards,

- Håvard