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