Duane, Apologies for the late reply.
At 2016-04-13 15:53:43 +0000 "Wessels, Duane" <dwess...@verisign.com> wrote: > > 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. > > 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? I meant the first. I thought that the stub's trust anchor will be revealed by QNAME, but not by EDNS. Looking at the draft I see that I was wrong. :( > 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. Yes, this is true. I don't know if this is useful information, but it actually is more information! :) > > 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. > > 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. Agreed. > > (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 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. Possibly a HMAC of the trust anchors used, with the string "Whoops, we should have done this in 2010" as the secret key? And then also the human-readable secret key, so I can read it. ;) Cheers, -- Shane
pgpf8MNQf7BK6.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
