[dns-operations] Preparing resolver operators for the rollover

[Jim Reid]

> On 3 Oct 2017, at 19:49, Paul Hoffman <paul.hoffman at icann.org> wrote:
> 
> It would be helpful if folks here would review the pages and send comments about any changes that you think should be made. They are at:
>   https://www.icann.org/dns-resolvers-checking-current-trust-anchors
>   https://www.icann.org/dns-resolvers-updating-latest-trust-anchor
> 
> Thanks in advance!

Paul, the advice about checking the error code from dig lookups is a little bit misleading. Could you please revise the text?

When a resolver treats validation failures as soft errors -- say val-permissive-mode in unbound or BIND’s dnssec-accept-expired/dnssec-must-be-secure is switched on -- lookups of dnssec-failed.org do not return SERVFAIL. According to the web page above, that means the resolver *isn’t* doing validation => nothing to see here wrt to the root KSK’s new trust anchor. However a resolver like that could be doing validation (albeit ignoring failures) and might only have the original KSK hard-wired into its configuration somehow.

I just found this out. My laptop runs unbound and has val-permissive-mode turned on. Sigh. Since it often finds itself on airport/hotel/coffee shop nets that do Stupid DNS Tricks, unbound on my laptop has to be able to work around such brokenness: eg when DNSSEC RRtypes get mangled or deleted by an idiot firewall or whatever. Therefore, unbound’s configured to tolerate validation failures so I can be sure to get my daily fix of cat videos whenever I’m travelling.

Of course the unbound setup on my laptop does know about the new KSK and is ready for the rollover. But if I had naively followed the advice above, I wouldn't have needed to check the resolver’s TA since it supposedly wasn't doing validation.