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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 05 May 2023 00:09 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 30A4FC152DA7 for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 17:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=gmail.com
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 EUGS_7SG6toD for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 17:09:50 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 29AE7C1519B9 for <dnsop@ietf.org>; Thu, 4 May 2023 17:09:50 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-24e2bbec3d5so873941a91.3 for <dnsop@ietf.org>; Thu, 04 May 2023 17:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683245389; x=1685837389; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YnlTm2RncyfcXiQ6wFLsl+G93YrLvkASs2z9RU80hJ4=; b=A4ixgaSV9YFRQ3Ng5Vb/KjSq05RBwzVnzKEtw/q/Yqea2xUlTjShFSDfvaFGvfoOQt wnPeseehft6plLGuW9nam+Jdoau4beTu/YNfrCg5hhysviHUeLqlEnUFpx9zkk2oEnxm Zk1+RkAGTWRWSoGL/QXjexI4RuaF1uZEg50CVTZVE4i4NFKl5cT5nmURC64iq8fDD4CD eqJiWz4wgMb5kvvImCSFlXuGu+mT5G6lJSadttigfB42g+CD06wcKCRHztG4oZylAY0B /zSsrTcFJcF9OkEFDKNuubhRYxlKQATYA2vmSNuDJUM6CufJ6RIjNP8xpr3fDBOBuYBV PLlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683245389; x=1685837389; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YnlTm2RncyfcXiQ6wFLsl+G93YrLvkASs2z9RU80hJ4=; b=EZb+XUH22PTnwVzu/FzppiPrVv1CBB+qP2Ekv/Yw4LjXgFuc5r1aYzIk6L/g8C11AD iBZizSfw/Le9/9/xE0tRq9zh4p1bj3J0IJ1WXrQknWxGtewoAOKMu7js6Y17SGKugyZV JxqS/wuRcwmELnCd9/xf00S/8Njy16RNB1mls9cAZojuS34z866bRJluj+6E5IoWh8Pn 2XZf4+W4si8DhbYwJ3s20pajrdxLIhaFjXifLkEAmLMhTjs4nwD8gFmaO7pAVNJRU6cR 998dW6ThEEX2K1odcvpVIQiU8QbdXSvrLfolZ3x5Fsk18zyfHj0bvPXskdGLlCrSGTw7 mLSw==
X-Gm-Message-State: AC+VfDwH7YsVlr6yHm2XHQBFiO1pbDZGv9sI5CO6Q3igehgD3acQXor4 gSbEXd74E3f1DMygVkuXQQM0YE8+CCLV/Nn3TBs=
X-Google-Smtp-Source: ACHHUZ5WNvNZKbOhgy93F+yyrNTH/YPyP1OuQCRamvWspW7vdl1mzGgDHIMs3XpWbV5meyc+XHS/5U3QUkouMIsq2AE=
X-Received: by 2002:a17:90a:4d87:b0:23f:58a2:7d86 with SMTP id m7-20020a17090a4d8700b0023f58a27d86mr3969066pjh.10.1683245389372; Thu, 04 May 2023 17:09:49 -0700 (PDT)
MIME-Version: 1.0
References: <2233B06E-126D-455F-90BA-6C0C00C06508@pir.org> <03RMKMRvj3ITkOlLv12cLejcpywcK59qXd2UK6ZXKVrDW1-syawnOfd9R_PcUQp_5bNOsb3xsEzx-6tqEIbFA8o5p1xxD_-MRXk_imQBsTE=@hopcount.ca> <ZFQcJh/oCKqdsyhp@pepino>
In-Reply-To: <ZFQcJh/oCKqdsyhp@pepino>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 04 May 2023 17:09:37 -0700
Message-ID: <CAH1iCiq5x1k+3bS+HNcukYyrAkwyKHPPkB2Z45ddS3mG6v4QBA@mail.gmail.com>
To: Hugo Salgado <hsalgado@nic.cl>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000080e36905fae71bef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/y5eWWKMsQchPgi9jed9LexQ0RqU>
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: Fri, 05 May 2023 00:09:51 -0000

Top-reply (to avoid adding to confusion by attempting to add in-line
commentary of uncertain value):
I also agree that this is very valuable and definitely helpful for
diagnostics.

I think there are a number of edge cases, for which disambiguation might be
helpful.
Apologies if this seems to add complexity, rather than the desired clarity
on responses.

The general edge case would be where a response includes multiple RRsets,
which could be from different zones on the same server.
Currently that would potentially occur if the response had CNAME, HTTPS, or
SVCB records in addition to the RRTYPE matching/corresponding to the QTYPE.

E.g. query: QNAME = foo.example.net, QTYPE = A;

response contains
foo.example.net CNAME bar.example.com

bar.example.com A {example IP address}

# server is authoritative for example.com and example.net, serves both zones
# ZONEVERSION for both zones is valuable for diagnostic purposes



Similarly, the Additional section could have records from multiple zones
(served by the same server), possibly (I think, maybe more likely
with HTTPS or SVCB responses).

The disambiguation I'm about to suggest would uniquely identify an RRSet in
the response by the location in the response message of the first record.

With the proposed (below) disambiguation, it would then be possible to
include multiple ZONEVERSIONs.

The simplest way would be one ZONEVERSION per RRset.
(There are other ways of having a single ZONEVERSION reference multiple
RRsets, but I think that would be needlessly complex at that point.)

If there are multiple RRsets from multiple zones, it would be necessary to
specify the zone that corresponds to the ZONEVERSION for each RRset.

Everything beyond this probably falls into the "bike shed" category.
(Which method to implement any element is much less important than the
existence of some method.)
E.g.

   - Identify the first RR of an RRset:
      - 2-bit section (0,1,2,3 for query, answer, auth, add) plus RR
      ordinal (e.g. 1st RR in the section)
      - compression pointer
      - something else ???
   - Identify the zone that the ZONEVERSION applies to (i.e. the RRset):
      - label count
      - compression pointer to domain name of zone
      - uncompressed domain name of zone (no pointers)
   - (plus the actual zoneversion, and any flag(s))

I think even in the single RR response this addresses Joe's issues, and
allows the recipient to distinguish parent/child side of zone cuts (for NS
records).

Brian


On Thu, May 4, 2023 at 1:58 PM Hugo Salgado <hsalgado@nic.cl> wrote:

> 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
> >
> > >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>