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. > > - 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. > > - 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... > 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. > > 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. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
