Hi Paul, thanks for the review. Comments inline…
> On Jun 17, 2024, at 4:23 PM, Paul Wouters via Datatracker <nore...@ietf.org>
> wrote:
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Just a few hopefully minor issues to talk about.
>
> In section 3.2, why is NXDOMAIN not listed? When asking for
> "foobar.nohats.ca",
> couldn't it be useful to get the zone version, if the nameserver is
> authoritative for "nohats.ca" and has no delegation for "foobar.nohats.ca." ?
The intention certainly is for a server to return zone version information in
an NXDOMAIN response. Would this change to the start of 3.2 address your
concern?
OLD:
A name server that … is authoritative for the original QNAME,
NEW:
A name server that … is authoritative for the zone of the original QNAME,
Or would you also like to see NXDOMAIN specifically mentioned like this?
A name server SHOULD include zone version information in a name error
(NXDOMAIN) response, even though the response does not include any
Answer section RRs.
>
> What should an authoritative nameserver return as zone version if it is
> configured as authoritative nameserver but can't get the zone version (eg
> because "no permission to read file") One way would be to allow it to return
> a zero length for ANY type and define that as an error condition.
I think the authors will need to discuss how to handle error conditions like
this
and get back to you.
>
> It seems DNAMEs could lead to involving two or more zones the nameserver is
> authoritative for. How should this be handled? Only use the first DNAME's
> zone's version?
I don’t see the issue. The version corresponds to the QNAME zone (and is type
agnostic).
It doesn’t depend on Answer RR names.
One thing we could do is allow multiple ZONEVERSIONs as long as
(TYPE,LABELCOUNT)
remains unique. Then the server could return multiple zone versions if it
happens to be authoritative for multiple zones of the QNAME.
>
> The type leaves no room for proprietary (or somehow encrypted) zone versions,
> as the DE advise states:
>
> In particular the reference should state clear instructions for
> implementers about the syntax and semantic of the data
>
> If you did not mean to exclude encrypted zone version data, perhaps clarify
> the advise to the DE? Or are those deployments meant to use the
> "local/experimental" use, in which case calling it "private use" might be
> better?
>
> Have you considered leaving a small initial space for "RFC Required" policy?
> Eg 0-15 ? With only 253 types available, I'd feel happier with that,
> especially if this supports proprietary types.
Does changing the range 246-254 from “experimental” to “private use”
sufficiently address your concern about proprietary types?
>
> Should implementers be warned not to blindly copy this EDNS(0)
> options from the query of a DNS client onwards? Doing this could cause
> amplification attacks if some server uses a non-SOA-SERIAL type with a
> long length.
How’s this (inspired by RFC 5001 NSID)?
3.2.1. ZONEVERSION Is Not Transitive
The ZONEVERSION option is not transitive. A name server (recursive
or otherwise) MUST NOT blindly copy the ZONEVERSION option from a
query it receives into a subsquent query that it sends onward to
another server. A name server MUST NOT send a ZONEVERSION option
back to a client which did not request it.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A name server SHOULD include zone version information for
>
> Can this be rephrased as:
>
> When asked for a zone version, a responding name server SHOULD
> include zone version information for [...]
>
> Just to avoid implementers from reading this and adding it when the DNS
> client did not ask for it.
I feel like it would be repetitive to make that change all the times we
say “A name server SHOULD include…”. How about this change to the start of 3.2
(item (b) new):
A name server that (a) understands the ZONEVERSION option, (b)
receives a query with the ZONEVERSION option, (c) is authoritative
for the zone of the original QNAME, and (d) chooses to honor a
>
>
> The OPTION-LENGTH for this type MUST be set to 6 in responses.
>
> Maybe say:
>
> The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in
> responses.
Done.
>
>
> My OCD triggers on these unbalanced parentices:
>
> ; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001
> (example.com.)")
>
> (note it seemed to render badly in my browser, but copy&paste seemed to fix
> it again?)
I’m not sure what you saw but maybe its better to remove the quotes there.
>
> The example dig command should have +norecurse :)
Done.
>
> Why does the example contain an AUTHORITY SECTION for an AA answer
> with data? Seems .com does that but other nameservers I tested do
> not (eg nohats.ca or .nl). This makes it a bit unclear if the setting
> of zoneversion requires that the Authority Section is included. Maybe
> a clarifying note can be added? I assume this related to query minimalization?
>
I think this is just the effect of “minimal-responses” feature available
in some implementations?
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
