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

Shumon Huque <shuque@gmail.com> Thu, 29 July 2021 20:32 UTC

Return-Path: <shuque@gmail.com>
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 9F9813A09BB for <dnsop@ietfa.amsl.com>; Thu, 29 Jul 2021 13:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuNUdisDlH-c for <dnsop@ietfa.amsl.com>; Thu, 29 Jul 2021 13:32:26 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78E53A09BA for <dnsop@ietf.org>; Thu, 29 Jul 2021 13:32:25 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id ec13so9371515edb.0 for <dnsop@ietf.org>; Thu, 29 Jul 2021 13:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAHPuVdV6s1wM6Qc3uAhRQurVg2mMocRCTPmpVHHkBHW9FWV5Cg@mail.gmail.com> <41460fa425b4a7ac495b5d73cc1718dc3e3f1cec.camel@powerdns.com>
In-Reply-To: <41460fa425b4a7ac495b5d73cc1718dc3e3f1cec.camel@powerdns.com>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 29 Jul 2021 16:32:12 -0400
Message-ID: <CAHPuVdVG-89QZbRmk3bXvbzKwNCB=WCJj_Kqs9i8jQhbySyDNA@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c1b3405c84900ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I8xqYo7ItI2fV4Y7HGpU1_19Iqw>
Subject: Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 29 Jul 2021 20:32:31 -0000

On Thu, Jul 29, 2021 at 2:29 PM Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> >
> >                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! :)

Shumon.