In message <88710f7e-4a46-4814-89a9-040a98a79...@verisign.com>, "Wessels, Duane
" writes:
>
> > On Apr 13, 2016, at 1:56 PM, Mark Andrews <ma...@isc.org> wrote:
> >=20
> >=20
> > In message <ce7457e3-2094-4801-85e5-2b3fdd6c0...@verisign.com>, "Wessels,=
> Duane" writes:
> >>=20
> >>> On Apr 13, 2016, at 6:54 AM, Shane Kerr <sh...@time-travellers.org>
> >> wrote:
> >>=20
> >>>=20
> >>> 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....
> >>=20
> >>=20
> >> There is one difference. With the EDNS0 approach (as written) if you ha=
> ve
> >> 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.
> >=20
> > 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.
When a validating recursive resolver receives a query
that includes the edns-key-tag option with a Key Tag list that
differs from its own, it SHOULD forward both the client's Key Tag
list as well as its own.
Note the word "differs".
> (It doesn't say they can be collapsed if identical)
>
>
> > You also need
> > to maintain a seperate cache just for these tag values. =20
>
> I'm not sure where you get this idea. The draft does not say that.
In practice you will need to maintain a cache or the down stream
TAG list will statistically never make it into the upstream query.
> > 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.
>
>
> >=20
> >> With the QNAME approach the two validators would send independent querie=
> s
> >> and they would not be so strongly linked.
> >>=20
> >> 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 progre=
> ss
> >> of a rollover.
> >>=20
> >>> (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 rar=
> e
> >>> queries, but I do care about being able to check logs without
> >>> running them through my secret decoder ring...)
> >=20
> > 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.
> >=20
> >> I don't have a strong opinion about hex/decimal, human readable, etc.
> >>=20
> >> 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 coul=
> d
> >> take the form of punctuation, keywords, or check digit.
> >=20
> > So label length % 4 =3D=3D 0 + strncasecmp(label, "_ta-", 4) =3D=3D 0 + t=
> ype
> > =3D=3D NULL + suffix =3D=3D 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=3DNULL which I think is a=20
> good enough signal. =20
>
> 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
