On Tue, Jun 18, 2024 at 1:40 PM Wessels, Duane <dwess...@verisign.com>
wrote:
> 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.
>
If you call out NODATA, I think for clarity you should call out NXDOMAIN as
well. Perhaps the
text for both can be conbined in a single sentence/paragraph?
> > 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.
>
Ok.
>
> >
> > 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.
>
Oh, you are right. It's not the job of the authoritative server to follow
the DNAME, so there is
just one zone and one zone version and so there is no issue. I was wrong,
thanks :)
> 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.
>
I thought about that as solution but since DNAME's could end up being
chained, the label
count is not guaranteed to be different for all entries in the chain. But
anyway, you convinced
me no issue exists surrounding DNAME,
> > 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?
>
That would address my rannge concern yes. It still leaves the issue of
"syntax and emantic". eg, want
if I submit a template for:
TYPE: NOHATS
Value: An encrypted opague blob containing proprietary information that can
be returned to the operator
of the nameserver.
If we get 15 vendors doing this, would they use their own type? Or should
the draft document a special
type for this use, eg TYPE: OPAQUE and make everyone who wants to hide
stuff to use the OPAQUE type?
> > 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.
>
Perfect!
> 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
>
Sounds good!
>
>
> >
> >
> > 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.
>
Thanks!
>
> >
> >
> > 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.
>
It might have been wrapping / cut on the view due to larger than average
font to compensate for
worse than average eye sight.
>
> >
> > 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?
>
I think so too. Just wondering if this would lead to confusion where people
might
think ZONEVERSION requires an Authoritative Section?
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
