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

Hugo Salgado <hsalgado@nic.cl> Thu, 04 May 2023 20:57 UTC

Return-Path: <hsalgado@nic.cl>
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 A3939C17B351 for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 13:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=nic.cl header.b="ldQj2klG"; dkim=pass (2048-bit key) header.d=nic.cl header.b="ldQj2klG"
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 U9u3whhWnqfE for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 13:57:15 -0700 (PDT)
Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63750C1388B9 for <dnsop@ietf.org>; Thu, 4 May 2023 13:57:14 -0700 (PDT)
Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id C38E8195D5A56; Thu, 4 May 2023 16:57:11 -0400 (-04)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.cl; s=default; t=1683233831; bh=T5Gz+kbhfKS95SCzjYtx3Xn4z649O6QrDUu1pkcCWwI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ldQj2klGolpl7v8iyiw1GryLKOWcTl1Zid6ApAUKyA47VSjGjEowJml9rsEH+9rMk MsEkEzlRvozIEX/0rLJoRtTnkCHT06TWOHp0eh+zQSyN+ddgDaYeq3Qc03/xzw5r7U L4mWotQXLGEX2/pJZlk3GbZWjkMLrgw7CXZoz4evk9ZTNMo9oaqfSZC8ZE1fNnzuWU Scmiy5xX7nalob0Q28InnGZB3n/GDZVZeFjLro57tUO1yFNGmpM4hO9EZZjjexOQaj gMTGZrQgW8lkodJWs6Xmi5TXxr/mLUA8/5wcmGBc4ZohxxYZ8KRHVhM2YulGxjE/2a KAYA57iS/HG0Q==
Received: from pepino (unknown [IPv6:2001:1398:14:0:172:30:16:17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nic.cl (Postfix) with ESMTPSA id 931DA195D5A54; Thu, 4 May 2023 16:57:11 -0400 (-04)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.cl; s=default; t=1683233831; bh=T5Gz+kbhfKS95SCzjYtx3Xn4z649O6QrDUu1pkcCWwI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ldQj2klGolpl7v8iyiw1GryLKOWcTl1Zid6ApAUKyA47VSjGjEowJml9rsEH+9rMk MsEkEzlRvozIEX/0rLJoRtTnkCHT06TWOHp0eh+zQSyN+ddgDaYeq3Qc03/xzw5r7U L4mWotQXLGEX2/pJZlk3GbZWjkMLrgw7CXZoz4evk9ZTNMo9oaqfSZC8ZE1fNnzuWU Scmiy5xX7nalob0Q28InnGZB3n/GDZVZeFjLro57tUO1yFNGmpM4hO9EZZjjexOQaj gMTGZrQgW8lkodJWs6Xmi5TXxr/mLUA8/5wcmGBc4ZohxxYZ8KRHVhM2YulGxjE/2a KAYA57iS/HG0Q==
Date: Thu, 04 May 2023 16:57:10 -0400
From: Hugo Salgado <hsalgado@nic.cl>
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
Message-ID: <ZFQcJh/oCKqdsyhp@pepino>
References: <2233B06E-126D-455F-90BA-6C0C00C06508@pir.org> <03RMKMRvj3ITkOlLv12cLejcpywcK59qXd2UK6ZXKVrDW1-syawnOfd9R_PcUQp_5bNOsb3xsEzx-6tqEIbFA8o5p1xxD_-MRXk_imQBsTE=@hopcount.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="cwMmngN+X5VM/k0P"
Content-Disposition: inline
In-Reply-To: <03RMKMRvj3ITkOlLv12cLejcpywcK59qXd2UK6ZXKVrDW1-syawnOfd9R_PcUQp_5bNOsb3xsEzx-6tqEIbFA8o5p1xxD_-MRXk_imQBsTE=@hopcount.ca>
X-Virus-Scanned: ClamAV using ClamSMTP on Thu May 4 16:57:11 2023 -0400 (-04) (mail.nic.cl)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LG4NzQE-w4AsRd4XrAPGvrFvaRg>
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, 04 May 2023 20:57:19 -0000

Hi Joe, thanks for your comments. Answers inline:

On 14:16 27/04, Joe Abley wrote:
> 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).
> 

You're right. That undefined behaviour for "not authoritatives" seems
to be a source of concern. Maybe we can just drop that introductory
phrase, wich otherwise talks about the transitive nature of EDNS
options.


> 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?
> 

In the document, the first time we mention zone is "... with a
token field representing the version of the zone which contains the
answered Resource Record,...". So that's the meaning. If you think
is better to repeat that clarification later, please tell me where and
we'll add it!


> 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?
> 

Yes, we expect to have a zoneversion response at this point. The only
thing that we might want to clarify is the zoneversion comes from the
authoritative part of the Name Server doing the referral; in this
particular case, from the root zone.

In section 3.2. it's mentioned:

  If an EDNS ZONEVERSION option is sent to a server that is
  Authoritative for the zone, then a name server that understands the
  ZONEVERSION option [...]

By using the definition of referrals [RFC8499] and the subtleties of
the parent authority above the zone cut, maybe we could add a
clarification in this point? Maybe something like:

  "In case of a downward referral response, even when the Authoritative
  Answer bit is not set, this specification considers that the Answer
  holds data that is authoritative for some portion of the QNAME (See
  "referrals" in RFC8499, Section 4). Given this, a ZONEVERSION option
  MUST be present as indicated in the paragraph above, with the zone
  versioning value that holds that portion of the QNAME where it is
  completely authoritative."


> Is it sufficiently obvious to the receiver of such a response which zone's version is being returned?
>

I hope so ;) A human operator could infer that information, based on
the AUTHORITY section that is included in the same referral.

And if the NS acts as authoritative in both sides, the AA flag in the
answer below the cut can serve as differentiator of which serial we're
receiving.


But once again, if the group consider it necessary, we could adapt the
extension to explicitly add the portion of the QNAME to which the
version corresponds to the authoritative portion.

If that's the case, and to avoid handling variable fields for such
label, we could use something similar to RRSIG's "labels field"
[RFC4034 section 3.1.3] in which we add a single byte indicating the
number of labels in the QNAME.

Does that sound like an overkill? Comments are welcome.


> 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.
> 

Yes, that makes sense. We can drop that special case, it's not worth
the efficiency gained by avoiding that redundancy, versus the problems
you indicate.

Regards,

Hugo & Mauricio


> 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
> 
> >