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 <[swo...@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 > > >
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
