Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies

Shumon Huque <> Thu, 29 July 2021 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F9813A09BB for <>; Thu, 29 Jul 2021 13:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fuNUdisDlH-c for <>; Thu, 29 Jul 2021 13:32:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B78E53A09BA for <>; Thu, 29 Jul 2021 13:32:25 -0700 (PDT)
Received: by with SMTP id ec13so9371515edb.0 for <>; Thu, 29 Jul 2021 13:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SzAgyQm4sNdfs8j7ddAtVq+KzQmYDrRJsB2K68OdXL4=; b=BNkhPF0/2c1njfUWfKSfp+k7A/4cZPzpWthEvOrOYmZa9bzFb17ntlYz/7OIMw6eQ3 3ombC+mw7y6vVKGqHx/yxCqLF30StPwy94X61LXE349IRQ5KCaSahWvi0MSEXw/ifAyW gpbgFTPCcz7//3CePcP82RcJbqNgLbgy4oXxf6V3dLW5cF+DElN223Y6XkXkzet48ReD oynTspLCqQwQuEnc1ffxpoA51sR1PBvl3DCPL7e1r6EmSKQ8BxlPWxngce7ngr6CyJmS 6ZW7fRYqdvIGhqmVWaG36opG4w+QZ9KoXaDUPInM+cdKDQBTANU2Z4eu5XqoEUDQ9rmm EP/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SzAgyQm4sNdfs8j7ddAtVq+KzQmYDrRJsB2K68OdXL4=; b=jKFEJ6wJxYA+lZtSGICi+5CXrf55K3JhyEU5RXi3N+HGWGwDFj5RJ+1CO6Dk9bCmLX g2RyAk900Qp5NItQ4SWTqu6BEu1806wSpsu3ybkS9K1N/kid2A3zJguZCdnhsVt4ML4P hwotGf4HGCL81lzqqVfvzlSew7eggrk07H5Oh9CK4zci+eBSjmTDL/yqXt04T7XxPnTs cFbkZ8rWtKwLUqxG9ppvbBz/QiUdjeVcJP/xM6l+fQey2w+zUi/bOu2ct0gYTl1TQvhA wu70o9En3xMMwbg7qVQJAk8X2K0HTjZse9jzKjJXLWiVZtXjYdGl2MhP5ggOAi2Xgoby J5cQ==
X-Gm-Message-State: AOAM5336ktAVmsn4DEti0quo3gShTHwSaQQRCTBva/24gi66/SP3Tc/T oXKt8vqI1fo7MJ3G4uOEskOtg3bKz7cqIQ7mgf0=
X-Google-Smtp-Source: ABdhPJztC66wTd5lCXZj6eeWWddhzCd2QubKA3A1BENWwqXNfddqb6X62LB+fj5wroj6n7+mwgGZd8FmB39WQUO9fYk=
X-Received: by 2002:a05:6402:5250:: with SMTP id t16mr8058047edd.317.1627590743561; Thu, 29 Jul 2021 13:32:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Thu, 29 Jul 2021 16:32:12 -0400
Message-ID: <>
To: Peter van Dijk <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000001c1b3405c84900ef"
Archived-At: <>
Subject: Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jul 2021 20:32:31 -0000

On Thu, Jul 29, 2021 at 2:29 PM Peter van Dijk <>

> >
> >                Empty Non-Terminal Sentinel for Black Lies
> >
> > Abstract
> >
> >    The Black Lies method of providing compact DNSSEC denial of existence
> >    proofs has some operational implications.  Depending on the specific
> >    implementation, it may provide no way to reliably distinguish Empty
> >    Non-Terminal names from names that actually do not exist.  This draft
> >    describes the use of a synthetic DNS resource record type to act as
> >    an explicit signal for Empty Non-Terminal names and which is conveyed
> >    in an NSEC type bitmap.
> I have read the draft, and I believe I understand what the draft is doing.
> I have also read the Introduction and Motivation section. While it does
> contain some motivation, I do not think it contains enough motivation. One
> might argue that ENT/NXDOMAIN problems do not exist with these operators,
> precisely because they do Black Lies.
> Furthermore, it looks like a trick that could only be relied on with
> specific operators (such as, for now, NS1) that have implemented it. There
> are plenty of differences between the implementations already. In fact,
> when promoting RFC8482, CloudFlare heavily argued how the difference
> between NODATA and NXDOMAIN is a very expensive one for them. So
> presumably, it would not make sense for them to implement this signal.
> Because of that, I wonder if it would not make more sense if the individual
> implementers/operators of things that are somewhat similar under the 'Black
> Lies'-umbrella document how they signal the difference between ENT and
> NXDOMAIN. (It would of course be fine if some of them agree on the signal).

Hi Peter,

Yes, Cloudflare is a bit different than the other 2 implementations - they
did not exactly follow the spec as described in the expired ID (presumably
for the reason you mention, although I don't know enough about their
implementation to know why it's hard for them). For any NODATA, including
ENT they return a NSEC bitmap that contains every (~ 20) RR type they
support except for the queried type. I mention this in the draft. So, they
effectively avoid the NXDOMAIN/ENT distinguishability problem that way.

I also hope, but want to say that out loud here, that there is no expection
> of -resolver- software to handle this signal in any special way.

Confirmed! :)