Paul Wouters has entered the following ballot position for draft-ietf-dnsop-zoneversion-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/ ---------------------------------------------------------------------- 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." ? 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. 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? 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. 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. ---------------------------------------------------------------------- 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. 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. I was initially confused and assumed it was talking about what this document calls VERSION, so alternatively instead of saying what the OPTION-LENGTH is, perhaps say: The VERSION length for SOA-SERIAL MUST be four octets, resulting in the OPTION-LENGTH for this EDNS(0) type option to be set to 6. 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?) The example dig command should have +norecurse :) 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? _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
