> On 31 Oct 2017, at 6:34 pm, Tony Finch <d...@dotat.at> wrote: > > Ray Bellis <r...@bellis.me.uk> wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >>> IIRC we discussed it, and were concerned that _ta. could be cached as >>> nonexistent by servers implementing QNAME minimization. >> >> How would that happen, at least so long as _ta responds like any other >> empty non-terminal? > > It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.) > > The problem occurs if you have a validator behind a cache. The cache will > prevent downstream id._ta. queries from reaching the root, so any > downstream trust anchor variation will be lost. >
The mechanism does not rely on these queries reaching the root. It's the signal back to the querier that’s important here. So even caching is quite ok. The critical aspect of this mechanism is that it is not intended to measure resolvers, but detect if an end user has a DNS resolution environment that will (or will not) be impacted by a roll in the KSK to a named (via a key tag value) new KSK. Certainly it would remove some of the QNAME minimisation issues if the test is based on a single label as defined in the draft, and on reflection I _think_ its probably more robust if its the terminal label, but frankly I’m not sure about that latter point. Geoff _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
