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

Warren Kumari <> Wed, 03 May 2023 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D39DC14CE47 for <>; Tue, 2 May 2023 18:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rh_Kv2e35N_k for <>; Tue, 2 May 2023 18:26:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (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 92000C14CE45 for <>; Tue, 2 May 2023 18:26:34 -0700 (PDT)
Received: by with SMTP id af79cd13be357-74d765f2180so426237685a.1 for <>; Tue, 02 May 2023 18:26:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1683077193; x=1685669193; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UWU2+VS4INtfN3RjO9XrHpZmRK1Dh7zle9vYNpbdJso=; b=QrNkEO+415ZgKazpZDIXYlepQffQm+YxeOnp8w1VGWW38pC0+AboIkECRyG/5OLdiI wIVx9Q0/d0OVJTefun4NnNSeHSIPjYeugiyQfO/dOm1WRauJTKC0/HZfKNxV1x8+aige OPYXTP6Crzod3wupJXwbAFFUhjJYe9oIClq6ixSVeXd16fDihdk2BPghxeo3C9YyOmSm EVCapVsMP1Gq8lQfLK9yEY9SdZV7MYZIbwgEqPUjxwXULQHDJPm3YEmoAaprfCR8Fwmz hfDPjQLqaZAbWjHefNQlKBdt7jzNHQJWtLUV5uTqrtUp6Wr5DkAr1R3dNXGu8oR6aU+F egkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683077193; x=1685669193; 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=UWU2+VS4INtfN3RjO9XrHpZmRK1Dh7zle9vYNpbdJso=; b=DMO3Ty3rWVH9bPpZOuVPv59sf/0RNyrEIs2JjkeQdRdqiM+TXjzNQL/2pUlHUEMKUS rDfimfcSmy8IJ0or71AwBfmlDBj6QrH8fbJh0TleByW3+X1R4P30Xr2dhS4hTj35Wqyn 7+HwFybqMdlun836V6nO62efLbBC8YMpvcKFYDaSejIF3i602CyPrvwZYyhB1PWIc7NV E4Px6BUIULRUR6pGNA9xJuiBuGqfz+PSnSSPQoRzd2E7nB3gaurbO5CssQ2L6u3rJW5c CO7KK/lHbBgu3HfyQiMJSu2op9yTKKC5COCQkaA6BCXY3EINwNtQqUZ2JlVUUPOSne5m 4Ylg==
X-Gm-Message-State: AC+VfDzRRDRmqyMRorFlx/AeKqUS9c1wF7sNyB2hhT3PZ76BC9CinIbJ 4gPJfycQCtC2swUVjZpPGWeiPeGbvgL9eFKDD0IYWLc4f1W5pg4p
X-Google-Smtp-Source: ACHHUZ6xit0qy3Ek9aQJJepnaZbjbquTRw3d73XxspN8Uo9okAPCROFA+xYeVtLaAi0TU4ie0KYHWT4ewxa+z04iHOc=
X-Received: by 2002:ac8:5f14:0:b0:3e3:9958:5fe8 with SMTP id x20-20020ac85f14000000b003e399585fe8mr26958545qta.42.1683077192946; Tue, 02 May 2023 18:26:32 -0700 (PDT)
Received: from 649336022844 named unknown by with HTTPREST; Tue, 2 May 2023 20:26:32 -0500
Mime-Version: 1.0
X-Superhuman-Draft-ID: draft00cc1307c7dfae80
In-Reply-To: <>
References: <> <> <> <>
From: Warren Kumari <>
X-Mailer: Superhuman Desktop (2023-05-02T01:54:51Z)
X-Superhuman-ID: lh70ox7v.8aee536e-741a-4743-9cd9-809adfacaa4e
Date: Tue, 02 May 2023 20:26:32 -0500
Message-ID: <>
To: Havard Eidnes <>
Content-Type: multipart/alternative; boundary="000000000000372b4905fabff2e6"
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: Wed, 03 May 2023 01:26:39 -0000

On Tue, May 02, 2023 at 7:43 PM, Havard Eidnes <> wrote:

> My parent says that the NS for are, ns2.
> , but I ( say that my NS are, ns2.
> *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 ns1.example.
> com, *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
> "lame".
> 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.

Well, perhaps - but it *is* a common deployment scenario.

Many companies use ACLs and views (or similar) to expose something like, but only to "internal" IP addresses[0]. It's obviously
easier to just have one set of nameservers, so if you query e.g www. from the global Internet you get an address, but if you query
e.g you get REFUSED.
I slight variation on this is if the servers for *do* answer
the public Internet, but have a delegation to other servers which handle
the zone, and these only answer queries from "inside" the

[0]: Obviously you can't let just anyone on the Internets know that you
have a server called e.g with the IP address of, because, um… well… erm.. no-one has ever really been able to
explain the threat model to me, but they are all *sure* that the sky will
fall if attackers know this… Often there is some allusion to "well, it may
leak that we working on a magic hovercraft product, because they'd see a
device called
<>… ¯\_(ツ)_/¯

> Best,
> - Håvard