Hi Hugo, I think your point is widely taken to be true. That is, stub resolvers won’t be fully protected as long as they have one non-validating recursive configured.
Of course it depends on how different stubs are implemented and I doubt anyone can say for sure that they know how all the different stub implementations would behave in such a situation. I certainly wouldn’t fault the ISP for doing an incremental deployment (unless they take a really long time with it). I assume the ISP also controls which recursive name servers are configured on the end user devices (e.g. via DHCP). They could give a subset of their subscribers only the address of the validating recursive and then that subset of users would be fully protected. As they gain confidence they could give it out to more and more subscribers and/or enable validation on the other servers. DW On 6/12/17, 2:15 PM, "Hugo Salgado-Hernández" <[email protected] on behalf of [email protected]> wrote: Dear dnssec-experts. I recently have found a situation where an ISP is doing "incremental rollout" of DNSSEC validation, by means of activating validation on 1 of its 3 resolvers for their customers. Even when it could be a conservative way to help to test load and behaviour for its resolvers, I'm in a discussion if this helps at all at their customers. AFAIK every stub resolver in customer's appliances would never be protected, because a stub receiving a SERVFAIL from the validating resolver for a bogus record, would try with one of the others two, which will deliver the "wrong" answer, cause they're not validating at all. So, 1 of 3 is the same as none, from the customer side. The same with 2. The only real protection will be all resolvers doing validation. Can you confirm this? Is there any research or documentation on the way stubs works that could clarify this issue? Thanks and regards! Hugo
