> On Apr 13, 2016, at 1:56 PM, Mark Andrews <ma...@isc.org> wrote: > > > In message <ce7457e3-2094-4801-85e5-2b3fdd6c0...@verisign.com>, "Wessels, > Duane" writes: >> >>> On Apr 13, 2016, at 6:54 AM, Shane Kerr <sh...@time-travellers.org> >> wrote: >> >>> >>> While the QNAME approach does feel a bit like a hack, I have to admit >>> that it probably is slightly better. I can't even think of useful >>> information that having both approaches would add.... >> >> >> There is one difference. With the EDNS0 approach (as written) if you have >> a validating stub (or other client) and a validating recursive, then you'd >> get two sets of key tags in one message. So this would tell you that >> there are two validators in that resolution chain. > > No, you may get two sets and only when they differ.
No, the -01 of the draft says: the recursive resolver SHOULD transmit the two Key Tag lists using separate instances of the edns-key-tag option code in the OPT meta-RR. (It doesn't say they can be collapsed if identical) > You also need > to maintain a seperate cache just for these tag values. I'm not sure where you get this idea. The draft does not say that. > Even if > you get multiple sets there is nothing that says the first must be > the resolvers just that all sets should be included. True the draft does not specify ordering, but it easily could. > >> With the QNAME approach the two validators would send independent queries >> and they would not be so strongly linked. >> >> Having said that, I don't think this difference is important enough to >> justify EDNS0 over QNAME. That is, its hard for me to imagine that the >> information provided by this difference would affect the go/no-go progress >> of a rollover. >> >>> (I do think that using human-readable key tags in the QNAME approach >>> makes sense, as someone suggested in the WG session. Because I am a >>> human, and don't care about 1 or 2 extra bytes for these relatively rare >>> queries, but I do care about being able to check logs without >>> running them through my secret decoder ring...) > > I care about being able to fit more tags into a single label. It > is only 63 octets which gives 14 hex tag values [(63 - 4) / 4] compared > with 10 when using decimals and a value seperator [(63 - 4 - 5) / 6 + 1] > or 11 if you just zero pad to width 5 and no seperator [(63 - 4) / 5]. Seems like plenty to me. And the draft does say this: It is RECOMMENDED that implementations place reasonable limits on the number of Key Tags to include in the outgoing edns-key-tag option. > >> I don't have a strong opinion about hex/decimal, human readable, etc. >> >> I do feel strongly that the QNAME approach should have a lot of "signal" >> in order to separate real data from random noise. i.e., the signal could >> take the form of punctuation, keywords, or check digit. > > So label length % 4 == 0 + strncasecmp(label, "_ta-", 4) == 0 + type > == NULL + suffix == zone name + label suffix is all hexdigits is > not enough to pull it out of a query stream? Actually I forgot that you proposed using QTYPE=NULL which I think is a good enough signal. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
