This may help https://www.icann.org/dns-resolvers-checking-current-trust-anchors
Jamie October 11, 2018 11:59 AM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote: > 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.
