Have 203 running on about 10 firewalls. Pleased with the lower RAM requirements compared to unbound. After running fine most of the day, two of the firewalls stopped supplying DNS resolution until switched from TLS to UDP. Observed with all clients as well as pakfire. No issues as of yet with the other firewalls, all similarly configured.
Please show the system logs for the Domain Name System.
Without logs it’s just guesswork. With logs at least there should be some messages to indicate what knot struggled with.
I have similar issue after upgrade to C203. I cannot use TLS. I see these messages in the /var/log/messages
...
Jul 21 20:18:28 ipfire knot_resolver.controller.supervi: Supervisord is already running, we will just update its config...
Jul 21 20:18:29 ipfire supervisord: spawned: 'policy-loader' with pid 1609
Jul 21 20:18:29 ipfire supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
Jul 21 20:18:29 ipfire kresd[1609]: [cache ] Cache top initialized using existing data (generic).
Jul 21 20:18:29 ipfire kresd[1609]: [system] error while loading config: error occurred here (config filename:lineno is at the bottom, if config is involved): stack traceback: [C]: in function 'tls_client' /usr/lib/knot-resolver/kres_modules/policy.lua:176: in function 'TLS_FORWARD' /usr/lib/knot-resolver/kres_modules/policy.lua:890: in function 'forward_convert_targets' /usr/lib/knot-resolver/kres_modules/policy.lua:922: in function 'rule_forward_add' /usr/lib/knot-resolver/config.lua:243: in function 'load_forwarders' policy-loader.conf:60: in main chunk ERROR: invalid hostname (workdir '/run/knot-resolver')
Jul 21 20:18:29 ipfire supervisord: exited: policy-loader (exit status 1; not expected)
...
Jul 21 21:44:10 ipfire supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
Jul 21 21:44:10 ipfire kresd[10917]: [cache ] Cache top initialized using existing data (generic).
Jul 21 21:44:10 ipfire kresd[10917]: [system] error while loading config: error occurred here (config filename:lineno is at the bottom, if c
onfig is involved): stack traceback: [C]: in function 'tls_client' /usr/lib/knot-resolver/kres_modules/policy.lua:176: in function 'TLS
_FORWARD' /usr/lib/knot-resolver/kres_modules/policy.lua:890: in function 'forward_convert_targets' /usr/lib/knot-resolver/kres_
modules/policy.lua:922: in function 'rule_forward_add' /usr/lib/knot-resolver/config.lua:243: in function 'load_forwarders' policy-loade
r.conf:60: in main chunk ERROR: invalid hostname (workdir '/run/knot-resolver')
Jul 21 21:44:10 ipfire supervisord: exited: policy-loader (exit status 1; not expected)
Jul 21 21:44:11 ipfire knot_resolver.manager.server: Reloading of the configuration file failed: Configuration validation failed. The reason
s are: - kresd 'policy-loader' process exited unexpectedly. The configuration may be invalid. Please check the log.
Jul 21 21:44:11 ipfire knot_resolver.manager.server: Configuration has NOT been changed.
...
Config is simple (I changed NS from TLS to UDP)
[root@ipfire /]# ls -ltr /var/ipfire/dnsforward/
total 0
-rw-r--r-- 1 nobody nobody 0 Apr 21 12:39 config
[root@ipfire /]# ls -ltr /var/ipfire/dns/
total 12
-rw-r--r-- 1 nobody nobody 0 Apr 21 12:39 dnsbl
-rw-r--r-- 1 nobody nobody 0 Apr 21 12:39 custom_domains
-rw-r--r-- 1 nobody nobody 3141 May 21 19:39 dnsbl.json
-rw-r--r-- 1 nobody nobody 288 Jul 21 21:43 servers
-rw-r--r-- 1 nobody nobody 87 Jul 21 21:44 settings
[root@ipfire /]# cat /var/ipfire/dns/settings
PROTO=UDP
ENABLE_SAFE_SEARCH_YOUTUBE=on
ENABLE_SAFE_SEARCH=off
USE_ISP_NAMESERVERS=off
[root@ipfire /]# ls -ltr /var/ipfire/main/hosts
-rw-r--r-- 1 nobody nobody 0 Apr 21 12:39 /var/ipfire/main/hosts
[root@ipfire /]# hostname
ipfire.home
Does the problem occur with safe_search disabled also?
This information could help to find the error cause.
EDIT: with a simple test ( enable safe_search, toggle protocol between UDP and TLS ) I cannot reproduce the error.
There must be some other config entry firing the error.
I cannot explain why but DNS start to work with TLS mode active. Maybe I did one more reboot, maybe I fixed DNS configuration.
There was a confusing error, check DNS in TLS mode, it reported ERROR. The issue was that TLS hostname of resolvers were not filled (that field is mandatory in TLS mode), so I fixed that configuration, and now “DNS check in TLS mode” reports OK and I can use DNS in TLS mode.
I used DNS in TLS mode with unbound and I had not filled TLS hostnames of DNS servers and there was no issue. Maybe this was a showstopper for DNS in TLS with knot…
UPDATE. I was WRONG, DNS in TLS mode is still not working. I had to switch mode to UDP. When mode is TLS, computer in green network cannot use DNS… I fixed only “check DNS” error (I added TLS hostnames).
user@linux:~$ host google.com
Host google.com not found: 2(SERVFAIL)
[root@ipfire /]# host google.com
Host google.com not found: 2(SERVFAIL)
DNS is configured in TLS mode, just one DNS server (9.9.9.9). The same issue with server 1.1.1.1.
I changed logging level from info to debug in file /etc/knot-resolver/config.yaml
[root@ipfire /]# host debian.org
Host debian.org not found: 2(SERVFAIL)
/var/log/messages:
...
Jul 22 00:31:43 ipfire kresd[10178]: [prlayr] [00000001] (in) Wire buffer submitted to grp 'DNS UDP' in unwrap direction (0: UDP)
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | 127.0.0.1#43311 UNWRAP
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | unverified address
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | CONTINUE
Jul 22 00:31:43 ipfire kresd[10178]: [plan ][00000.00] plan 'debian.org.' type 'A' uid [06465.00]
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.00] 'debian.org.' type 'A' new uid was assigned .01, parent uid .00
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.01] => no NSEC* cached for zone: org.
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.01] => skipping zone: org., NSEC, hash 0;new TTL -123456789, ret -2
Jul 22 00:31:43 ipfire last message buffered 1 times
Jul 22 00:31:43 ipfire kresd[10178]: [plan ][06465.01] plan '.' type 'DNSKEY' uid [06465.02]
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.02] '.' type 'DNSKEY' new uid was assigned .03, parent uid .01
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.03] => satisfied by exact RRset: rank 060, new TTL 22884
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.03] <= rcode: NOERROR
Jul 22 00:31:43 ipfire kresd[10178]: [valdtr][06465.03] <= parent: updating DNSKEY
Jul 22 00:31:43 ipfire kresd[10178]: [valdtr][06465.03] <= answer valid, OK
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.01] 'debian.org.' type 'A' new uid was assigned .04, parent uid .00
Jul 22 00:31:43 ipfire kresd[10178]: [plan ][06465.04] plan 'org.' type 'DS' uid [06465.05]
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.05] 'org.' type 'DS' new uid was assigned .06, parent uid .04
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.06] => satisfied by exact RRset: rank 060, new TTL 73009
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.06] <= rcode: NOERROR
Jul 22 00:31:43 ipfire kresd[10178]: [valdtr][06465.06] <= DS: OK
Jul 22 00:31:43 ipfire kresd[10178]: [valdtr][06465.06] <= parent: updating DS
Jul 22 00:31:43 ipfire kresd[10178]: [valdtr][06465.06] <= answer valid, OK
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.04] 'debian.org.' type 'A' new uid was assigned .07, parent uid .00
Jul 22 00:31:43 ipfire kresd[10178]: [plan ][06465.07] plan 'org.' type 'DNSKEY' uid [06465.08]
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.08] 'org.' type 'DNSKEY' new uid was assigned .09, parent uid .07
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.09] => skipping exact RR: rank 060 (min. 030), new TTL -3227
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.09] => no NSEC* cached for zone: org.
Jul 22 00:31:43 ipfire kresd[10178]: [cache ][06465.09] => skipping zone: org., NSEC, hash 0;new TTL -123456789, ret -2
Jul 22 00:31:43 ipfire last message buffered 1 times
Jul 22 00:31:43 ipfire kresd[10178]: [resolv][06465.09] => id: '26379' querying: '.'@'9.9.9.9#00853' zone cut: 'org.' qname: 'org.' qtype: 'DNSKEY' proto: 'tcp'
Jul 22 00:31:43 ipfire kresd[10178]: [worker][06465.09] => connecting to: '9.9.9.9#00853'
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | IDLE
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | deactivate idle
Jul 22 00:31:43 ipfire kresd[10178]: [defer ] | POLL
Jul 22 00:31:43 ipfire kresd[10178]: [worker] => connected to '9.9.9.9#00853'
Jul 22 00:31:43 ipfire kresd[10178]: [prlayr] [00000026] (out) Buffer submitted to grp 'DNS TCP' in wrap direction (3: DNS_MULTI_STREAM)
Jul 22 00:31:43 ipfire kresd[10178]: [prlayr] [00000026] (out) Pushing IOVec
Jul 22 00:31:43 ipfire kresd[10178]: [io ] => connection to '9.9.9.9#00853' closed by peer (end of file)
Jul 22 00:31:43 ipfire kresd[10178]: [select][06465.09] => id: '26379' noting selection error: '.'@'9.9.9.9#00853' zone cut: 'org.' error: 3 TCP_CONNECT_FAILED
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.09] 'org.' type 'DNSKEY' new uid was assigned .10, parent uid .07
Jul 22 00:31:43 ipfire kresd[10178]: [iterat][06465.10] 'org.' type 'DNSKEY' new uid was assigned .11, parent uid .07
Jul 22 00:31:43 ipfire kresd[10178]: [resolv][06465.11] AD: request NOT classified as SECURE
Jul 22 00:31:43 ipfire kresd[10178]: [resolv][06465.07] finished in state: 8, queries: 3, mempool: 16400 B
...
IPFire diagnostics
Section: dns
Date: July 20, 2026
23:56:42 knot_resolver.manager.server: Configuration file successfully reloaded
23:56:42 supervisord: exited: policy-loader (exit status 0; expected)
23:56:39 kresd[13533]: [rules ] skipping out-of-zone record(s); first name .
23:56:39 kresd[13533]: [cache ] Cache top initialized using existing data (AVX2).
23:56:39 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
23:56:39 supervisord: spawned: ‘policy-loader’ with pid 13533
23:56:39 knot_resolver.manager.server: Reloading event triggered…
22:34:03 knot_resolver.manager.server: Configuration file successfully reloaded
22:34:02 supervisord: exited: policy-loader (exit status 0; expected)
22:34:00 kresd[10263]: [rules ] skipping out-of-zone record(s); first name .
22:34:00 kresd[10263]: [cache ] Cache top initialized using existing data (AVX2).
22:34:00 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
22:34:00 supervisord: spawned: ‘policy-loader’ with pid 10263
22:34:00 knot_resolver.manager.server: Reloading event triggered…
21:29:43 knot_resolver.manager.server: Configuration file successfully reloaded
21:29:42 supervisord: exited: policy-loader (exit status 0; expected)
21:29:40 kresd[7766]: [rules ] skipping out-of-zone record(s); first name .
21:29:40 kresd[7766]: [cache ] Cache top initialized using existing data (AVX2).
21:29:40 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
21:29:40 supervisord: spawned: ‘policy-loader’ with pid 7766
21:29:40 knot_resolver.manager.server: Reloading event triggered…
20:16:10 knot_resolver.manager.server: Configuration file successfully reloaded
20:16:09 supervisord: exited: policy-loader (exit status 0; expected)
20:16:07 kresd[4969]: [rules ] skipping out-of-zone record(s); first name .
20:16:07 kresd[4969]: [cache ] Cache top initialized using existing data (AVX2).
20:16:07 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
20:16:07 supervisord: spawned: ‘policy-loader’ with pid 4969
20:16:07 knot_resolver.manager.server: Reloading event triggered…
20:08:28 kresd[1730]: [taupd ] next refresh for . in 12 hours
20:08:28 kresd[1730]: [tasign] signalling query triggered: _ta-4f66-9728.
20:08:28 kresd[1717]: [taupd ] next refresh for . in 12 hours
20:08:28 kresd[1714]: [taupd ] next refresh for . in 12 hours
20:08:28 kresd[1717]: [tasign] signalling query triggered: _ta-4f66-9728.
20:08:28 kresd[1714]: [tasign] signalling query triggered: _ta-4f66-9728.
20:08:28 kresd[1717]: [taupd ] refreshing TA for .
20:08:28 kresd[1730]: [taupd ] refreshing TA for .
20:08:28 kresd[1714]: [taupd ] refreshing TA for .
20:08:27 kresd[1732]: [taupd ] next refresh for . in 12 hours
20:08:27 kresd[1732]: [tasign] signalling query triggered: _ta-4f66-9728.
20:08:27 kresd[1732]: [taupd ] refreshing TA for .
19:10:14 knot_resolver.manager.server: Configuration file successfully reloaded
19:10:14 supervisord: exited: policy-loader (exit status 0; expected)
19:10:11 kresd[2400]: [rules ] skipping out-of-zone record(s); first name .
19:10:11 kresd[2400]: [cache ] Cache top initialized using existing data (AVX2).
19:10:11 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
19:10:11 supervisord: spawned: ‘policy-loader’ with pid 2400
19:10:11 knot_resolver.manager.server: Reloading event triggered…
18:44:16 knot_resolver.manager.server: Configuration file successfully reloaded
18:44:15 supervisord: exited: policy-loader (exit status 0; expected)
18:44:13 kresd[1203]: [rules ] skipping out-of-zone record(s); first name .
18:44:13 kresd[1203]: [cache ] Cache top initialized using existing data (AVX2).
18:44:13 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
18:44:13 supervisord: spawned: ‘policy-loader’ with pid 1203
18:44:13 knot_resolver.manager.server: Reloading event triggered…
17:26:27 knot_resolver.manager.server: Configuration file successfully reloaded
17:26:26 supervisord: exited: policy-loader (exit status 0; expected)
17:26:24 kresd[30615]: [rules ] skipping out-of-zone record(s); first name .
17:26:24 kresd[30615]: [cache ] Cache top initialized using existing data (AVX2).
17:26:24 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
17:26:24 supervisord: spawned: ‘policy-loader’ with pid 30615
17:26:24 knot_resolver.manager.server: Reloading event triggered…
16:31:30 knot_resolver.manager.server: Configuration file successfully reloaded
16:31:29 supervisord: exited: policy-loader (exit status 0; expected)
16:31:27 kresd[28430]: [rules ] skipping out-of-zone record(s); first name .
16:31:27 kresd[28430]: [cache ] Cache top initialized using existing data (AVX2).
16:31:27 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
16:31:27 supervisord: spawned: ‘policy-loader’ with pid 28430
16:31:27 knot_resolver.manager.server: Reloading event triggered…
15:54:37 knot_resolver.manager.server: Configuration file successfully reloaded
15:54:36 supervisord: exited: policy-loader (exit status 0; expected)
15:54:34 kresd[26892]: [rules ] skipping out-of-zone record(s); first name .
15:54:34 kresd[26892]: [cache ] Cache top initialized using existing data (AVX2).
15:54:34 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
15:54:34 supervisord: spawned: ‘policy-loader’ with pid 26892
15:54:34 knot_resolver.manager.server: Reloading event triggered…
14:00:58 knot_resolver.manager.server: Configuration file successfully reloaded
14:00:57 supervisord: exited: policy-loader (exit status 0; expected)
14:00:56 kresd[22386]: [rules ] skipping out-of-zone record(s); first name .
14:00:55 kresd[22386]: [rules ] skipping out-of-zone record(s); first name .
14:00:55 kresd[22386]: [cache ] Cache top initialized using existing data (AVX2).
14:00:55 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
14:00:55 supervisord: spawned: ‘policy-loader’ with pid 22386
14:00:55 knot_resolver.manager.server: Reloading event triggered…
13:07:27 kresd[1717]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1730]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1714]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1732]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1730]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1732]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1730]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1732]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:07:27 kresd[1717]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
13:01:01 knot_resolver.manager.server: Configuration file successfully reloaded
13:01:00 supervisord: exited: policy-loader (exit status 0; expected)
13:00:58 kresd[20003]: [rules ] skipping out-of-zone record(s); first name .
13:00:58 kresd[20003]: [cache ] Cache top initialized using existing data (AVX2).
13:00:57 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
13:00:57 supervisord: spawned: ‘policy-loader’ with pid 20003
13:00:57 knot_resolver.manager.server: Reloading event triggered…
12:03:04 knot_resolver.manager.server: Configuration file successfully reloaded
12:03:04 supervisord: exited: policy-loader (exit status 0; expected)
12:03:01 kresd[17683]: [rules ] skipping out-of-zone record(s); first name .
12:03:01 kresd[17683]: [cache ] Cache top initialized using existing data (AVX2).
12:03:01 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
12:03:01 supervisord: spawned: ‘policy-loader’ with pid 17683
12:03:01 knot_resolver.manager.server: Reloading event triggered…
11:48:09 knot_resolver.manager.server: Configuration file successfully reloaded
11:48:08 supervisord: exited: policy-loader (exit status 0; expected)
11:48:06 kresd[17052]: [rules ] skipping out-of-zone record(s); first name .
11:48:06 kresd[17052]: [rules ] skipping out-of-zone record(s); first name .
11:48:06 kresd[17052]: [cache ] Cache top initialized using existing data (AVX2).
11:48:06 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
11:48:06 supervisord: spawned: ‘policy-loader’ with pid 17052
11:48:06 knot_resolver.manager.server: Reloading event triggered…
11:10:36 kresd[1732]: [rules ] => local data applied, user: 192.168.160.192, name: d3e54v103j8qbb.cloudfront.net.
11:10:36 kresd[1714]: [rules ] => local data applied, user: 192.168.160.192, name: d3e54v103j8qbb.cloudfront.net.
11:10:36 kresd[1732]: [rules ] => local data applied, user: 192.168.160.192, name: d3e54v103j8qbb.cloudfront.net.
11:10:36 kresd[1730]: [rules ] => local data applied, user: 192.168.160.192, name: d3e54v103j8qbb.cloudfront.net.
10:52:24 knot_resolver.manager.server: Configuration file successfully reloaded
10:52:23 supervisord: exited: policy-loader (exit status 0; expected)
10:52:21 kresd[14515]: [rules ] skipping out-of-zone record(s); first name .
10:52:21 kresd[14515]: [cache ] Cache top initialized using existing data (AVX2).
10:52:21 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
10:52:21 supervisord: spawned: ‘policy-loader’ with pid 14515
10:52:21 knot_resolver.manager.server: Reloading event triggered…
09:42:29 knot_resolver.manager.server: Configuration file successfully reloaded
09:42:29 supervisord: exited: policy-loader (exit status 0; expected)
09:42:26 kresd[11708]: [rules ] skipping out-of-zone record(s); first name .
09:42:26 kresd[11708]: [cache ] Cache top initialized using existing data (AVX2).
09:42:26 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
09:42:26 supervisord: spawned: ‘policy-loader’ with pid 11708
09:42:26 knot_resolver.manager.server: Reloading event triggered…
09:04:37 kresd[1732]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
09:04:37 kresd[1730]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
09:04:37 kresd[1717]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
09:04:37 kresd[1732]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
09:04:37 kresd[1717]: [rules ] => local data applied, user: 192.168.160.58, name: d3e54v103j8qbb.cloudfront.net.
09:02:30 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:02:30 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:01:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:01:15 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:01:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:00:56 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:00:56 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:00:56 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:00:56 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
09:00:56 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:59:09 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:59:09 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:59:09 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:57:43 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:57:43 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:57:43 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:57:43 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:57:43 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:56:51 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:56:51 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:56:51 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:56:51 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:51:13 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:51:13 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:51:13 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:51:13 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:50:22 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:50:22 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:50:22 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:50:22 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:47:59 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:47:59 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:47:59 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:47:59 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:47:59 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:46:39 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:46:39 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:46:39 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:46:39 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:53 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:53 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:53 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:49 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:49 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:49 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:49 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:44:49 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:43:07 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:43:07 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:43:07 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:47 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:47 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:47 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:47 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:39 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:39 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:39 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:42:39 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:52 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:39:52 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:39:52 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:39:52 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:39:51 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:51 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:51 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:51 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:51 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:51 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:51 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:51 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:28 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:28 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:28 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:15 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:15 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:15 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:15 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:14 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:14 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:14 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: fw-cdn.com.
08:39:14 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:14 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:12 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:12 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:12 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:12 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:12 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:11 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:11 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:11 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:10 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:10 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:10 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:39:03 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:36:00 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:36:00 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:36:00 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:59 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:59 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:59 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:59 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:54 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:54 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:43 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:43 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:43 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:16 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:16 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:16 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:35:16 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:58 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:58 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:58 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:58 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:29 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:29 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:29 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:29 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:34:15 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:34:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:34:15 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:34:15 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: monitor.clickcease.com.
08:34:14 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:14 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:14 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:34:14 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:33 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:33 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:00 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:00 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:00 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:33:00 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1714]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:30:30 kresd[1730]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:28:51 kresd[1732]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:28:51 kresd[1717]: [rules ] => local data applied, user: 192.168.160.187, name: d3e54v103j8qbb.cloudfront.net.
08:24:28 knot_resolver.manager.server: Configuration file successfully reloaded
08:24:27 supervisord: exited: policy-loader (exit status 0; expected)
08:24:25 kresd[7591]: [rules ] skipping out-of-zone record(s); first name .
08:24:25 supervisord: spawned: 'policy-loader' with pid 7591
08:24:25 knot_resolver.manager.server: Reloading event triggered...
08:08:28 kresd[1714]: [taupd ] next refresh for . in 12 hours
08:08:28 kresd[1717]: [taupd ] next refresh for . in 12 hours
08:08:28 kresd[1730]: [taupd ] next refresh for . in 12 hours
08:08:28 kresd[1714]: [tasign] signalling query triggered: _ta-4f66-9728.
08:08:28 kresd[1717]: [tasign] signalling query triggered: _ta-4f66-9728.
08:08:28 kresd[1730]: [tasign] signalling query triggered: _ta-4f66-9728.
08:08:28 kresd[1714]: [taupd ] refreshing TA for .
08:08:28 kresd[1717]: [taupd ] refreshing TA for .
08:08:28 kresd[1730]: [taupd ] refreshing TA for .
08:08:27 kresd[1732]: [taupd ] next refresh for . in 12 hours
08:08:27 kresd[1732]: [tasign] signalling query triggered: _ta-4f66-9728.
08:08:27 kresd[1732]: [taupd ] refreshing TA for .
07:44:44 knot_resolver.manager.server: Configuration file successfully reloaded
07:44:43 supervisord: exited: policy-loader (exit status 0; expected)
07:44:41 kresd[5146]: [rules ] skipping out-of-zone record(s); first name .
07:44:41 kresd[5146]: [cache ] Cache top initialized using existing data (AVX2).
07:44:41 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:44:41 supervisord: spawned: 'policy-loader' with pid 5146
07:44:41 knot_resolver.manager.server: Reloading event triggered...
07:08:32 knot_resolver.manager.server: Configuration file successfully reloaded
07:08:32 supervisord: exited: policy-loader (exit status 0; expected)
07:08:30 kresd[2138]: [rules ] skipping out-of-zone record(s); first name .
07:08:30 kresd[2138]: [rules ] skipping out-of-zone record(s); first name .
07:08:30 kresd[2138]: [cache ] Cache top initialized using existing data (AVX2).
07:08:29 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:08:29 supervisord: spawned: 'policy-loader' with pid 2138
07:08:29 knot_resolver.manager.server: Reloading event triggered...
07:08:28 kresd[1717]: [timesk] cannot resolve '.' NS
07:08:28 kresd[1730]: [taupd ] next refresh for . in 1 hours
07:08:28 kresd[1714]: [taupd ] next refresh for . in 1 hours
07:08:28 kresd[1730]: [taupd ] active refresh failed for . with rcode: 2
07:08:28 kresd[1714]: [taupd ] active refresh failed for . with rcode: 2
07:08:28 kresd[1730]: [timesk] cannot resolve '.' NS
07:08:28 kresd[1714]: [timesk] cannot resolve '.' NS
07:08:28 kresd[1717]: [taupd ] next refresh for . in 1 hours
07:08:28 kresd[1717]: [taupd ] active refresh failed for . with rcode: 2
07:08:27 kresd[1732]: [taupd ] next refresh for . in 1 hours
07:08:27 kresd[1732]: [taupd ] active refresh failed for . with rcode: 2
07:08:27 kresd[1732]: [timesk] cannot resolve '.' NS
07:08:23 supervisord: captured stdio output from cache-gc[1733]: Knot Resolver Cache Garbage Collector, version 6.4.0
07:08:23 supervisord: success: manager entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:23 knot_resolver.manager.server: Manager fully initialized and running in 3.924 seconds
07:08:23 knot_resolver.manager.server: Starting API HTTP server on http+unix:///run/knot-resolver/kres-api.sock
07:08:23 knot_resolver.manager.server: Initial configuration applied. Process manager initialized...
07:08:23 knot_resolver.manager.manager: Config applied successfully to all workers
07:08:23 supervisord: success: cache-gc entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:08:23 supervisord: spawned: 'cache-gc' with pid 1733
07:08:23 kresd[1732]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1732]: [taupd ] refreshing TA for .
07:08:23 kresd[1732]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 supervisord: success: kresd3 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:23 kresd[1732]: [defer ] Using existing defer data (AVX2).
07:08:23 kresd[1732]: [cache ] Cache top initialized using existing data (AVX2).
07:08:23 kresd[1732]: [system] path = /run/knot-resolver/control/3
07:08:23 supervisord: spawned: 'kresd3' with pid 1732
07:08:23 kresd[1730]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1730]: [taupd ] refreshing TA for .
07:08:23 supervisord: success: kresd2 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:23 kresd[1730]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1730]: [defer ] Using existing defer data (AVX2).
07:08:23 kresd[1730]: [cache ] Cache top initialized using existing data (AVX2).
07:08:23 kresd[1730]: [system] path = /run/knot-resolver/control/2
07:08:23 supervisord: spawned: 'kresd2' with pid 1730
07:08:23 kresd[1717]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1717]: [taupd ] refreshing TA for .
07:08:23 kresd[1717]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 supervisord: success: kresd1 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:23 kresd[1717]: [defer ] Using existing defer data (AVX2).
07:08:23 kresd[1717]: [cache ] Cache top initialized using existing data (AVX2).
07:08:23 kresd[1717]: [system] path = /run/knot-resolver/control/1
07:08:23 supervisord: spawned: 'kresd1' with pid 1717
07:08:23 kresd[1714]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1714]: [taupd ] refreshing TA for .
07:08:23 kresd[1714]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 supervisord: success: kresd0 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:23 kresd[1714]: [defer ] Defer configuration: Expected cpus/procs: 4 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
07:08:23 kresd[1714]: [defer ] Defer initialized (AVX2).
07:08:23 kresd[1714]: [defer ] Initializing defer...
07:08:23 kresd[1714]: [cache ] Cache top initialized using existing data (AVX2).
07:08:23 kresd[1714]: [system] path = /run/knot-resolver/control/0
07:08:23 supervisord: spawned: 'kresd0' with pid 1714
07:08:23 supervisord: stopped: kresd0 (exit status 0)
07:08:23 kresd[1713]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1713]: [taupd ] refreshing TA for .
07:08:23 kresd[1713]: [io ] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:22 supervisord: waiting for kresd0 to stop
07:08:22 supervisord: success: kresd0 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:08:22 kresd[1713]: [defer ] Defer configuration: Expected cpus/procs: 4 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
07:08:22 kresd[1713]: [defer ] Defer initialized (AVX2).
07:08:22 kresd[1713]: [defer ] Initializing defer...
07:08:22 kresd[1713]: [cache ] Cache top initialized using existing data (AVX2).
07:08:22 kresd[1713]: [system] path = /run/knot-resolver/control/0
07:08:22 supervisord: spawned: 'kresd0' with pid 1713
07:08:22 supervisord: exited: policy-loader (exit status 0; expected)
07:08:20 kresd[1709]: [rules ] skipping out-of-zone record(s); first name .
07:08:19 kresd[1709]: [cache ] Cache top initialized using existing data (AVX2).
07:08:19 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:08:19 supervisord: spawned: 'policy-loader' with pid 1709
07:08:19 knot_resolver.controller.supervi: Supervisord is already running, we will just update its config...
07:08:19 knot_resolver.controller: Selected controller 'supervisord'
07:08:19 knot_resolver.controller: Available subprocess controllers are ('supervisord',)
07:08:19 knot_resolver.controller: Starting service manager auto-selection...
07:08:19 knot_resolver.manager.logger: Changing logging level to 'INFO'
07:08:19 knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
07:08:18 supervisord: spawned: 'manager' with pid 1706
07:08:17 supervisord: notify: injected $NOTIFY_SOCKET into event loop
07:08:17 supervisord: supervisord started with pid 1663
07:08:17 supervisord: Server 'unix_http_server' running without any HTTP authentication checking
07:08:17 supervisord: RPC interface 'fast' initialized
07:08:17 supervisord: RPC interface 'supervisor' initialized
07:08:17 supervisord: RPC interface 'sd_notify' initialized
07:08:17 supervisord: RPC interface 'manager_integration' initialized
07:08:17 supervisord: RPC interface 'patch_logger' initialized
07:08:17 knot_resolver.manager.server: Exec requested with arguments: ['/usr/bin/supervisord', 'supervisord', '--configuration', '/run/knot-resolver/supervisord.conf']
07:08:17 knot_resolver.controller.supervi: We want supervisord to restart us when needed, we will therefore exec() it and let it start us again.
07:08:17 knot_resolver.controller: Selected controller 'supervisord'
07:08:17 knot_resolver.controller: Available subprocess controllers are ('supervisord',)
07:08:17 knot_resolver.controller: Starting service manager auto-selection...
07:08:17 knot_resolver.manager.logger: Changing logging level to 'INFO'
07:08:17 knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
07:07:15 supervisord: stopped: cache-gc (exit status 0)
07:07:15 supervisord: stopped: kresd0 (exit status 0)
07:07:15 supervisord: stopped: kresd3 (exit status 0)
07:07:15 supervisord: stopped: kresd2 (exit status 0)
07:07:15 supervisord: stopped: kresd1 (exit status 0)
07:07:15 supervisord: stopped: manager (exit status 0)
07:07:15 knot_resolver.manager.server: The manager run for 126 seconds...
07:07:15 knot_resolver.manager.server: Stopping kresd manager...
07:07:15 knot_resolver.manager.server: Stopping API service...
07:07:15 supervisord: ignoring ready notification from unregistered PID=29170
07:07:15 knot_resolver.manager.server: Received SIGINT, triggering graceful shutdown
07:07:14 supervisord: waiting for cache-gc, kresd0, kresd1, kresd2, kresd3, manager to die
07:07:14 supervisord: received SIGTERM indicating exit request
07:05:51 knot_resolver.manager.server: Configuration file successfully reloaded
07:05:51 supervisord: exited: policy-loader (exit status 0; expected)
07:05:49 kresd[31723]: [rules ] skipping out-of-zone record(s); first name .
07:05:48 kresd[31723]: [rules ] skipping out-of-zone record(s); first name .
07:05:48 kresd[31723]: [cache ] Cache top initialized using existing data (AVX2).
07:05:48 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:05:48 supervisord: spawned: 'policy-loader' with pid 31723
07:05:48 knot_resolver.manager.server: Reloading event triggered...
07:05:11 kresd[29220]: [taupd ] next refresh for . in 12 hours
07:05:11 kresd[29220]: [tasign] signalling query triggered: _ta-4f66-9728.
07:05:11 kresd[29220]: [timesk] Local system time "Mon Jul 20 07:05:11 2026" is within RRSIG validity interval <"Mon Jul 20 00:00:00 2026","Sun Aug 2 01:00:00 2026">.
07:05:11 supervisord: captured stdio output from cache-gc[29221]: Knot Resolver Cache Garbage Collector, version 6.4.0
07:05:11 supervisord: success: manager entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:11 knot_resolver.manager.server: Manager fully initialized and running in 1.57 seconds
07:05:11 knot_resolver.manager.server: Starting API HTTP server on http+unix:///run/knot-resolver/kres-api.sock
07:05:11 knot_resolver.manager.server: Initial configuration applied. Process manager initialized...
07:05:11 knot_resolver.manager.manager: Config applied successfully to all workers
07:05:11 supervisord: success: cache-gc entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:05:11 supervisord: spawned: 'cache-gc' with pid 29221
07:05:11 supervisord: success: kresd3 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:11 kresd[29220]: [taupd ] refreshing TA for .
07:05:11 kresd[29220]: [defer ] Using existing defer data (AVX2).
07:05:11 kresd[29220]: [cache ] Cache top initialized using existing data (AVX2).
07:05:11 kresd[29219]: [taupd ] next refresh for . in 12 hours
07:05:11 kresd[29219]: [tasign] signalling query triggered: _ta-4f66-9728.
07:05:11 kresd[29219]: [timesk] Local system time "Mon Jul 20 07:05:11 2026" is within RRSIG validity interval <"Mon Jul 20 00:00:00 2026","Sun Aug 2 01:00:00 2026">.
07:05:10 kresd[29220]: [system] path = /run/knot-resolver/control/3
07:05:10 supervisord: spawned: 'kresd3' with pid 29220
07:05:10 supervisord: success: kresd2 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:10 kresd[29219]: [taupd ] refreshing TA for .
07:05:10 kresd[29219]: [defer ] Using existing defer data (AVX2).
07:05:10 kresd[29219]: [cache ] Cache top initialized using existing data (AVX2).
07:05:10 kresd[29218]: [timesk] Local system time "Mon Jul 20 07:05:10 2026" is within RRSIG validity interval <"Mon Jul 20 00:00:00 2026","Sun Aug 2 01:00:00 2026">.
07:05:10 kresd[29218]: [taupd ] next refresh for . in 12 hours
07:05:10 kresd[29218]: [tasign] signalling query triggered: _ta-4f66-9728.
07:05:10 kresd[29219]: [system] path = /run/knot-resolver/control/2
07:05:10 supervisord: spawned: 'kresd2' with pid 29219
07:05:10 supervisord: success: kresd1 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:10 kresd[29218]: [taupd ] refreshing TA for .
07:05:10 kresd[29218]: [defer ] Using existing defer data (AVX2).
07:05:10 kresd[29218]: [cache ] Cache top initialized using existing data (AVX2).
07:05:10 kresd[29217]: [taupd ] next refresh for . in 12 hours
07:05:10 kresd[29217]: [tasign] signalling query triggered: _ta-4f66-9728.
07:05:10 kresd[29217]: [timesk] Local system time "Mon Jul 20 07:05:10 2026" is within RRSIG validity interval <"Mon Jul 20 00:00:00 2026","Sun Aug 2 01:00:00 2026">.
07:05:10 kresd[29218]: [system] path = /run/knot-resolver/control/1
07:05:10 supervisord: spawned: 'kresd1' with pid 29218
07:05:10 kresd[29217]: [taupd ] refreshing TA for .
07:05:10 supervisord: success: kresd0 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:10 kresd[29217]: [defer ] Defer configuration: Expected cpus/procs: 4 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
07:05:10 kresd[29217]: [defer ] Defer initialized (AVX2).
07:05:10 kresd[29217]: [defer ] Initializing defer...
07:05:10 kresd[29217]: [cache ] Cache top initialized using existing data (AVX2).
07:05:10 kresd[29217]: [system] path = /run/knot-resolver/control/0
07:05:10 supervisord: spawned: 'kresd0' with pid 29217
07:05:10 supervisord: stopped: kresd0 (exit status 0)
07:05:10 supervisord: waiting for kresd0 to stop
07:05:10 kresd[29216]: [taupd ] refreshing TA for .
07:05:10 supervisord: success: kresd0 entered RUNNING state, process sent notification via $NOTIFY_SOCKET
07:05:10 kresd[29216]: [defer ] Defer configuration: Expected cpus/procs: 4 Max waiting requests: 64.0 MiB Request timeout: 1.0 s Idle: 1.0 ms UDP phase: 400.0 us Non-UDP phase: 400.0 us Priority levels: 25 (4 main levels, 8 sublevels) + UDP KRU capacity: 524.3 k (4.2 MiB) Decay: 0.012 % per ms (32-bit max: 524280) Half-life: 5.7 s Priority rise in: 22.7 s Counter reset in: 90.8 s Rate limits for crossing priority levels as single CPU utilization: 1 2 3 max v4/32 : 0.012 % 0.195 % 3.125 % 49.999 % v4/24 : 0.391 % 6.250 % 100.000 % 1599.976 % v4/20 : 3.125 % 50.000 % 800.000 % 12799.805 % v4/18 : 9.375 % 150.000 % 2400.000 % 38399.414 % v6/128: 0.012 % 0.195 % 3.125 % 49.999 % v6/64 : 0.024 % 0.391 % 6.250 % 99.998 % v6/56 : 0.037 % 0.586 % 9.375 % 149.998 % v6/48 : 0.049 % 0.781 % 12.500 % 199.997 % v6/32 : 0.781 % 12.500 % 200.000 % 3199.951 % Instant limits for crossing priority levels as CPU time: 1 2 3 max v4/32 : 1.0 ms 16.0 ms 256.0 ms 4.1 s v4/24 : 32.0 ms 512.0 ms 8.2 s 131.1 s v4/20 : 256.0 ms 4.1 s 65.5 s 1048.6 s v4/18 : 768.0 ms 12.3 s 196.6 s 3145.7 s v6/128: 1.0 ms 16.0 ms 256.0 ms 4.1 s v6/64 : 2.0 ms 32.0 ms 512.0 ms 8.2 s v6/56 : 3.0 ms 48.0 ms 768.0 ms 12.3 s v6/48 : 4.0 ms 64.0 ms
07:05:10 kresd[29216]: [defer ] Defer initialized (AVX2).
07:05:10 kresd[29216]: [defer ] Initializing defer...
07:05:10 kresd[29216]: [cache ] Cache top initialized using existing data (AVX2).
07:05:10 kresd[29216]: [system] path = /run/knot-resolver/control/0
07:05:10 supervisord: spawned: 'kresd0' with pid 29216
07:05:09 supervisord: exited: policy-loader (exit status 0; expected)
07:05:09 kresd[29201]: [cache ] Cache top initialized as empty (AVX2).
07:05:09 supervisord: success: policy-loader entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
07:05:09 supervisord: spawned: 'policy-loader' with pid 29201
07:05:07 knot_resolver.manager.server: Exec requested with arguments: ['/usr/bin/supervisord', 'supervisord', '--configuration', '/run/knot-resolver/supervisord.conf']
07:05:07 knot_resolver.controller.supervi: We want supervisord to restart us when needed, we will therefore exec() it and let it start us again.
07:05:07 knot_resolver.controller: Selected controller 'supervisord'
07:05:07 knot_resolver.controller: Available subprocess controllers are ('supervisord',)
07:05:07 knot_resolver.controller: Starting service manager auto-selection...
07:05:07 knot_resolver.manager.logger: Changing logging level to 'INFO'
07:05:07 knot_resolver.manager.server: Loading configuration from '/etc/knot-resolver/config.yaml' file.
07:05:04 unbound: [1695:0] info: 0.262144 0.524288 1
Apologies for doing a horrible job of describing this. knot resolver went live at 07:05 on this box. Initially doing UDP to comcast’s DNS (75.75.75.75). Clients were not able to resolve names in DHCP leases. Work around was to create entries for the reservations in hosts. Switched to TLS using google.dns and one.one.one.one. DNS screen showed ok/working. Clients could not resolve any name not in hosts. pakfire could not connect. Switched to UDP (still with 8.8.8.8 and 1.1.1.1) and
dns log.pdf (63.6 KB)
all resolution started functioning.
from a second box having DNS issues. This one went live early yesterday morning and ran all day without issue until just before 4am this morning. No resolution then knot stopped. Restarted firewall. knot stopped.. restarted knot resolver via CLI. Clients still had no name resolution. knot resolver keeps stopping. Unselect everything from DNS Firewall, knot resolver kept running but clients still getting no name resolution. Switched from TLS to UDP and resolution started working.
knot resolver dns log.pdf (116.0 KB)
The only way you could do that is by having the system set to UDP or TCP and then there is no check that the TLS hostname has been filled in. So you can then fill in a lot of entries with only the IP.
If you then change to TLS and press the Check DNS Servers button you will find that all the entries without hostnames will show a red Error. with the message “No TLS hostname given”.
If you have it set to TLS and try and enter DNS server the WUI page has the hostname marked with a red asterisk as being a Required Field and if you press the Save button you will get an error message at the top of the page saying “No TLS hostname given”.
If using TLS I would recommend starting afresh on your system and ensuring that you add in the hostname for the server as shown on the IPFire “List of Public DNS Servers” in the documentation.
Having filled and saved all the entries then press the “Check DNS Servers” button and resolve any entries that are showing a red Error.
This mechanism was in place with unbound and is still in place with knot.
Maybe I started with UDP, then switched to TLS. My TLS hostnames were empty but that is not the issue…
I tried new test. I used IPfire C201 installed in VirtualBox virtual machine, just a basic configuration, red+green, DHCP on green, disabled ISP DNS, configured several public DNS servers (1.1.1.1, 8.8.8.8, 9.9.9.9) and tested that UDP and TLS configuration work OK (unbound). Then I switched to UDP and upgraded to C203. No issue this time, until DNS was configured to UDP mode, it works good.
Once I switch from UDP to TLS, I start to see SERVFAIL errors, DNS doesn’t work in TLS. From my point of view, this is an easy to replicate… I use just one TLS server, 1.1.1.1:
[root@vmfire ~]# host ipfire.org
Host ipfire.org not found: 2(SERVFAIL)
[root@vmfire ~]# cat /var/ipfire/dns/servers
3,8.8.8.8,dns.google,disabled,Google DNS dns.google
5,1.1.1.1,one.one.one.one,enabled,ClaudFlare one.one.one.one
4,9.9.9.9,,disabled,Quad9 dns9.quad9.net
[root@vmfire ~]# cat /var/ipfire/dns/settings
ENABLE_SAFE_SEARCH=off
ENABLE_SAFE_SEARCH_YOUTUBE=on
USE_ISP_NAMESERVERS=off
PROTO=TLS
[root@vmfire ~]# pakfire status
Core-Version: 2.29-x86_64
Core-Update-Level: 203
Last update: 51m 19s ago
Last core-list update: 55m 14s ago
Last server-list update: 55m 18s ago
Last packages-list update: 55m 17s ago
Core-Update available: no
Package-Updates available: 0
Reboot required: no
[root@vmfire ~]# uname -a
Linux vmfire.localdomain 6.18.32-ipfire #1 SMP PREEMPT_DYNAMIC Thu May 21 20:04:47 GMT 2026 x86_64 GNU/Linux
[root@vmfire ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:31:12:6b brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute red0
valid_lft 82454sec preferred_lft 71654sec
3: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:0e:43:59 brd ff:ff:ff:ff:ff:ff
inet 192.168.33.1/24 scope global green0
valid_lft forever preferred_lft forever
Okay, I have looked through the logs for the second box. From that I don’t see any linkage with a change from TLS to UDP. I think that was more just a time co-incidence.
At 00:51 the phishing.rpz.ipfire.org.zone file was found by the knot rules check to have an invalid domain name character. This caused the knot system to fail due to an invalid configuration file. This check of the zone file was then carried out a further 19 times up to 05:48, with the same error each time.
Then the knot supervisord program has the message
05:48:42 supervisord: gave up: manager entered FATAL state, too many start retries too quickly
05:48:42 supervisord: manager process entered FATAL state! Shutting down
05:48:41 supervisord: exited: manager (exit status 1; not expected)
Then at 05:49:21 knot restarts and this time it stays running up to the end of the log at 07:53.
So whatever the problem was with the phishing zone file it was resolved.
Based on this log file I would expect that you can run the DNS server in TLS mode without any issues.
Looking at the log file for the first system I noticed that at 07:05 the update from unbound to knot occurred. A zone download check was carried out successfully with no changes to be dealt with.
At 07:08 the following messages were seen.
07:08:23 kresd[1714]: [io] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
07:08:23 kresd[1714]: [taupd ] refreshing TA for .
07:08:23 kresd[1714]: [io] Failed to establish udp connection to 75.75.75.75#00053: network is unreachable
knot is working here but there seems to be a problem actually reaching that server. It was tried 10 times in total and then after that knot is having trouble to resolve root.
Then at 07:08:29 the resolving is working again so the problem with connection to 75.75.75.75 was only for a relatively short time. Then knot is doing a periodic reload but nothing much else as there is no traffic triggering the DNS Firewall.
From 08:28 I can see the DNS firewall being triggered by traffic. This continues up to 09:42 when a reload step is successfully carried out. Then also at 10:52. The reload is carried out at around an hourly basis. There are the reloads mixed in with DNS Firewall rules checks, all occurring successfully with no errors up to the end of the log at 23:56.
On this system, all I can see is a short period where 75.75.75.75 was unreachable but all the rest of the time knot-resolver was running as expected.
There are no entries at all in the knot logs related to google, one.one.one.one or 8.8.8.8 or 1.1.1.1, so I am not sure what the problem you were experiencing was but it was not related to knot as it was running correctly the whole time from 07:05 to 23:56
On this firewall, knot resolver shuts down if I have any of the DNS firewall categories selected. With no DNS firewall categories selected, knot resolver keeps running. With DNS configured for TLS, clients get no name resolution. With DSN configured for UDP, clients get name resolution.
I’m also seeing on every firewall running knot resolver that dns.google (8.8.8.8) cannot resolve any of the microsoft 365 names (microsoft365.com, etc.) while all the firewalls still running unbound with dns.google (8.8.8.8) are not having issue. This is both TLS and UDP. Easy workaround is to take 8.8.8.8 and 8.8.4.4 out of all the DNS configs. I think there something about that in another thread.
I have been able to get this error message if I created a udp dns server entry and then changed it to tls without adding a hostname to it and then disabling all the correct tls dns servers that I had.
So this error message is shown when you have a dns server defined with TLS but no hostname. This will show up as a red Error message when you run the Check DNS Servers test.
EDIT: and when I have DNS Servers with TLS and correctly defined hostnames and all show a Green OK when the Check DNS Servers button is pressed then I no longer have that error.
Can you please select a category and then show the logs from the period when you selected that category and pressed the Save button. Also please say which category was selected.
Following up on the odd Knot Resolver TLS behaviour. I ran a few tests on a system where everything actually works, hoping it helps narrow down what’s going on for the people hitting SERVFAIL. I think we can pinpoint where the issue sits.
My setup is IPFire 2.29 Core Update 203 with a DoT forwarder pointing at Quad9 (9.9.9.9, hostname dns.quad9.net). DNS resolves without any problems on my box, so I used it as a reference to compare against.
First I checked whether the plain TLS handshake works at all:
kdig -d @9.9.9.9 +tls google.de
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, skipping certificate verification
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; status: NOERROR
google.de. 146 IN A 142.251.27.94
;; From 9.9.9.9@853(TLS) in 86.2 ms
So port 853 is open, TLS 1.3 comes up fine and the certificate is presented (CN=dns.quad9.net). Note that kdig skips verification here by default, so this only proves the connection works, not the trust part.
Next I ran it exactly the way kresd would, with hostname and CA verification:
kdig -d @9.9.9.9 +tls-hostname=dns.quad9.net +tls-ca google.de
;; DEBUG: TLS, imported 150 system certificates
;; DEBUG: TLS, The certificate is trusted.
;; status: NOERROR
google.de. 50 IN A 142.251.27.94
;; From 9.9.9.9@853(TLS) in 96.4 ms
The system CA bundle is intact (150 certs imported), the hostname matches and the chain is trusted up to DigiCert. So full verified DoT works fine here.
Then I tried what happens with an empty hostname, which is the interesting one:
kdig -d @9.9.9.9 +tls-hostname= +tls-ca google.de
;; ERROR: empty argument: +tls-hostname=
The Knot library flat out refuses to work with an empty TLS hostname. This is the exact same underlying behaviour that produces the “invalid hostname in function ‘tls_client’” error in kresd.
Putting it together: networking, the TLS handshake and the CA store are all fine. What breaks things is an empty TLS hostname. My reading of the root cause is that the WebGUI lets you save a DoT forwarder without a TLS hostname. That empty value gets passed into tls_client() in the Lua policy config, Knot rejects it, and policy-loader exits with an error. At that point kresd has no working forwarder left and everything comes back as SERVFAIL. Unbound used to tolerate this, which is why it only shows up now that we’ve moved to Knot Resolver.
Anyone who filled in the hostname properly (like me) never sees it. Anyone who left the field blank, or migrated from an Unbound config where it wasn’t required, runs straight into the crash.
As for where it could be fixed, I see a few options. The cleanest would be to make the TLS Hostname field mandatory in the WebGUI whenever DoT is selected, validated both client and server side, before the config is ever written out to Knot. On top of that it would make sense to catch this during the migration from Unbound, so existing forwarders that have TLS enabled but no hostname get flagged rather than silently carried over. And regardless of that, a clear error in the log and GUI instead of a silent policy-loader crash would save people a lot of guessing, because right now there’s no obvious hint which forwarder is misconfigured.
To reproduce it: take a working DoT forwarder, clear the TLS hostname field and save. A look at /var/log/messages (for example with grep kresd /var/log/messages) then shows the invalid hostname error, policy-loader fails and DNS goes to SERVFAIL. Put the hostname back and it works again immediately.
Happy to run more tests if that helps.
Interesting find.
I think it is possible, that knot is more sensible to the standards. A DoT server must have a TLS host name. Unbound may be more ‘tolerable’, but no idea how this tolerance is implemented.
With the switch to knot resolver the WUI must check this in the protocol change operation.
You should report it to bugzilla.
Thanks, that matches my conclusion exactly. Knot seems to strictly enforce that a DoT server needs a TLS hostname, while Unbound was more forgiving. Since the switch to Knot Resolver, the WUI really should validate this on the protocol change, so an incomplete DoT forwarder can’t be saved in the first place.
That is incorrect.
If you have the protocol set to TLS then adding an entry gives you the following
You can see that the TLS Hostname has a red asterisk against it which defines it as a required field. Leaving it blank gives you the error message that “No TLS hostname given” and you have to fix that before you can save it.
If you are doing a UDP or TCP protocol then the TLS Hostname box does not have a red asterisk shown.
The only way to get DNS Servers with no hostname entered when using TLS is to create all of them first with UDP/TCP as the protocol.
This screenshot shows three DNS servers defined for UDP with no hostname specified.
With UDP as the protocol then pressing the Check DNS Servers gives the green OK for all the servers.
If you now change the protocol from UDP to TLS and press the Save button and don’t bother updating the entries with a hostname then you now have DNS servers under TLS without a hostname.
It seems sensible to me that every time you change anything on the DNS page that you should press the Check DNS Servers button. I certainly do that.
If you do that in this case then you get the following
I have placed the mouse pointer over one of the red Error statuses and it shows “No TLS hostname given”.
So to get in the “odd behaviour with TLS” you would have to create the entries first under UDP/TCP without a hostname, then change the protocol to TLS and press Save and then not update any of the entries and also not press the Check DNS Servers button so you don’t get shown that there is an error.
The IPFire documentation mentions that if you are wanting to use TLS then a hostname is required. It also suggests that if you want to update to TS in the future that you enter the hostname even if you are using the UDP/TCP protocols.
https://www.ipfire.org/docs/configuration/network/dns-server#tls-hostname.
If you try and edit an existing TLS entry under the TLS protocol then you will get an error message that “No TLS hostname given”
To reproduce it with a working TLS entry you have to first change the protocol to UDP then Save, then edit the entry to remove the hostname and Update and then change the protocol back to TLS and press Save.
What would be an inprovement would be to have a check when changing the protocol from UDP to TLS and preventing it from occurring with an error message if any of the entries (enabled or disabled) do not contain a hostname.
EDIT: It would probably need to be done against only entries that are enabled because some users might have entries without hostnames that are only enabled for use with UDP/TCP and others with hostnames for use with TLS.
The check would also then need to be done whenever any entry is changed from disabled to enabled, not just for when the protocol is changed from UDP/TCP to TLS. So it would need to check for hostnames in all the enabled entries when the protocol is changed to TLS and prevent it being done if one or more of the enabled entries don’t have a hostname, then also if an entry is changed from disabled to enabled and TLS is enabled then prevent the enabling if that entry did not have a hostname.
Of course a user can still get a TLS entry to be accepted by just putting in a dummy hostname such as this.is.a.test. That entry is then accepted but if you then press the Check DNS Servers button it will show a red error status with the message
TLS, handshake failed (Error in the certificate.);
The use of the Check DNS Servers button is mentioned in the IPFire DNS Server documentation page.
https://www.ipfire.org/docs/configuration/network/dns-server#check-dns-servers