On Wed, Feb 21, 2018 at 1:44 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > At Wed, 21 Feb 2018 08:53:23 -0500, > Warren Kumari <war...@kumari.net> wrote: > >> > - General >> > I think it's worth pointing out that SERVFAIL can be returned for >> > various other reasons and the detection mechanism relying on it >> > isn't reliable. This is probably okay given the purpose of this >> > detection, but I think it's better to note it explicitly. >> >> Good point. I had some trickiness writing this - how is "The >> techniques describes in this document rely on (DNSSEC validating) >> resolvers responding with SERVFAIL (RCODE 2) to valid answers. Note >> that a slew of other issues can also cause SERVFAIL responses, so >> false positive or negative results may sometimes occur." ? > > Works for me, except that I might avoid 'false positive/negative' as > it's often ambiguous or confusing (exactly what "false positive" means > depends on the context). I'd personally say something like "..., so > the sentinel processing (Section 4) may sometimes result in incorrect > conclusions". But that's probably minor in the entire context of this > document, so I'd leave it to you.
Thanks, I changed it (in the editor copy) to ", so the sentinel processing (Section 4) may sometimes result in incorrect conclusions". When I initially added the false positive/false negative text I spent some time trying to figure out if it was a false positive or false negative... and then just listed both :-) > >> > - Section 3 >> > >> > [...] Note >> > that the <tag-index> is specified in the DNS label using hexadecimal >> > notation. >> > >> > I suggest clarifying whether '<tag-index>' contains leading 0s >> > somewhere in the document (this may not be the best place to do so, >> > but this is the first reference to 'tag-index' that made the >> > question occur to me). >> >> Hmmm... Good point. I personally actually preferred having these as >> "decimal" keys. >> RFC1034, Sec 5.3: The DS RR Presentation Format sayeth: >> " The Key Tag field MUST be represented as an unsigned decimal >> integer.", things like dig +multiline DNSKEY . shows it as decimal, >> etc. >> My initial demos (www.ksk-test.net) also all used decimal. Petr >> recently pointed out to me that I'd messed up, and so I converted my >> demo to use hex, as the draft states. >> What does the WG prefer? Is the new KSK called "20326" or it is "4f66"? >> >> Note that Knot Resolver 2.1 already implements (thank you!) this, and as >> hex. >> But, yes, either way, we need to note if it is padded. >> [TODO(WK): Raise the hex vs Dec issue] > > Personally I don't have a strong opinion/preference on hex vs decimal > or with or without leading zeros as long as it's clearly specified. > But I see the point of preferring the decimal representation you > showed above. https://data.iana.org/root-anchors/root-anchors.xml > also uses the decimal representation, so especially if we expect the > usage of this query by a human operator who builds the query name by > hand, it would be more convenient if it's consistent with other common > representations, which is currently decimal. But again, I don't have > a strong opinion. I'll start a separate thread on this question. I have a feeling that I'm bikeshedding here, but decimal seems preferable to me. > >> > - Section 3 >> > >> > If the resolver has not placed a >> > Root Zone Key Signing Key with tag index value matching the value >> > specified in the query into the local resolver's store of trusted >> > keys, then the resolver should return a response indicating that the >> > response contains authenticated data according to section 5.8 of >> > [RFC6840]. >> > >> > Should we perhaps define "store of trusted keys" more precisely? >> > For example, if a key is in the "AddPend" status (per RFC5011) for >> > the resolver, should it be considered in the "store of trusted >> > keys"? >> >> Nope. Well, yes, we need to better define it, but no, a key in AddPend >> is not considered. >> We explicitly mean "keys which are active and can be used for >> validating entries in the root zone." > > To be clear, I didn't think a key in the "AddPend" state is considered > to be in the "store of trusted keys". I just pointed out that it may > not be super clear. And so... Yup - you are right, it wasn't super clear (and I'd assumed that you didn't think that AddPend counted, but it doesn't hurt to clarify in the doc). Thanks. > >> We have: "In particular, this response mechanism can be used to >> determine whether a certain Root Zone KSK is ready to be used as a >> trusted key within the context of a key roll by this resolver." >> and I added: >> "An active key is one which could currently be used for validation (ie >> not in AddPend or Revoked state (RFC5011)). >> >> Sounds reasonable? > > yes it does. Yay! > >> > BTW, you might want to say 'a query for an Address Record' or 'an >> > Address Record query' instead of 'an A or AAAA query' (I guess >> > that's the intent of the introduction of this term. See also my >> > first comment on Section 1.1 above). >> >> Actually, there are small enough number of occurrences that explicitly >> listing them (and not creating a new term) seemed better, so (see >> ablove) I removed the "Address Record" term and left in the "A or >> AAAA" stuff - please let me know if you agree. > > Works for me. Excellent! W > > -- > JINMEI, Tatuya -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
