Reviewer: Patrick Mevzek Review result: Ready with Nits Hi, I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir There was already a previous dnsdir review of an earlier version of the document at https://datatracker.ietf.org/doc/review-ietf-dnsop-compact-denial-of-existence-01-dnsdir-early-leymann-2023-11-29/ with which I agree on its core part: "The draft is well written with a clear problem statement and a corresponding solution." Thanks to the authors to have clearly outlined what the problem is, how it was attempted to be solved in the past with associated pros and cons, and how the solution given mostly applies to a specific case (mostly online signing cases), so it shouldn't be seen as a protocol change for every case and user. However, I do find in §3 this to be a little weak: " While it could support NSEC3 too, there is no benefit in introducing the additional complexity associated with it." Because Motivation in §1 clearly explains that this new scheme allows fewer number of NSEC records... and mentions 3 of them are needed in NSEC3 case, so the benefit is (should be) even better here for NSEC3 than NSEC. So I would suggest either giving more details here on what would be additional complexity for NSEC3, or just removing the whole line and stating unambiguously that the document applies only to zones using NSEC. I do have some remarks on §3.4: It defines a new extended code as "Invalid Query Type" but it seems to be defined to be used in case of a resolver asking for "NXNAME" resource record type. Wouldn't it better to be clearer that it applies to the resource record type, as otherwise I fear "query type" could be understood at what RFC 1035 calls OpCode aka Query vs Inverse Query vs Notify vs Update, etc.? Specifically since RFC6895 has: " Data TYPEs are the means of storing data. QTYPES can only be used in queries. Meta-TYPEs designate transient data" And NXNAME is clearly defined as being of Meta type, not QType. Also, RFC8914 already defines code 20 as: "The requested operation or query is not supported." Isn't that good enough, or is really a new code needed (30)? For a generic code (since document says "Note that this EDE code is generally applicable to any RR type that should not appear in DNS queries.") maybe existing 20 could be enough, or otherwise 30 should be repurposed specifically about and only NXNAME queries. Not sure myself, so only in case you find it useful: - about caching, RFC2308 has "Negative responses without SOA records SHOULD NOT be cached", which makes sense when not having the SOA Negative TTL field to use, but here with NSEC(NXNAME), there is a TTL on this record, should it be used (or not) as caching hint? Maybe add a sentence for that, if relevant. - because of §4.1., shouldn't also RFC6891 be marked as updated by this document, specifically since it defines Z (which is mutated here) as "Set to zero by senders and ignored by receivers, **unless modified in a subsequent specification.** " (emphasis mine) Also RFC6891 states the following about the fixed part vs the variable one: "The fixed part holds some DNS metadata, and also a small collection of basic extension elements that we expect to be so popular that it would be a waste of wire space to encode them as {attribute, value} pairs." So this new CO flag being in the fixed part, does it pass the "extension elements we expect to be so popular" criteria? If not, and to resolve the above (no change in RFC6891), instead of a new CO flag, create a new variable part, by requesting a new EDNS0 Option Code? (with a length of 0, its mere presence would mean the same as CO=1) Related, and even if obvious, maybe specify that the flag should be set (value = 1) to enable the feature, and how it should be in replies and what the receiver should do with it (discard I guess, but better to specify - or should 0/1 on answer give an hint if server supports the feature, even if not relevant in that specific answer because it was not an NXDOMAIN/NXNAME case?). Nitpicks: - there is both "type bitmap" and "Type Bitmaps" and "type bitmaps", so both variations in casing and singular/plural form. Even if not really confusing, possibly better to align to just one name? RFC4034 has "Type Bit Maps". - §3.1 says creating a response with no records in Answer section, and then says to create a NSEC record. While normally obvious, just specify that it goes in the Authority section? (specifically since Authority section is mentioned in §3.3) - in §6.2 for the new paragraph to add, there is a dangling open ( with no ) to close it. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
