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

[Hugo Salgado <[e-mail]>]

Thanks Brian for your comments.

Currently the draft only allows zoneversion extension for records in
the ANSWER section of the response. But you're right that even there
we could have records from different zones.

For the sake of simplicity I'd prefer to clarify the text and declaring
such case as undefined, and it MUST NOT include a zoneversion if there's
no a single unequivocal zone.

Or at most, declare that it always referes to the first record of the
section.

Besides that, why are you including an "uncompressed domain name
of the zone" in your proposal? Is it not enough with the label count
and compression pointer to domain name of zone?

Regards,

Hugo

On 17:09 04/05, Brian Dickson wrote:
> 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 <[e-mail]> 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 <[[e-mail]](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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> >

> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop