IETF Logo Mail Archive

[DNSOP] Re: Synchronizing caches of DNS resolvers ("poisonlicious" draft)

Bill Woodcock <woody@pch.net> Tue, 28 July 2026 09:18 UTC

Return-Path: <woody@pch.net>
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 584A411FB08BB for <dnsop@mail2.ietf.org>; Tue, 28 Jul 2026 02:18:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785230321; bh=pBOlaO1JTwcXKHdD8hcXQ1R+3sudeV2lfbIlSe9Cz+I=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WL3aq2MNFvRYs/XvHGaQlNmnFgCNuELZGk3sXF2qZo265NH6YHUF3b8AMEVI5j8dn QA/AzmAeBIk+3ZNGl2ex2IZksiN9u0C70sxt55it8NwVQhlkXDb5q5KNRppQvlqRVh kMtBQjij0Q534v21Si5KuOtZWo7Tm/Rinq0w3hjc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=pch.net
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 VHdu3HexPlCo for <dnsop@mail2.ietf.org>; Tue, 28 Jul 2026 02:18:41 -0700 (PDT)
Received: from secmail.pch.net (secmail.pch.net [206.220.231.87]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id CF6FD11FB08B3 for <dnsop@ietf.org>; Tue, 28 Jul 2026 02:18:40 -0700 (PDT)
Received: from secmail.pch.net (localhost [127.0.0.1]) by secmail.pch.net (Postfix) with ESMTP id 4h8VJB5cBJz4xsxd for <dnsop@ietf.org>; Tue, 28 Jul 2026 02:18:34 -0700 (PDT)
Authentication-Results: secmail.pch.net (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=pch.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pch.net; h= x-mailer:to:references:message-id:date:in-reply-to:from:subject :mime-version:content-type; s=secmail_dkim; t=1785230313; x= 1787822314; bh=pBOlaO1JTwcXKHdD8hcXQ1R+3sudeV2lfbIlSe9Cz+I=; b=k /8WepVYeXy+aFU5D/6Kw18oznDwovidHC6d0LiEw7Nv/JUCw4o6Qrm0v9rISPl/s 4mEUo5/TT37hx4nhHIaRUSoYi3gLqgWO+JSlmH3ZweBlhX27/TPV2rMdUAStdjZb RJj8VTMto0NZ+xiS4JWwxB/EYeWsM3r0dxejShGntXpCirGMzOKJQQKcNzrCXZvq b+EMaKpEpP6MzQc2MqIOVBPe17yf0uQsUGxI0NYMz1KYV8CVp16VdtAU4VakLETO qU8VmHJIhC1Sxi94fXB0qR8c9lCTOv1tkSz/MgL7SF8jxAuPT7RYq4Xymbupt1fa rd4SoGjxDNBk+chk9u2xw==
X-Virus-Scanned: amavisd-new at secmail.pch.net
Received: from secmail.pch.net ([127.0.0.1]) by secmail.pch.net (secmail.pch.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jsW9rKGQPbZx for <dnsop@ietf.org>; Tue, 28 Jul 2026 02:18:33 -0700 (PDT)
Received: from smtpclient.apple (unknown [66.185.123.190]) by secmail.pch.net (Postfix) with ESMTPSA id 4h8VJ80jcFz4xrW2; Tue, 28 Jul 2026 02:18:31 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_614EECCE-D9BE-4ED4-AE47-A5A1ACC98D58"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
From: Bill Woodcock <woody@pch.net>
In-Reply-To: <90CED010-D268-45C6-973D-8791FDB6ACCB@sury.org>
Date: Tue, 28 Jul 2026 15:03:26 +0545
Message-Id: <80CF436A-843D-44C5-AFAA-A1C3AE5DAC21@pch.net>
References: <al4QKxmXzVPfghm9@nic.fr> <C7BA4A7F-4EB8-48B8-A45E-3CCF33F209B0@pch.net> <90CED010-D268-45C6-973D-8791FDB6ACCB@sury.org>
To: Ondřej Surý <ondrej@sury.org>
X-Mailer: Apple Mail (2.3864.700.51.1.1)
Message-ID-Hash: GKDV3MRLVSIOOV5UZAH34BKXZAUFMN5Z
X-Message-ID-Hash: GKDV3MRLVSIOOV5UZAH34BKXZAUFMN5Z
X-MailFrom: woody@pch.net
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: Synchronizing caches of DNS resolvers ("poisonlicious" draft)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z6vm0PD-e1BriLO7caecTUKGqzs>
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 Jul 28, 2026, at 14:38, Ondřej Surý <ondrej@sury.org> wrote:
> 
>> On 27. 7. 2026, at 07:54, Bill Woodcock <woody@pch.net> wrote:
>> 
>> 
>> 
>>> On Jul 20, 2026, at 17:55, Stephane Bortzmeyer <bortzmeyer=40nic.fr@dmarc.ietf.org> wrote:
>>> https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-poisonlicious/
>> 
>> I strongly support the effort, but would prefer DoT to be mandatory, and DANE authentication to be preferred over TSIG, when available.
> 
> I strongly believe the security mechanism should be a matter of local policy
> (and implementation defaults) rather than something enforced by the Internet
> Standard.
> 
> So far, the DNS does not even enforce a secure transport and/or authentication
> for XFRs, so enforcing DoT/DANE/whatever for something that is going to be
> mostly used on internal networks feels over the top.

Sorry, I should have said DoQ/DoT; force of habit.

I hear you, but I think that as long as we make security optional, a lot of people won’t bother, and then a lot of people writing code won’t prioritize it, and then it won’t work when it’s needed.  Whereas if everything is as secure as our current standards facilitate, all the time, we only have a single build target and test case and the most-sensitive traffic doesn’t have a target painted on its back.

Why should HTTP be secure-by-default, but DNS not?

                                -Bill

v2.46.0 | Report a Bug | By Email | System Status