On Thu, Oct 11, 2018 at 10:27:57AM -0700, pg...@dev-mail.net wrote:
> Can you comment just a bit further on 'ready'?
By "ready" I mean that it has a working "rfc5011" key rollover
implementation, and so has already long added KSK2017 to its list
of root trust anchors. Or alternatively, that some attentive
administrator has manually updated the trust-anchor file.
> Oct 11 10:09:00 ns01 named[4116]: 11-Oct-2018 10:09:00.435 resolver:
> debug 1: fetch: google.com/A
> Oct 11 10:09:00 ns01 named[4116]: 11-Oct-2018 10:09:00.484 dnssec:
> info: view internal: validating com/DS: bad cache hit (./DNSKEY)
> Oct 11 10:09:00 ns01 named[4116]: 11-Oct-2018 10:09:00.484
> lame-servers: info: broken trust chain resolving 'google.com/A/IN':
> 2001:4860:4802:36::a#53
> Oct 11 10:09:00 ns01 named[4116]: 11-Oct-2018 10:09:00.484
> query-errors: debug 1: client @0x7efc441cd640 ::1#63498 (google.com): view
> internal: query failed (SERVFAIL) for google.com/IN/A at query.c:10692
> ...
This does not look like a forwarder problem, your own trusted key
list is not up to date. Either it is manually maintained, or
automated updates are failing (perhaps permission problems to update
the files, the keys need to be writable by the running nameserver).
> Which seems related to the key roll.
Definitely.
> Changing my local dns (named) config to
>
> - dnssec-enable yes;
> + dnssec-enable no;
> dnssec-lookaside no;
> - dnssec-validation yes;
> + dnssec-validation no;
>
> gets me back up & running, without DNSSEC of course.
>
> > As cached data expires, this should make its way into all working
> caches over the next day or two
>
> Is 'ready' simply .... 'wait awhile' ?
Waiting won't fix anything, you need to fix the trust anchor
management on your system.
--
Viktor.
