[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency

Joe Abley <jabley@strandkip.nl> Thu, 12 June 2025 06:10 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 991B43405512 for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 23:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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 fdLn7anP9V1x for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 23:10:44 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.11]) (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 E302C340550A for <dnsop@ietf.org>; Wed, 11 Jun 2025 23:10:43 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4bHsb65LFyz14KF; Thu, 12 Jun 2025 06:10:42 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4bHsb62zvszC1; Thu, 12 Jun 2025 06:10:42 +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=EARIrb+m; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1749708642; 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=WOat+fmPGveZAHsY6aoRY0Upm62nyaqNtDGuVS4EtjQ=; b=EARIrb+m8dgwkbg+4uqFP5kZQHtlcOM95GCMpGZ4/ywdeyV/M1KwXgyUqHNM8ry6lWYjvm jsarjBu3oFf2QBbVHYsB+OYq47iHUufE/cL4NaernJsHiNRh9HOcXmgAB83sQxeOAycC0C xj7ENFGoOXNOcK2RkfNgr7oj6DFO1arnFj+/wzowbRwFSDAY2NTFIWz6kd162t+a/nXU+i tz46mVKkTN5FgEnCFyzCpi71TyM1eUOGbwwFx4R2eDw2FzuiLuNN6iQ754I/Vf6y8cYF4m Pr7bYgtnHvojQbFiFLi08V3ErMDGPRV8HPbkvzwjFiF1k/2gBmmBOhzKYjzLfg==
X-CM-Envelope: MS4xfONQMaOz274Iov+im3ErygPBjMYSeL3yk9cu4CJAAmVzdCkVbSzNos0GPzGUz8FuBnEaCSUag4YP79O6136IoKvkop6fV+IHWT+lU02tlm8dwPGc4Tmt amY0PckOHj+TGOD1jFBkykuVMByUcv/9rJXcttyc7SLe7vrv11hlLHfUsI9ZMt1nsHMUeQ10EPwfAaor7i7tYAZXOaKc9bFGKldCdBUYYZIfoOTKbmfGAo8/ CYCsq8XZ1/hxYA1mr8PeKQ==
X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=684a6f62 a=JOIo7ZnGrqNsdeP5EGHgoA==:117 a=JOIo7ZnGrqNsdeP5EGHgoA==:17 a=IkcTkHD0fZMA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=cCnh0FZycHl4JZ67cgQA:9 a=QEXdDO2ut3YA:10
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Thu, 12 Jun 2025 08:10:31 +0200
Message-Id: <3E132416-9291-4736-B416-4C2295168F39@strandkip.nl>
References: <4F949062-8C2D-450E-A4EF-73AD611AA429@gmail.com>
In-Reply-To: <4F949062-8C2D-450E-A4EF-73AD611AA429@gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Spampanel-Class: ham
Message-ID-Hash: CMQ3T5KXRFXUA5IOEYVDJXZ6HD7WK3P4
X-Message-ID-Hash: CMQ3T5KXRFXUA5IOEYVDJXZ6HD7WK3P4
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: Ondřej Surý <ondrej@sury.org>, dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sUZC902e-AX_h6ULN6Enx2iKAP8>
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 12 Jun 2025, at 04:23, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

> On Jun 11, 2025, at 5:14 AM, Joe Abley <jabley=40strandkip.nl@dmarc.ietf.org> wrote:
> 

>> I don't think the recommendations in the document will do any harm, and some people think they are useful, so I think it is fine to publish this advice.


(Above repeated, just as a reminder)

> I think a balanced reading of the advice, which might depend on favorable interpretation of semantics and definitions, can be actionable and an improvement.

I don't really know what this means here, but I'll note that we ought to aim for documents that are unequivocally clear, not those that are useful only if read under a full moon.

> The (IMHO) reasonable expectation regarding these specific record types is that they SHOULD be consistent across an anycast set.

This is the DNS, and the DNS is specified to be loosely coherent. So, in fact, the expectation that responses are consistent across a set of authoritative servers is definitively unreasonable. Implementation of a DNS service with anycast does not change this. This is an important contract between publishers and consumers of data using the DNS protocol.

Acknowledging and accommodating this contract is part and parcel of using the DNS as a control plane. If you ignore the contract, you are inviting sadness. If you try to paper over the fact you ignored it you're just making the sadness less predictable and harder to troubleshoot. If the contract makes your control plane weak, perhaps don't use the DNS as a control plane.

In this case the duct tape is only being applied in places that are feeling the consequence of forgetting the contract; the consequences of ignoring the contract are largely self-inflicted and not shared with other innocent bystanders. This is why I think this proposal overall does no great harm and I think it's ok to publish. This is not the same as being in favour of duct tape. 


Joe