Reviewer: Peter van Dijk Review result: Almost Ready 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 This document is generally in good shape. It is not too prescriptive, leaving room to implementers to honour the requirements in a way that makes sense for their implementations. The document has not seen a lot of WG discussion; I hope this means people have read it and generally agree. Section 3.3 contains a "FOR DISCUSSION" note. I believe this means the document cannot currently pass Last Call. (See below for some notes on that discussion item.) I have various nits and suggestions. Please see them below. Section numbers are for -03. ## 2 I know section 2 is not meant to be exhaustive, but I wonder if FORMERR deserves a mention. In theory, a FORMERR response will not improve with time until an auth operator actively intervenes (by updating/replacing software to a more compliant version). SERVFAILs, by comparison, can be much more transient. ## 2.1 current: > Authoritative servers, and more specifically secondary servers, > return server failure responses when they don't have any valid data > for a zone. That is, a secondary server has been configured to serve > a particular zone, but is unable to retrieve or refresh the zone data > from the primary server. proposed: > Authoritative servers, and more specifically secondary servers, > return server failure responses when they don't have any valid data > for a query. For example, a secondary server has been configured to serve > a particular zone, but is unable to retrieve or refresh the zone data > from the primary server. ## 2.2 The first paragraph correctly mentions "policy reasons". The second paragraph correctly says "they are not authoritative". I am not sure not being authoritative can be considered a policy reason, so perhaps these two paragraphs can be connected with an "or"? ## 2.3 "If, however, the implementation does not join outstanding queries together, ..." - this could use a reference to 5452 4.3 and 5452 5, pointing out that implementations really should be joining queries together for security reasons whenever they can, beside the reason given in the draft of not overloading authoritatives. ## 3.1 "A resolver MUST NOT retry a given query over a server's transport more than twice" - should this be clarified to say "in a short period of time" or something like that? Clearly a retry is allowed *eventually*. Also, "MUST NOT" is pretty strong language. Given the various process models of resolver implementations, two subprocesses (threads) both retrying the same or a similar thing a few times can not always be avoided. Would you settle for SHOULD NOT? The "given" in "retry a given query" gives some leeway, but not enough, I feel. "may retry a given query over a different transport .. believe .. is available" - this ignores that some transports have better security properties than others. One currently active draft in this area is draft-ietf-dprive-unilateral-probing. Perhaps add some wording, without being too prescriptive, such as "available, and compatible with the resolver's security policies, ..". ## 3.2 A previous review (https://mailarchive.ietf.org/arch/msg/dnsop/sJlbyhro-4bDhfGBnXhhD5Htcew/) suggested that the then-chosen tuple was not specific enough, and also said it was too prescriptive. I agree with both. The current draft prescribes nothing, which I'm generally a fan of! However, speaking to a coworker (the one likely responsible for implementing this draft, if it turns out our implementation deviates from its final form) told me "some guidance would be nice". After some discussion on prescriptiveness, here is our suggestion: do not prescribe, but mention (without wanting to be complete) a few tuple formats that might make sense, and suggest that implementations document what they choose here. ## 3.3 > FOR DISCUSSION: the requirement quoted above may be problematic > today. e.g., focusing on NS as the query type (a) probably goes > against qname minimization, and (b) is not the real problem. Also > RFC 4697 doesn't place any time restriction (TTL) on this. *Before* qname minimization, queries that yield delegation answers often did not have type NS. With qname minimization, depending on the implementation, those queries might in fact be NS. (7816 specifies NS; 9156 relaxes the qtype requirement for qname-minimized queries). That said, there is no reason for the requery (which, as this draft reiterates, MUST NOT be done) to use NS, and so, I do agree the focus on the NS type should be removed. As for TTL, the originally received delegation will eventually expire, so the requery will in fact happen at some time after that expiry. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
