> On Aug 19, 2016, at 11:38 AM, 神明達哉 <jin...@wide.ad.jp> wrote: > > At Wed, 10 Aug 2016 16:54:39 -0700, > "Paul Hoffman" <paul.hoff...@vpnc.org> wrote: > >> [[ A month later, we're still eager to hear responses to the draft. We >> got a few that we have incorporated for a new version, but want to be >> sure we're on the right track before we move ahead. ]] > >>> We understand that "specify more than one" is often an unpopular >>> choice in the IETF, about as unpopular as "don't get consensus on >>> one". This is a WG document so we need consensus even to go with two >>> ways. We look forward to hearing from you about this choice and how we >>> can move forwards. > > On this specific point I don't have a strong opinion. Personally, I > can live with the two-solution approach if it's deemed to be nearly > impossible to reach consensus on a single solution. While I'd > definitely prefer a single solution, the current draft seems to > provide a reasonable explanation on why we have two at least for now. > > Some specific comments on the 02 version follows: > > - Section 1.1 (or for general discussion): another obvious downside of > the QNAME-based approach is that it can't be used for all possible > zone names because of the size limitation (255 octets) while adding > extra label. In practice, this is less likely to be a real issue > since trust anchors would only be configured a higher level zones. > But I think it's worth mentioning explicitly.
I support adding this caveat. > > - Section 4.3 > > A responder MUST NOT include the edns-key-tag option in any DNS > response. > > I wonder whether it might be useful for a responder to signal its > capability of understanding the option, either by including this > option in the response or in some other way. Then the resolver may > use that information to suppress further unnecessary generation and > inclusion of the key-tag option. Not a strong opinion, but raising > it just in case it's worth considering. I generally like bi-directional signaling such as this, so I would not oppose having the server indicate its support for the feature in a response. I would like to hear from implementors whether or not they feel this places a burden on the implementation. I know they already must do things like retry queries with/without EDNS and sometimes find a UDP message size that works. This adds to those state-keeping requirements. Do we have to worry about middleboxes that would allow the option code in queries but block it in responses? We also would have to figure out whether a recursive should signal its support of the feature to a stub. > > - Section 5.3 > > Unless the zone operator has intentionally added > "_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN > response. > > Perhaps a pedantic comment, but I suspect this is not 100% accurate > in that it could legitimately result in other response than > NXDOMAIN, e.g., if there's a wildcard that would match the > "_ta_xxxx" name even if (a record of) that specific name itself > isn't added to the zone. On the other hand, ignoring this > nitpicking this requirement seems to be too obvious; if a name > really doesn't exist in the zone, the server MUST surely return an > NXDOMAIN, but it's not specific to this protocol, right? So, in the > end, I'd primarily suggest just removing this sentence. Then we > don't have to worry about making it very accurate, while IMO not > leaving any obscure points. I can be convinced either to keep it or to leave it. My rationale for that sentence is to state that a server should not have some built-in logic that determines the response to these types of queries. The response code should be determined by whether or not they are in the zone file (or as you say covered by wildcard). > > - Section 5.3.1 > > Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec- > aggressiveuse] may also affect the quality of key tag signaling. > > (nit) nsec-aggressiveuse is now a dnsop wg document. Ack. > > - Section 5.3.1 > > When the response code for a key tag query is NXDOMAIN, DNS resolvers > that implement aggressive negative caching will send fewer key tag > queries than resolvers that do not implement it. > > In the context of the interaction with nsec-aggressiveuse, I think > this should be more generalized than the response to a key tag query > itself, e.g.: > > When a query results in an NXDOMAIN response with NSEC or NSEC3 > that covers the name of a key tag query, DNS resolvers that > implement aggressive negative caching will send fewer key tag > queries than resolvers that do not implement it. IMO your version adds a little unnecessary complexity to the sentence, while making the same point. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
