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

Warren Kumari <> Tue, 02 May 2023 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C05E3C15152E for <>; Tue, 2 May 2023 12:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Status: No, score=-7.095 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qKqIKz7TWLB4 for <>; Tue, 2 May 2023 12:32:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id A372AC151524 for <>; Tue, 2 May 2023 12:32:31 -0700 (PDT)
Received: by with SMTP id d75a77b69052e-3ef657f5702so45347261cf.3 for <>; Tue, 02 May 2023 12:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1683055950; x=1685647950; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AABYU94R8usoA047XyKA3XIG6D7AYyKdrXUUK0RrpC8=; b=RD+6dC8w1I3IElvbkChN9mgG5Qq/04wNFHQpRGB5U95K1oJMmEzjiFSVAU8Bik+unN rRU63Zecwv9oP7v8RaQ3JfnmyRAMGkl+8YWuTwBJdP4VDr9+UJVr2NJBjWKmS4gvFxSp FRqIKbD35uosHWTNTWoh5zjYzFrEgLk4UGr+ixVz086zg/EuvdjpDFGd6XuGz5pi1dl1 RcpYTljyF1EgkHzKzNdtMMgvlTqfYQ6Ll1AVtebniSpdxGqhX3MSwKQZlCYV/xCAuBzM 2SLuTU7UrCpISt++RU+I/Js4dcWSxYaMKMQTn58lVF3H22b7Oj30Tk5exfpn4romVq+W nsIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683055950; x=1685647950; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AABYU94R8usoA047XyKA3XIG6D7AYyKdrXUUK0RrpC8=; b=TjBlI1cXp8FeChjcRIQd+uBCQYtT8tYnqF1FC2kc2kOpW4dULLAVDSsoMOGCZUthY+ KBVuZedwsQtobsZguYt0GnxpsyHnMvEbWKP4T4oh95Hs23NsYILnOo1OY8G+QBYihOBy 2NwO/9b0X3T4xk9aBz1sGL9RRrVEU4k6lLBv1OcYpwskFbUdwWSL+2Qln5xfK5H9hxTe DoEGtCDBfun5ZAw55D90aeIW3w6KmDXPZBvsR73IJMB7Qfx6ASnlNH089e9di/WGX25X t1R8FcTQzabBX44ghKoe8jaF8ezKAJajt5I/zBNhYQG2XUcZ2v7sRyqRl92QMsU8VGCR qUrA==
X-Gm-Message-State: AC+VfDy74UVJfVxIzPzCXgTCktwhmJlbr36fjSULzlnvz/WMDbc3DMPr iCXNfmwi3FGhdqb6HB8qYJq9QKf157vCnqIT5GZhAXVk/Gy+smMn
X-Google-Smtp-Source: ACHHUZ6azFnPyAj+/OX1TjftpcOGWlvzvXqsbZepUBohjCJF6KyBCUDS8EXEBHxvf0B8HVTRtsmKS87mtUzbUaJoy7A=
X-Received: by 2002:a05:622a:12:b0:3e3:712d:8be2 with SMTP id x18-20020a05622a001200b003e3712d8be2mr15855555qtw.10.1683055950371; Tue, 02 May 2023 12:32:30 -0700 (PDT)
Received: from 649336022844 named unknown by with HTTPREST; Tue, 2 May 2023 14:32:29 -0500
Mime-Version: 1.0
X-Superhuman-ID: lh6o1ltz.6281453c-00e6-451b-9c7b-14f3c644de2d
X-Mailer: Superhuman Desktop (2023-05-02T01:54:51Z)
X-Superhuman-Draft-ID: draft0082efcd603aba27
In-Reply-To: <>
References: <> <> <> <ZFD/> <> <> <> <> <>
From: Warren Kumari <>
Date: Tue, 02 May 2023 14:32:29 -0500
Message-ID: <>
To: Peter Thomassen <>
Cc: Joe Abley <>,
Content-Type: multipart/alternative; boundary="0000000000000f30e105fabb0071"
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 19:32:35 -0000

On Tue, May 02, 2023 at 12:14 PM, Peter Thomassen <> wrote:

> On 5/2/23 17:52, Joe Abley wrote:
> On Tue, May 2, 2023 at 11:09, Peter Thomassen < <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.
> Sure, but to compare to the delegation's NS RRset (as Paul was arguing),
> you'll have to ask the authoritative nameserver for the NS RRset, in which
> case the response should contain that RRset and the AA bit.
> Paul said that even if the AA bit was missing, that would not be lame, as
> long as the RDATA agree. I was trying to say that if the child's answer is
> indeed non-authoritative, that's not a proper situation because the two
> servers make conflicting authority claims.

Perhaps, but it *is* quite common (or, at least used to be quite common, I
haven't checked stats recently). A surprising number of people put some
sort of load-balancer in front of their authorative servers. These would
basically just be recursive servers which were only[0] willing to recurse
for a specific set of zones, or would do some sort of funky GSLB type
behavior, or were "DNS firewalls"(!). These often would skip setting the AA
bit, because they were, you know, not actually authorative.

What the parent and the child nameserver say w.r.t. the NS hosts' authority
> is not identical; as a result, I would call it lame. (Apologies for the
> loose wording in my earlier post; I really should be more careful.)

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?

Flipped around: My parent says that the NS for are, *and* I ( say
that my NS are only and If you query, you get REFUSED. In that case I'd (personally) say that is lame for I don't think that I'd call "lame", as both ns1 and ns2 work OK.

Note that both of these fail your parent and child need to be identical

> Another case would be where the name server responds with REFUSED, which,
> depending on the reader's DNS expertise, could be construed as a "answering
> non-authoritatively", although it's not answer (only a response). Is this
> meant to be included in the "lame" definition?

I think so.

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.

This means that a server can be lame for a domain, or that "all of the
servers in a delegation can be lame", which I'd personally often just call
"a lame delegation".

> (It is not clear whether the verb "answering" is meant to require the
> presence of answer RRs, but I suppose so. Further, the distinction between
> "answer" and "response" may not be obvious to someone reading about "lame
> delegations" when debugging an issue, so it may be worth clarifying what's
> meant, e.g. by referring to the RCODE.)

Yah! I think that (personal view) the important bit is that a
(non-recursive) query is hitting a server which cannot provide a meaningful
answer, either because it doesn't have the zone configured, or perhaps
because there are "views" which hide that zone from that query address.

I'll note that this is often not the nameservers fault - as an example,
there are many  domains which are pointed at e.g which has no idea about. This isn't it's fault - people just seem
to include it in their NS set for some reason ¯\_(ツ)_/¯.


> Best,
> Peter
> _______________________________________________
> DNSOP mailing list