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: > > > > Mark, > > > > At 2016-04-07 20:48:43 -0300 > > Mark Andrews <ma...@isc.org> wrote: > > > >> Warren. In both cases receiving a query with either a option or a > >> qname encoding ids it is a indication that the IP address or the > >> clients behind the IP address have the trust anchor configured. You > >> may receive a option without the recursive server actually validating. > >> > >> As far as I can see both options provide the same information. > > > > Actually using a QNAME does provide more information, since it can > > reveal validators behind a resolver with different trust anchors. > > Shane, > > Can you explain your reasoning some more, or what you mean by different? > > Do you mean a stub and its recursive having different trust anchors? Or > do you mean two different stubs with different trust anchors? > > As I see it both approaches reveal multiple trust anchors behind a single > IP, but the EDNS0 approach can reveal the "order" of trust anchors. > > > > > > 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. You also need to maintain a seperate cache just for these tag values. Even if you get multiple sets there is nothing that says the first must be the resolvers just that all sets should be included. > 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]. > 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? strncasecmp(buf, "v=spf1", 6) + buf[6] == 0 || buf[6] == ' ' is basically all that is used to pull out SPF records out of txt records after collapsing the rdata into a single buffer. > DW > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
