[DNSOP] Re: Disclosure of Negative Trust Anchors in DNS Responses (draft-farrokhi-dnsop-ede-nta-00)
Joe Abley <jabley@strandkip.nl> Mon, 13 July 2026 15:20 UTC
Return-Path: <jabley@strandkip.nl>
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 6B538115E5A1C for <dnsop@mail2.ietf.org>; Mon, 13 Jul 2026 08:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783956020; bh=SjcypYAHRa8MEBfPsw55ul7gzgF8L9hjYIhqr6SsQMs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OBLb+obokA3h8mMGBVuKr1WoMiZ/Wo/L9RTfJEHKOniAtqnpzvAjQUL27z+xCxW4W vFANVj7F78JKxhaM8QPdjdfwajEffK1ug/5jb0NLEoNssFm7bdz85qPlY9ZYq5GZ2x EL/mEFH9aum0ZwRB2ksbJka6MipwV1LBmIIxoXKk=
X-Virus-Scanned: amavisd-new at ietf.org
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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 TWO__EEsY7sX for <dnsop@mail2.ietf.org>; Mon, 13 Jul 2026 08:20:19 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C01EA115E5A17 for <dnsop@ietf.org>; Mon, 13 Jul 2026 08:20:19 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.4.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4gzR2P2cpSz1FmY; Mon, 13 Jul 2026 15:20:13 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4gzR2P149dzkw; Mon, 13 Jul 2026 15:20:13 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=strandkip.nl header.i=@strandkip.nl header.a=rsa-sha256 header.s=soverin1 header.b=K5klSqVH; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1783956013; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QW3KmNCjcTfmr1Wyqkr0a2JvwPA6DX1p1ZhKl3jNQZY=; b=K5klSqVHg+NAQb/82fUgAniN3bDvx0upYq/2UcYA8EXIDNQ4839UmRzIZViFf4c++FBPBC OxlXASknWZ+fKPYmpQRKVYbZjcA4t5k9W0OZjiHrFcH3o2yFQ7q0S3Cii8DbKJeJwHrdXi bcR1m7VxZqyKCy7OLMMIndTtnl2vm2E3wJ1uDVoBsA5e54GFM3VaJFkOSIubgRc1/Zy7Cd WuD6R+GktD1e32hQJsyll0Dkik31mb9Au7AIyIjFq1weG/KxRzeVTRwEEosMq3vAXaJ7vj EJBiDqI0nPeyFcA4brMs8pdb6A4yZ01EMbE2zBn3gWzPnz3d/ca+4NQx/e3eFA==
X-CM-Envelope: MS4xfEPTmgAEEvk2oAk2ysawgNafdXH+TPCwAZqsJStapXrT1HHaE4eeXwEOu4/dL428NPUGHx3SOq4/SjH2Co/IzIPsH4ZgfkNB8Ys2IZ2bothjx+meLDj9 0pP1P948Oc17dGsbJ5oMKRkZ3HcnGsDETG19Cmf/LGhWsIjWKj3smkYVkSRovntkYb+UabHB1Hht5pR+xD67nHgVaPvxQTgTvJR9yNhUyaIbWhbeqHd0vhk3 QBiChqx7UmYb2gMKhLgI0tm5oWJ2Vv2JXMUAu0VKlpU=
X-Soverin-Id: 019f5c10-7fc8-7a3c-b6c0-ea2c74b89848
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.8\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <f49b395f-a474-45ab-b3e8-164e5602a174@isc.org>
Date: Mon, 13 Jul 2026 17:20:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D2BBA54-0397-4F44-81ED-FEC9C22587B1@strandkip.nl>
References: <52c9e65c-eef3-43b0-bbfc-000f4470e88b@isc.org> <4EAFAC7E-4210-4CC1-BC43-3D9248A4F903@strandkip.nl> <f49b395f-a474-45ab-b3e8-164e5602a174@isc.org>
To: Petr Špaček <pspacek@isc.org>
X-Spampanel-Class: ham
Message-ID-Hash: XQ3MO3LK22YJZLNMFVGW52M3FK4CDEMC
X-Message-ID-Hash: XQ3MO3LK22YJZLNMFVGW52M3FK4CDEMC
X-MailFrom: jabley@strandkip.nl
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: Disclosure of Negative Trust Anchors in DNS Responses (draft-farrokhi-dnsop-ede-nta-00)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nRnmbqUgQjF_B_hwVV7DNxwUwUs>
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 13 Jul 2026, at 16:51, Petr Špaček <pspacek@isc.org> wrote: >> If there was a really good use case for machine-parsing the information in the EXTRA-TEXT perhaps that would be convincing, but I can't really think of one. > > For this specific case, say a diagnostic tool tools might provide detail than 'AD=0, some NTA somewhere in effect'. > > Instead if might say something like ... Answer > wwww.example.com CNAME 1234.cdn.example > 1234.cdn.example HTTPS ... > has AD=0 because NTA is activa at cdn.example.com. > > And this can be in French because the tool could ingest the EDE + domain name in structured form and provide localized output. > > Or the research stats could actually be made more reliable than hand-written regexes. Mmmmmmm. I sense this is a can of worms, but perhaps that's just because you mentioned human languages, which as we know are a gateway drug for talking about scripts. The implementation we have live at Cloudflare does not mention the particular NTA that is in place. So for example the following example is less helpful than you had hoped for: jabley@manta ~ % dig @1.1.1.1 ntamuch.org soa ; <<>> DiG 9.20.24 <<>> @1.1.1.1 ntamuch.org soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 33: (a Negative Trust Anchor has been applied for this query (see RFC 7646)) ;; QUESTION SECTION: ;ntamuch.org. IN SOA ;; ANSWER SECTION: ntamuch.org. 1800 IN SOA barbara.ns.cloudflare.com. dns.cloudflare.com. 2407706086 10000 2400 604800 1800 ;; Query time: 24 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon Jul 13 17:11:49 CEST 2026 ;; MSG SIZE rcvd: 181 jabley@manta ~ % You can't tell from that response that the NTA is applied to the NTAMUCH.ORG zone (which is what is going on) or whether there's some other NTA installed at ORG (there isn't). Or maybe there could be NTAs installed at both for different reasons. Maybe that response could have been validated and would have been fine. All you know is that you have received a response for a name that is covered by an NTA. I appreciate other implementations might return different information in there, including more helpful detail of the kind you suggest. I think there's some benefit in not over-specifying the message format, though. I don't know that it's reasonable to anticipate every element of data that anybody might want to see, or even to propose an optional schema if it turns out it doesn't suit some implementations. The core goal with this was to give the system receiving a response that normally would have been suppressed due to validation some clue as to what is happening. I don't actually think we need any EXTRA-TEXT for that. I'm interested to hear from others what they think about this. Babak and I will also be in Vienna and I think we're on one of the dnsop agendas, so maybe this is also a good question for the mic line. Joe
- [DNSOP] Disclosure of Negative Trust Anchors in D… Joe Abley
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Carlos Horowicz
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Robert Edmonds
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Carlos Horowicz
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Mukund Sivaraman
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Mukund Sivaraman
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Ralf Weber
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Warren Kumari
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Petr Špaček
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Petr Špaček
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Joe Abley
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Joe Abley
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Petr Špaček
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Joe Abley
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Mukund Sivaraman
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Joe Abley
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Mukund Sivaraman
- [DNSOP] Re: Disclosure of Negative Trust Anchors … Mukund Sivaraman