kres_modules/prefill.lua:186: [prefill] configuration must be in table {owner name = {per-zone config}}

Hi,

I am getting this issue with:

prefill.config({['.'] = {url = 'https://www.internic.net/domain/root.zone', ca_file = '/etc/ssl/certs/ca-certificates.crt', interval = 86400}})

I have the following modules:

modules = {
  'policy',
  'view',
  'hints',
  'prefill',
  'serve_stale < cache',
  'workarounds < iterate',
  'stats',
  'predict'
}

But with the prefill.config, I get: 'kres_modules/prefill.lua:186: [prefill] configuration must be in table {owner name = {per-zone config}}'

And yet, it is the one provided in https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling.

I see... that's a bug. When loading prefill through the modules = { syntax, it assumes it already has configuration even if it does not. This does not happen when loaded with the modules.load('prefill') syntax.

Still, it works for me either way, only it additionally prints this incorrect message.

Only this works:

-- Enable optional modules
modules = {
  'policy',
  'view',
  'hints',
  'serve_stale < cache',
  'workarounds < iterate',
  'stats',
  'predict'
}

-- Cache prefilling
modules.load('prefill')
prefill.config({['.'] = {url = 'https://www.internic.net/domain/root.zone', ca_file = '/etc/ssl/certs/ca-certificates.crt', interval = 86400}})

If I don't do this, I have this error:

sept. 05 16:06:02 myhost.example.com systemd[1]: Starting Knot Resolver daemon...
sept. 05 16:06:02 myhost.example.com kresd[1647111]: /usr/lib/knot-resolver/kres_modules/prefill.lua:186: [prefill] configuration must be in table {owner name = {per-zone config}}
sept. 05 16:06:02 myhost.example.com kresd[1647111]: [ ta ] warning: . DNSKEY is missing the SEP bit; flags 256 instead of 257
sept. 05 16:06:02 myhost.example.com systemd[1]: kresd@1.service: Main process exited, code=exited, status=1/FAILURE
sept. 05 16:06:02 myhost.example.com systemd[1]: kresd@1.service: Failed with result 'exit-code'.
sept. 05 16:06:02 myhost.example.com systemd[1]: Failed to start Knot Resolver daemon.

mentioned in merge request !863 (merged)

Ah, right, these problems in configuration file will also fail the startup; I forgot about that. Anyway, I opened MR with a fix: https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/863

In fact it does not even work with your workaround:

sept. 05 16:37:01 myhost.example.com systemd[1]: Started Knot Resolver daemon.
sept. 05 16:37:01 myhost.example.com kresd[1649044]: [prefill] downloading root zone...
sept. 05 16:37:11 myhost.example.com systemd[1]: kresd@1.service: Watchdog timeout (limit 10s)!
sept. 05 16:37:11 myhost.example.com systemd[1]: kresd@1.service: Killing process 1649044 (kresd) with signal SIGABRT.
sept. 05 16:37:12 myhost.example.com systemd[1]: kresd@1.service: Main process exited, code=dumped, status=6/ABRT
sept. 05 16:37:12 myhost.example.com systemd[1]: kresd@1.service: Failed with result 'watchdog'.
sept. 05 16:37:12 myhost.example.com systemd[1]: kresd@1.service: Service RestartSec=100ms expired, scheduling restart.
sept. 05 16:37:12 myhost.example.com systemd[1]: kresd@1.service: Scheduled restart job, restart counter is at 4.

Also in the first case, I don't know lua but: In "if not config or type(config) ~= 'table' then", does this "if not" apply also to the second condition? Which means if not the type of the config arguments is not a table, which means if the type of the config arguments is a table, and in that case, it is a table, so shouldn't be it written this way: "if not config or type(config) == 'table' then".

not is an operator that binds very tightly, i.e. that's not a problem here. Watchdog is a real problem that probably can't be properly solved as easily. Well, you could disable it for now, or increase its limit to an interval that's sufficient to download the whole zone.

Yes, regarding the watchdog issue, I have the above one if my kresd@.service has set WatchdogSec=30s but with WatchdogSec=60s, I am getting the following issue:

sept. 05 17:00:04 myhost.example.com systemd[1]: Started Knot Resolver daemon.
sept. 05 17:00:04 myhost.example.com kresd[1650892]: [prefill] downloading root zone...
sept. 05 17:00:44 myhost.example.com kresd[1650892]: [prefill] cannot download new zone (/usr/lib/knot-resolver/kres_modules/prefill.lua:88: [prefill] fetch of `https://www.internic.net/domain/root.zone` failed: temporary failure in name resolution), will retry root zone download in 09 minutes 54 seconds

I might want currently to disable the root on loopback feature till it works for me :)

Aand yes... your machine apparently uses the same server as the default resolver. Fortunately, using non-blocking fetch should fix that by itself, when we do it.

It's amazing how many issues you managed to find so fast, thanks!

Yes my machine uses the same server as the default resolver. Non-blocking fetch would mean that it will cancel the fetch more quickly in the temporary failure in name resolution case? I would love this Internet Draft to be implemented: https://tools.ietf.org/html/draft-ietf-dnsop-7706bis-05 with the root zone service running on the same server as the recursive resolver.

No... the problem is that the fetch blocks kresd from doing anything else, including the resolution of its own DNS request (routed through the OS). When we unblock that, it should just work.

Implementation details: I expect we'd better convert the fetch to use lua-http library, as it's asynchronous and has a relatively convenient API for this.

assigned to @vcunat

closed via merge request !863 (merged)

mentioned in commit f4bcca85

mentioned in issue #512 (closed)