[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency
Ondřej Caletka <ondrej.caletka@gmail.com> Tue, 24 June 2025 11:42 UTC
Return-Path: <ondrej.caletka@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 8C6DB38B5E05 for <dnsop@mail2.ietf.org>; Tue, 24 Jun 2025 04:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 3MiMfmkjlwXF for <dnsop@mail2.ietf.org>; Tue, 24 Jun 2025 04:42:25 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 3E5C638B5DF8 for <dnsop@ietf.org>; Tue, 24 Jun 2025 04:42:25 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-ade76b8356cso914459966b.2 for <dnsop@ietf.org>; Tue, 24 Jun 2025 04:42:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750765344; x=1751370144; darn=ietf.org; h=content-transfer-encoding:cc:from:content-language:subject:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=QUxzg7QjfJPCN9Pl0Wud6VSsn4T8fouhYvEKqHCp7LM=; b=IAlt5fvFczcLXkTfmdhZ/hTYp5tvhompPyaKRGpDHhBMNK/qx0NAo7+grEjW+TiERC yU7eEGL9Jj7Q1vvrjwn5pPfFYowOaZBqgo/DtkrTqGcqFKPKESBUJiceLrXYyPLL3CeJ CN9niSetXwYonbI/+rRkcu9REtRrgR5CYEFqQeJxp7nQksAfMm0WNGDVzhoNBoQfGn1c jV9TaAqtNdr0wH9UnslKPEVPtsv9NlgdbcXJtm9tC6khOp1y7uXvmkmkSQwgglJCXRhU 1MMEa791to7Gh2F/Sv2EpF47mIzS6FTDmuBh70XYId7v/2Mw6FKAQYiQeIT1nIVmZpbA Yb3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750765344; x=1751370144; h=content-transfer-encoding:cc:from:content-language:subject:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=QUxzg7QjfJPCN9Pl0Wud6VSsn4T8fouhYvEKqHCp7LM=; b=FJOMoljxPl4nVjaK4TJxJQfvcT7DwHPD9uA65PDcOLCFWy/JXII8wZdUx8Z7WM0ZkB YOFiMl0YbEa8iC2yu2e/BHWJ5MK1iVotrdmF6Rsb8A8nkLB6XLXwzoByg1gE5UBmicWp nlsOT8S7QEMeQBo64nXPQ1inmX71GFTruQznAoEAj899qltjWmxesTRiVkgM39xY3v2A ygLmx9xgB6PQiktTXAMcURRXisCXFykKohITZsHhK6PQBpBLKuc4DPL4FItjqf7yjlav 8g8u3dbGLN+OBA8omxQSx/S8zj38f4o5cm9yLKjPqJ/6cz/t/URz629sTbFCXWyBeWV6 M9CA==
X-Gm-Message-State: AOJu0YxwL1rfM4z9dPUgTVP5Y4fWPhEcCY9vvEZPgYUUvV0DwO7aZoEY 5RLjA6eY3jmRnm6zML117Yx2fgDyqlVNk3/lCUR5uuZglghgDIT51IDEhUyEEabyb0k=
X-Gm-Gg: ASbGncsE/seFScsqEPJC+3llj28b/3Ha58cpony0YGp9I37sMvjB5T8feazDEQmPcbc 6c4r/fHt6q8aIqd82WeFMWZ+9KsZBtAIUpPqPlMo/8JeUtlDpMRniSA6IGRO9fl3YShgHUcWYqV i/CDiMT0ftLwisGyYa4rH4EPjCtxtbfYUNK9A3TdqlzSPNJpIYqK3sFX0sm2SwLrvnW397kqjG+ VZB9FUcoGQ5OMdPBKcAjYVt2NF3vVwbmKb39gsZwk0a61XIUOfBA5eQ8Lc8ahRPF66gyC4okCtg 7OUpA283cGShzO0XwZrMPbwRsCb1Q0b3ak5OFNURExk96fX+CMGDxHrrLtWCJCjBCsU24FuCxwA Z+JrxtVReggeQov8EvIZUR8fH6wpHFw5aTWzBPHSmvcLyTlg0XE3i6MvrWzVoyQ==
X-Google-Smtp-Source: AGHT+IFwpdc7u+Eguzp4Fe8YRs740clK9RE5wDUpo4cHa+bpVFitF5NXN0K6oQaFiJEphEBFigDBbg==
X-Received: by 2002:a17:907:9627:b0:adb:300a:bcc0 with SMTP id a640c23a62f3a-ae057f65398mr1685235266b.46.1750765343615; Tue, 24 Jun 2025 04:42:23 -0700 (PDT)
Received: from ?IPV6:2001:67c:2e8:110:a581:4ef2:dcba:8cbb? ([2001:67c:2e8:110:a581:4ef2:dcba:8cbb]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae0b7bc2107sm13290666b.104.2025.06.24.04.42.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jun 2025 04:42:23 -0700 (PDT)
Message-ID: <75ebbdf6-678c-42e0-95c8-359c72211916@gmail.com>
Date: Tue, 24 Jun 2025 13:42:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: dnsop@ietf.org
Content-Language: en-GB
From: Ondřej Caletka <ondrej.caletka@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: JHV33RK36U7PBUPM4I64XZGGLVFHMHCG
X-Message-ID-Hash: JHV33RK36U7PBUPM4I64XZGGLVFHMHCG
X-MailFrom: ondrej.caletka@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: oli.schacher@switch.ch
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/1Ozd8vE0Mawt7dX8ld7qIa36hFQ>
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>
Hello, sorry for chiming in a bit late but I find part of this proposal a bit harmful: > …the Parental Agent, knowing both the Child zone name and its NS hostnames, MUST ascertain that queries are made against all (reachable) nameservers listed in the Child's delegation from the Parent… You cannot send queries to hostnames, you have to query an IP address. So you have to somehow convert each NS hostname into a set of IP addresses. Normally people do this by asking the local recursive resolver. But with the spirit of this draft this does not seems to be reasonable thing to do because in a multi-signer scenario, each party can resolve the same hostname to a completely different set of IP addresses. Using local recursive resolver might thus bring completely random results based on which authoritative server will it query. In fact, every single branch of the DNS tree can lead to resolving a hostname to a completely different set of IP addresses, including the possible inconsistency between the 13 hostnames of the root servers. Properly resolving a hostname into a set of all possible IP addresses would therefore require reimplementing a recursive resolver to make it follow not only one path but all the possible paths through the DNS tree. This would be extremely hard to implement and such a resolver would be extremely resource intensive to operate. Then, suppose you get multiple IP addresses for a host name. Is it enough to ask one randomly selected address or does one have to query every single IP address the hostname resolves to? Again I see no guidance for this in the draft. I think these are crucial questions influencing interoperability of implementations following this draft. I find it therefore harmful to just specify that you MUST query each NS hostname, without describing the details of how to do such a thing in a consistent and useful way. Since Oli Schacher claims to have this draft already implemented, I wonder, what decisions did you take when implementing this? How exactly does your implementation works for hostname that resolve to inconsistent sets of IP addresses? Also, appendix A1 describes an impossible failure scenario, considering that Section 6.2 of RFC 7344 says that: > The Parental Agent MUST ensure that previous versions of the CDS/ > CDNSKEY RRset do not overwrite more recent versions. -- Best regards, Ondřej Caletka RIPE NCC
- [DNSOP] Working Group Last Call for draft-ietf-dn… Ondřej Surý
- [DNSOP] Re: Working Group Last Call for draft-iet… Ondřej Surý
- [DNSOP] Re: Working Group Last Call for draft-iet… Steve Crocker
- [DNSOP] Re: Working Group Last Call for draft-iet… Michael Bauland
- [DNSOP] Re: Working Group Last Call for draft-iet… Frederico A C Neves
- [DNSOP] Re: Working Group Last Call for draft-iet… Brian Dickson
- [DNSOP] Re: Working Group Last Call for draft-iet… Joe Abley
- [DNSOP] Re: Working Group Last Call for draft-iet… Brian Dickson
- [DNSOP] Re: Working Group Last Call for draft-iet… Oli Schacher
- [DNSOP] Re: Working Group Last Call for draft-iet… Ondřej Caletka
- [DNSOP] Re: Working Group Last Call for draft-iet… Joe Abley
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Joe Abley
- [DNSOP] Re: Working Group Last Call for draft-iet… Joe Abley
- [DNSOP] Re: Working Group Last Call for draft-iet… Ondřej Caletka
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Oli Schacher
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Ondřej Caletka
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen