[DNSOP] Re: Disclosure of Negative Trust Anchors in DNS Responses (draft-farrokhi-dnsop-ede-nta-00)
Petr Špaček <pspacek@isc.org> Mon, 13 July 2026 14:24 UTC
Return-Path: <pspacek@isc.org>
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 EA8EA115DA7F2 for <dnsop@mail2.ietf.org>; Mon, 13 Jul 2026 07:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783952692; bh=yuJYIWPKDf/kFcMZviE6WTXyzMOYOsWBjv+gCYpqdIM=; h=Date:Subject:To:References:From:In-Reply-To; b=KBRcfYekN8XMQxSi9/ux7s1+eK46OY8tE0kKIhXrcrQOGMRTjlyU1F+Nd4cXGnuus AO8Ey2RCtHpMeRns4sN+TlLM4EINljNOQ0nVrNb8qFi2aB0rqWuc1Sm0qtuD1v4Psi Le0uMKbT4/iZ3y04vEefejk+ZfHu5HRnKsOjAr9o=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="ABw1aEFP"; dkim=pass (1024-bit key) header.d=isc.org header.b="WShBRDRR"
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 6yEHW1KdrfGz for <dnsop@mail2.ietf.org>; Mon, 13 Jul 2026 07:24:51 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 C334E115DA7ED for <dnsop@ietf.org>; Mon, 13 Jul 2026 07:24:51 -0700 (PDT)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (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) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 1DFBA4E40B1 for <dnsop@ietf.org>; Mon, 13 Jul 2026 14:24:51 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 1DFBA4E40B1
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1783952691; cv=none; b=pLdiyqnX9vkl1a/nut+c6HLwt0yvkQ2mfZXCspUPb8B+3z4kZ84uoD4EL4/UKUX/K3D/csCCaftPiW/kXfqgL3IMRq0qKjhkTQEr+opQGKW3W1+cXaPsI2EDN5Tmoo8SxbLdCb9bvXsUEKhpj9Q+CPFxJ+m5lWJ93DA1ADRPU88=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1783952691; c=relaxed/relaxed; bh=/cTqSkOwBAWTfppUmi/F4+YyyF+DPCQCh0/v5zdxVy4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=NvmMCZSMedBgL3SafFJb+ktGg/mWQiSalvPPRqex5dcMaybZ3AukG9vvmwS3BiRy+CtDLgkzDGPnedOcl8Q5PmAd8ybFr3CJcOClrwBRae6BRco52PPTnzliTRBkFX0VLk7eCw2PEm1Vw2tvqi9QcHgvGpQiKAMWMn5CDLA1k60=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 1DFBA4E40B1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1783952691; bh=yuJYIWPKDf/kFcMZviE6WTXyzMOYOsWBjv+gCYpqdIM=; h=Date:Subject:To:References:From:In-Reply-To; b=ABw1aEFPfg6W2nJ3Qm9ZTkvqUM5MOyBHRyrk3a7saOJLpj2fEP5Oy6xTbrPjI16du T5tkw6OxlJingBMMu6Odzo6xEnFCqY2ZeueoG88Dmwu/sBplRl1kEPHVOXtWkJqpsX XOBsNczB8t38aHeTXYpEhr+SOOBmRqwh28vk4WEo=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 180482E60120 for <dnsop@ietf.org>; Mon, 13 Jul 2026 14:24:51 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 152CC2E601AB for <dnsop@ietf.org>; Mon, 13 Jul 2026 14:24:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 152CC2E601AB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1783952691; bh=/cTqSkOwBAWTfppUmi/F4+YyyF+DPCQCh0/v5zdxVy4=; h=Message-ID:Date:MIME-Version:To:From; b=WShBRDRRt2VnxTZshauFpDL4pZoAu1Pn/Ci0HZ54moMqeJW9UVzqLKMFYYuK80tJJ stJwJn40MdMOIMSutTF1mjqbaLq0OoHrYO+Jwlh9BRNa6u1eYUE78D/ju3KDajXrvb VEY7AiMu4Lv60mF7yk5TlRPZ+bV83v92/5K7orvA=
Received: from [192.168.44.118] (78-80-19-161.customers.tmcz.cz [78.80.19.161]) by zimbra10.isc.org (Postfix) with ESMTPSA id 8E29C2E60120 for <dnsop@ietf.org>; Mon, 13 Jul 2026 14:24:50 +0000 (UTC)
Message-ID: <823a9c08-db41-4615-900a-44e89949f601@isc.org>
Date: Mon, 13 Jul 2026 16:24:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dnsop@ietf.org
References: <EE289631-0A69-47CA-A34A-093D22018B12@strandkip.nl> <52c9e65c-eef3-43b0-bbfc-000f4470e88b@isc.org>
Content-Language: en-US
From: Petr Špaček <pspacek@isc.org>
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmkt8P0FCQtoiX8ACgkQq9WHzfBlga4m OxAAhBZyC7vnxl3kjFPFRT39ocbZy1jJX4fiaJmiIgKma06c9Eled/w2IN9pzRc0+iI6jSQa 40NfHFV8g2KZfZUNEVE3BOliWdEFi61OcwxB/UeryGDJUFYfK4un7ibYv4Rzvrfpz13aQ0/z MVm2HA3OVwkTqnK+dJL//d3AmED66oJKUFXU9tG5kUGNqbVrZNSiegZXC/TloO0+eYYN63Fm EHvWE20NcgdciG4y/pdtBXcWSwt21tSeqiZqN5L8LvfAGmJ1gdi6p4eHvPEH1WSOqUEZmy5l +5BE6xA2z4bfNpCYSir6GwFTOQwxHeekLKJktgsLjYY8oHbmPjIIdEzkcV8dD8czJEPo0sqe VB4qTun8cCE4AkVofpo5MMwni/3DLlm9bgV8tKJ3sAqwo6bEWk8dU9QqlcwiYb5S1KPbWrwO 89cIJNLIu9rO3nemWFDwNq6mFuNdNWSDciLV434P5xZ0y5Xy09n5dGhCgYZTRv1JTLmXEO+H aw6iRgLNZmImYB0VpoPPHBjIavsY211qyLIwDRaUykELhGaBk7P1zKhC91ZD866CbR3x6ptv EuFuJ2myZT1dIalWiFf0HaVhrMHm8y8ih1sn9Ezdxnle7Hxyjgp//CtM92GCjU8iuqYQOzNq B9LWBU6NTtGx5Tktf2/Vin2ADqiiVN1EDOQd9tvOwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC aS3xCAUJC2iJigAKCRCr1YfN8GWBrgJJD/4oabL/T67M7GNPB1Q+1ghSpi3LJEwDqeaULNZv 2exo7N59cChW5DXD5e/rkvQM7yOsaKJBwkpjY2+vk4+Tw9iU1iqzS0iavr9A3i9mHJjlp4it u6oDBHCGMqBGZHHGP4O9xPuIoW6s50yP31NLbIGP4KGD03S1JtOBrETlTyr6a0mN4HrRnAkz nOa2l7npRvgkRpdr/vDmbAkyZYXcUCQSWsOKzRrcCrqRxzF7Ob39Xw+SrPv7hMBShzOVJCj6 XwOsu+F/hmRK5TML8+yZ+wGbrcTyxJ8qkKtwtDJXPMVY993f1k50/bquRdjX5wHTthvf6o9A 2cmZtbL0fVm2KEWNV3xDk52cJj7MqBk1M/mj1q8+6UzN9hTxN0N77u1sosgguW/8PWu/v2yy kUs2huxaqDkdrPc6kKuKbCGpkT5/89S6gvQSNx5IlVl0uWzJRat1h9HkdkO0CBYRX51Rv33W BF4qJ73o2dfrUchs70rher6734c21z8DUhDkvnPGIgLh4tYrYHNcM4akBTUt9k38xMGrj6yo kRjP6Pq9jhLwJBxxBRDEXn3vse8uy1s1sp9rhBxSS7bEHfmyz71h6ccALCFBlBzqfMediCAE 0PEMOPrXM0NU+o25vNC8BuWWpPf+fzvkLf+sEyYcIdwbHZ/V2qv97JvYX0FpMwmeyw4O2g==
In-Reply-To: <52c9e65c-eef3-43b0-bbfc-000f4470e88b@isc.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: AYDRBDBQLHSU253AAQIMJQWE4VJ6K5AG
X-Message-ID-Hash: AYDRBDBQLHSU253AAQIMJQWE4VJ6K5AG
X-MailFrom: pspacek@isc.org
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
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/a3gZOdwJan_YKszvKim6_JyRCZE>
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. 07. 26 16:20, Petr Špaček wrote: > On 17. 06. 26 12:47, Joe Abley wrote: >> Babak, Sebastiaan and I put pen to paper and came up with the following: >> >> https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ede-nta/ >> >> https://github.com/farrokhi/id-ede-nta (working copy) > > Good idea! > > In section 2: >> This EDE is intended for use in DNS responses sent by a DNS resolver >> with a configured NTA and SHOULD NOT be included in other responses. >> For example, a DNS response sent by an authoritative-only DNS server, >> which does not perform validation and hence has no obvious use for an >> NTA, SHOULD NOT include this EDE. > > Why not MUST NOT? > > I think an occurrence of SHOULD NOT should (see what I did there) have > an explanation under what conditions it can be violated, and I can't > think of any. > > > Personally I think machine parseable EXTRA-TEXT would be a good idea. > Something like > {"d": "example.com", "e": "2026-07-30T00:00:00Z"} > or so. > Urgh, I hit Send button too soon. Ad > 5. Security Considerations > Clients that require integrity protection of these signals should use an authenticated and encrypted transport between client and resolver, such as DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484]. See Section 6 of [RFC8914] for more discussion. Could we drop the encryption part? TSIG or SIG(0) is a fine integrity protection, too. No need to encrypt when it's not needed. -- Petr Špaček
- [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