Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Joe Abley <jabley@hopcount.ca> Thu, 27 April 2023 14:17 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A30C14F748 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2023 07:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sUN7OggrYZC for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2023 07:17:00 -0700 (PDT)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7B3C14CEFC for <dnsop@ietf.org>; Thu, 27 Apr 2023 07:17:00 -0700 (PDT)
Date: Thu, 27 Apr 2023 14:16:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=protonmail; t=1682605017; x=1682864217; bh=stY9VmT4oAibMnD2TgT/Nq17Er85bqpky5LpWx0+mXg=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dbKZmtgXcGyL5Jr8tbxodF9fAEAJF18dPupEjfJFVS973Bb8Wqy0IgQQFgP0yeIXy Ng1xdRAlraAfOABhUMZcTHEH+hMOn/ZtxNZDZS0NZJn+Aq/7o8eFH1BWvTewh3Hz2d hSEs8Uv3Omq33Hg3rPeZucCFUSro8PeWL/QbH5tv26b5bWA/nhg4m03ZbgD7wZahFE ow93ZlYpiCh2PM2ADOs/kLbzJqgWff8mIEcU/Cg/l2xNLLFPtmIpM3aCQn1lG8+uVC OqGAO3H46XwDfrJwA3eoCOHva34qHOnSFo8B9S0q+G9lU6PeSx0SPuaWKzdVH57/V/ TeE90c0ajEegg==
To: swoolf@pir.org, dnsop@ietf.org
From: Joe Abley <jabley@hopcount.ca>
Message-ID: <03RMKMRvj3ITkOlLv12cLejcpywcK59qXd2UK6ZXKVrDW1-syawnOfd9R_PcUQp_5bNOsb3xsEzx-6tqEIbFA8o5p1xxD_-MRXk_imQBsTE=@hopcount.ca>
In-Reply-To: <2233B06E-126D-455F-90BA-6C0C00C06508@pir.org>
References: <2233B06E-126D-455F-90BA-6C0C00C06508@pir.org>
Feedback-ID: 62430589:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_8pXyXJVvXbkbScbTSThkncQ6aeW8wbK6ZjipLyYE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/X464N-KhlLuutU2CklSCVJFbja8>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2023 14:17:05 -0000

On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swoolf@pir.org](mailto:On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <<a href=)> wrote:

> This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
>
> If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this message. We particularly need to hear from implementers and operators whether this EDNS option is implementable and useful.
>
> If you don't think it's ready, and have specific concerns or suggestions, please let us know about those too.
>
> The Last Call will be two weeks, ending on Thursday 11 May.

As I think I have said before, I like this idea and I think it is genuinely useful. The draft is well-written and mainly clear but I have some observations. I think some additional work would be beneficial before we raise the draft up the IESG flagpole.

In section 1 I see "Resolver and forwarder behaviour is undefined". However, in section 3.2 the specification says that if various conditions (including "server that is authoritative for the zone") are not met, the answer "MUST NOT add an EDNS ZONEVERSION option to the response". This seems inconsistent; 3.2 in fact does in fact seem to define the required behaviour for at least some resolvers and forwarders (those that are not also authoritative servers).

The draft refers to "the zone" in various places, as in one of the sentences quoted above. I think it's fairly obvious what this means, but I don't think it would hurt to be a little more specific about it. After all, if the whole point is to identify something specific about a zone, wouldn't it be good to be clear about which zone we are talking about? Should the option included in responses include the identity of the zone explicitly?

For example, suppose I am doing a recursive lookup on an empty cache. I send a query to a root server with the EDNS ZONEVERSION option and get a referral response. Is it reasonable for that response to include a version token for the root zone in its response? Is it sufficiently obvious to the receiver of such a response which zone's version is being returned?

The draft contains phrases like "QNAME belongs to an authoritative zone of the server" which I also feel has the potential to be misunderstood.

The idea of omitting the option in a response which also includes the SOA serial seems problematic. I feel like this could mask various kinds of implementation problems, and an explicit signal might be better. For example, what about the case where the SOA serial does not represent the zone version, and the response is omitted by error, e.g. because a member of an anycast cluster is badly configured? That should be interpreted by the receiver as a missing response option, not as a new version number that can safely be processed and compared with others. How would the receiver of the response know to do this? I fully confess I haven't thought about this in detail, but I think there are some lurking dragons here.

Happy to suggest text around these various points if there is some kind of consensus that these are things that would merit from attention.

Again, great idea though. I do like it and would definitely use it if it existed.

Joe

>