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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users