Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

[Peter]

On Sun, Nov 21, 2021 at 06:51:13PM +0100, Sten Carlsen wrote:
! As far as I am aware - and what I have always done - the normal
| thing to do is to use a hints file. Lately the hints are built-in,
| so nothing is really needed.

Ah. Well, I have here a named.conf.sample file that comes with the
distribution, and that shows both ways. And it doesn't seem to say
that one of them would be "normal".

! One question that comes to mind:
! What happens if the slaved root zones are not up to date /not
! correct?

Hm. It depends. When they are not up to date, the question is WHERE
are they not up to date, and why?
When they are not correct - since these are digitally signed
zonefiles, they must be identical everywhere. So if they are not
correct, then I think the Internet has a problem.

Anyway, as long as the roots let me xfer, I do xfer. For me it has a
few advantages: 1. a baseline of proven functionality: xfers do work.
2. I always have a syntactically correct example zonefile on file. 3.
I have them in the backup and can easily see when something was changed.

! might that be the cause?

No. These files are checked/updated about every 15 minutes, and I have
not had any problem with them in more than a decade.
And this error message appears only and exactly once at server start,
no matter if or when these zonefiles have been fetched before.

So, I've just updated OS, so let's have a look at the logs:

Nov 21 17:07:58 <local0.info> pole named[1771]: general: info: shutting down: flushing changes
Nov 21 17:07:58 <local0.notice> pole named[1771]: general: notice: stopping command channel on 127.0.0.1#953
Nov 21 17:07:58 <local0.notice> pole named[1771]: general: notice: exiting
Nov 21 18:04:40 <local0.info> pole named[3722]: zoneload: info: managed-keys-zone: loaded serial 346
Nov 21 18:04:40 <local0.warn> pole named[3722]: dnssec: warning: managed-keys-zone: Failed to create fetch for DNSKEY update
Nov 21 18:04:40 <local0.info> pole named[3722]: zoneload: info: zone ./IN: loaded serial 2021112100 (DNSSEC signed)
Nov 21 18:04:40 <local0.info> pole named[3722]: zoneload: info: zone 10.in-addr.arpa/IN: loaded serial 2021080800
Nov 21 18:04:40 <local0.info> pole named[3722]: zoneload: info: zone arpa/IN: loaded serial 2021112101 (DNSSEC signed)

So, we can see, at first it opens that "managed-keys-zone"
pseudozone. There it detects that it might query the DNSKEY,
and *fails*. Only *after that* it loads the ./IN & friends.

Now if one looks a bit into the running code, the error number is
65586 ( that's what the error message would show if it would show the
error number. :/ ), and in the source this error is defined as
DNS_R_NOTLOADED.

Now let's look further on. Exactly an hour later this appears:

Nov 21 19:04:40 <local0.info> pole named[3722]: dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)

The question would now be: what does it do in the meantime? Does
it distrust the trust-anchor? That's interesting, because without
trust anchor it would likely need to distrust everything.

Lets try that out: shutdown, restart, see the error - and I still
get the AD bit in TLDs. So it seems to have no troublesome effect.


Now lets make something else clear: I am running these machines
since way back into the last century - when it was common to know
*every file* on your machine, and to read the sourcecode within thse
files - and occasionally to even understand it.
And I hold on to that line, because what we have today is worse.


cheerio, PMc