[DNSOP] Re: How black are black lies, really?
Shumon Huque <shuque@gmail.com> Sat, 13 June 2026 12:32 UTC
Return-Path: <shuque@gmail.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AFD75100B20B2 for <dnsop@mail2.ietf.org>; Sat, 13 Jun 2026 05:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781353967; bh=knW3K5PtH83RyzsHQz0TpLGhph2A2gucTPKbzSaE8Oo=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=kJtNzhY1OuG88G6ox9J3v7Cz++zAC9ggE2xpaiuSDsZ3xItK0zbOtRrsIeG+6umpp QUP3qKwkjOD0q2SMkif2zHBUNfOQY1NC2vPs5nLVgnjJg7rVDnb2Io148tXFinsLxS coR2n7cvv2LMcK+B24lTVdRJCzFJwGEYxPjSVQSg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4kaqdH3O3Q6 for <dnsop@mail2.ietf.org>; Sat, 13 Jun 2026 05:32:47 -0700 (PDT)
Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 551E9100B20AD for <dnsop@ietf.org>; Sat, 13 Jun 2026 05:32:47 -0700 (PDT)
Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-69de9bc590aso1441923eaf.1 for <dnsop@ietf.org>; Sat, 13 Jun 2026 05:32:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1781353967; cv=none; d=google.com; s=arc-20240605; b=cigWQ6R29ooRMBlHUoO+1QgTuVe563Rre7PMQwDw7UjdS3u5Nt0hGkejV6RqdMPst0 pCN/ajwmxVQdx0E/s8ueV/+cPlHzaj2aJ00WZ+Hh4jixdkZv2oBKL7TIjm1a4HE76J+5 kVpljutL2NVGmBzGBWz3Oi5oDPeLB80vB/MkrooMURBPmfKejjyXrbJ2brX/0QiTZt/G X7gyTsQiC7ISmy3/qWbIlLT4neF/RWiZyNfrZdcWVN5/x/zKi8YZMdjSX9SgxEa3ByPU wQ8ED/VOF0SwNsjjybI8HUQTjhtAT79bz1Go7OUY/M15ofp18b9ZVWX46nxKY1LNjdLU HnNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=0xCxAW4JUBKdLnS/YG3zvAjGMbEHkoHbgkrxxHQegec=; fh=tme6P/VFwlgx4Hd6k1p9Uh+vJdy+DhLjYji0AGBYF/c=; b=AM1o/xTl/WKVLjAhm85SEHAlwyaqeasxF4MQJFt15loOktIOx3YBMqaZKNbf61arBp 3ns0ovqbbhkpRyYf/iH+A3I6ZQVIm0yZ1ZpMX5zFhMssLeWqja8O0Scmz7zDHlOjJIMd vCoqB0HTcii0y4Nu/nvv5H+d4nG5KKHY0VgvkzFHOc3+xE8Dv+7+PIXB9cfaQwoC5D8D MIFFSJcr5keegpGYf153FTQMPESYZvWfPPTsna6Y85yYNtoCnVauNTFWm9XP5C9iAGDw uhz8bdrPe1A/pUQLoCpFRxVysGGA+xbi/NNpX+9kZE3ietNfpn/7Pj4id86fuG/FW3YD YDXw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781353967; x=1781958767; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0xCxAW4JUBKdLnS/YG3zvAjGMbEHkoHbgkrxxHQegec=; b=qegBuk9KFCq7mWiqK3vLA8vakCzrYVYA6pkm0SauLmKvwJoqR6yfvRjicR9XVG9PJH ZjQ2aN7EHClZoUtKnyNspGQT0wRoysicLa6byBTg3HJ/PtTR8SSKpP2EZPPQnSgeLUqu rKw3vpTNz3DQYqgsFN00yVcRFKvPXh9AaJVNSYdnx//OtUMUktJ5kAm1OjzcwcFHGKoC kfttOQq0thPLzGJzWAl//lMsp73OhF6OmrDqYTCKsvUWEJ1oAG1zTkPe2nLRyIl42Kr9 Q+e9HeaBBtHG1+dy1aCOuG+mN1RktRNhLTM2oXg1IkcviPYr+NMEzrMzQMvKymQA08aN /+7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781353967; x=1781958767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0xCxAW4JUBKdLnS/YG3zvAjGMbEHkoHbgkrxxHQegec=; b=f0N8hrv/6q6ye6FhfeNC481LZTikdzNTU3ZbLXOms96jhhcuGfTKhePqr2n6Cpgwx0 I3tZaqQsZUP++lieeQkhH6CYY3jhGVUFYDkEvAgZ7B+qlL9N+qPjmLarF35QyrGXGoOr RhN79uQMlkA9EJbHpD+osXMY7bZyF1rA6U4UNDGfMPr6nNKPBnY05mlf9Ao08HucfoLT 7De88JDAyqtRmkWeADNKIBTzKSEdvMfQ6xF/zfWp51SLAe6aYTGGJGe+DgfK3I9vGMFr 1Aqr5yF+VAN/mU4ChqUixNvUUzwuaWappO3vsbyN03jlKAbNpjqKcQYZwCvtYoQg/zyG 6RMQ==
X-Gm-Message-State: AOJu0YwbF5ynZwiL4owmsT6MH1vlHEdUt04YMieSpwsB92cvt5swL9zD zhg8HUKvr36O0sRcuOXuYoVu3pXlDfLG6F0mI3ANXjgy7IV9js+fppXg0+Zhi1hZflO0swArGoP vPw8dd2m0kKmazuK0soPEKmMwDyi9jCs=
X-Gm-Gg: Acq92OFDIzV0KRNbVmeeVso/BmpVYYsLtdLZUj02CKtr/2PZ2J6M1GL9Vdr92XRSl70 aBfZZiFqR3HTiSykyOGfVaYwO6IfFUsZg1Lp4IVPUFYMBJ7alXmU1H75uxmQioKN1XH1EisbCrs r9Sw8JYrHCRg8WdxdctmJF45PqJdV3IlulQdq/G71b0fwQv6pNqCnA0vjInT393EqrAj+4Sa+7S UKaix3XC9Fq/xH7fUFWT0YSMYOtVm1Pjzh9lZAJMY/NuqzyfLIcG9Y8+BSB35GV/yhUW2eAa4/y WA9y/zw=
X-Received: by 2002:a4a:ee1a:0:b0:69e:42ee:40d with SMTP id 006d021491bc7-69edc7a9654mr4247734eaf.55.1781353966709; Sat, 13 Jun 2026 05:32:46 -0700 (PDT)
MIME-Version: 1.0
References: <e181523b-3651-5812-a5b2-a44bbc89c02f@ietf.email>
In-Reply-To: <e181523b-3651-5812-a5b2-a44bbc89c02f@ietf.email>
From: Shumon Huque <shuque@gmail.com>
Date: Sat, 13 Jun 2026 08:32:35 -0400
X-Gm-Features: AVVi8Cc36N4VF79fvWdnu3KNsAYl5O57TUauAZjki4lS8pmdyJkegSG1EAc8_iw
Message-ID: <CAHPuVdXa3N3Ev44z+-xRfdBFS04j8iJF-EtFY=axVMbmRk03BQ@mail.gmail.com>
To: John R Levine <johnl@ietf.email>
Content-Type: multipart/alternative; boundary="00000000000067b2b6065421ca64"
Message-ID-Hash: 6RLZ4TDLFJYTCKHBHCP6GPTSRUNWHJ5V
X-Message-ID-Hash: 6RLZ4TDLFJYTCKHBHCP6GPTSRUNWHJ5V
X-MailFrom: shuque@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: How black are black lies, really?
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EvoLurRNR8wQSc5J7ceduBvv2Mc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
On Fri, Jun 12, 2026 at 11:42 PM John R Levine <johnl@ietf.email> wrote: > RFC 9824 on Compact Denial of Existence in DNSSEC says how to generate > miniallly covering DNSSEC signatures on the fly which works great so long > as the name exists. If it doesn't, we invented the NXNAME psedudo-RRtype > as a flag to say this response is really an NXDOMAIN. Section 5 describes > that and encourages resolvers to return a real NXDOMAIN. > > Over in another working group I got an proposed errata for RFC9989 saying > that where it says applications check for NXDOMAIN, they also have to > check for NXNAME, for resolvers that don't recover the NXDOMAIN. I > rejected it but he insists claiming that (approximately) the resolvers > he's seen don't actually recover NXDOMAIN. > Yes, this is largely true today. The NXDOMAIN restoration feature isn't implemented by any mainstream resolver that I'm aware of. From private communication, I know that a couple of them plan to implement it in the future, or are contemplating it. It seems to me that's a bug in the resolver, that's the whole point of the > CO flag and NXNAME. The alternative is to file a similar erratum on every > RFC that mentions NXDOMAIN. What do you think? > That depends on your point of view. Remember, that there was significant controversy about this mechanism when it was first deployed in the field due to the unilateral disappearance of the NXDOMAIN signal. The IETF work recovered that signal in an alternative way with the NXNAME pseudo type, which can be implemented entirely on the side of the authoritative servers that have implemented RFC9824. Restoring the NXDOMAIN type code value into the actual response code field requires the additional active cooperation of the resolver (to set the CO EDNS header flag and perform attendant processing). And some resolver operators were adamant that they were not going to make any changes to their code to accommodate 9824, so this part of the spec had to remain optional. As a practical matter, that means (at least today) if applications need to conclusively determine non-existence of a domain name at zones that implement Compact Denial of Existence, they will need to examine the NXNAME signal. (We have several specialized inhouse applications that already do this). Shumon.
- [DNSOP] How black are black lies, really? John R Levine
- [DNSOP] Re: How black are black lies, really? Shumon Huque
- [DNSOP] Re: How black are black lies, really? 左鹏
- [DNSOP] Re: How black are black lies, really? Ẹnitàn
- [DNSOP] Re: How black are black lies, really? Petr Špaček
- [DNSOP] Re: How black are black lies, really? John Levine
- [DNSOP] Re: How black are black lies, really? Olafur Gudmundsson
- [DNSOP] Re: How black are black lies, really? Olafur Gudmundsson
- [DNSOP] Re: How black are black lies, really? John R Levine
- [DNSOP] Re: How black are black lies, really? Max Hearnden
- [DNSOP] Re: How black are black lies, really? Olafur Gudmundsson
- [DNSOP] Re: How black are black lies, really? Shumon Huque