DNS broken after factory reset and update to 3.11.1

dns

#1

Starting with the update to 3.11, DNS keeps breaking, so I perfomed a factory reset (3 LED). I changed the SSID and passwords, but all other settings are default. I updated to 3.11.1.

I also factory reset my cable modem (connected to Comcast). I turned off DHCP and WiFi, then enabled Rg passthrough (“bridge mode”), specifying the Turris Omnia WAN MAC address.

After a day or so, most devices cannot load websites because the DNS does not work. The devices that specify a DNS server (e.g. 8.8.8.8 in MacOS system preferences) on their own work fine. Using foris, I have tried the following:

  • “Use forwarding” unchecked
  • “Use forwarding” checked, DNS forwarder: Cloudflare
  • “Use forwarding” checked, DNS forwarder: Use provider’s DNS resolver, “Disable DNSSEC” checked.

After about a day, when DNS stops working, if I switch between any of the above it instantly starts working without a reboot (even if I switch back to the one that was just broken). I tested the second two configurations on 3.11, and the first configuration (no forwarding) on 3.11.1. Now I’m testing the second (use Cloudflare) on 3.11.1. Tomorrow, assuming it breaks, I’ll test the third (use Comcast with no DNSSEC).

Tomorrow I’ll try
echo 'verbose(true)' | socat - /tmp/kresd/tty/"$(pgrep kresd)"
and post the logs. I did notice this error when I log into foris:

Error from 2018/12/21 00:55:35
Updater selhal:
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn’t resolve host ‘repo.turris.cz’

To be clear, the router is not working with all settings (besides SSID) default.


Repeated problems with kresd
#2

I have no particular ideas. The verbose logs would be my recommendation for the next step.


#3

This is exactly what I am experiencing!


#4

My DNS broke similar way after updating to 3.11.1 (didn’t notice any issues under 3.11).

I didn’t have time to investigate it yet, but from my logs it looks like /tmp/kresd/hints.tmp is corrupted on the first run. After restarting DNS subsystem via Foris web interface, the file seems to fix itself.

Initial run:

2018-12-22T04:43:24+01:00 info dnsmasq[2931]: started, version 2.78 DNS disabled
2018-12-22T04:43:24+01:00 info dnsmasq[2931]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
2018-12-22T04:43:24+01:00 info dnsmasq-dhcp[2931]: DHCP, IP range 192.168.4.10 -- 192.168.4.159, lease time 12h
2018-12-22T04:43:24+01:00 info dnsmasq-dhcp[2931]: DHCP, IP range 192.168.3.10 -- 192.168.3.159, lease time 12h
2018-12-22T04:43:24+01:00 info dnsmasq-dhcp[2931]: read /etc/ethers - 0 addresses
2018-12-22T03:43:24+01:00 info dhcp_host_domain_ng.py[]: DHCPv4 new lease
2018-12-22T03:43:24+01:00 info dhcp_host_domain_ng.py[]: DHCP update hostname [old,whale,192.168.3.201]
2018-12-22T03:43:24+01:00 err dhcp_host_domain_ng.py[]: Kresd socket failed:<class 'socket.error'>,[Errno 104] Connection reset by peer
2018-12-22T03:43:24+01:00 err dhcp_host_domain_ng.py[]: Wrong host format '/tmp/kresd/hints.tmp' in host file 192.168.3.201 whale.lan
2018-12-22T03:43:24+01:00 err dhcp_host_domain_ng.py[]: Kresd socket failed:<class 'socket.error'>,[Errno 104] Connection reset by peer
2018-12-22T03:43:24+01:00 err dhcp_host_domain_ng.py[]: Wrong host format '/tmp/kresd/hints.tmp' in host file 192.168.3.202 minime.lan

After kicked by Foris web interface:

2018-12-22T03:44:34+01:00 info dhcp_host_domain_ng.py[]: Refresh kresd leases
2018-12-22T04:44:34+01:00 info dnsmasq[2931]: exiting on receipt of SIGTERM
2018-12-22T04:44:34+01:00 info dnsmasq[4138]: started, version 2.78 DNS disabled
2018-12-22T04:44:34+01:00 info dnsmasq[4138]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
2018-12-22T04:44:34+01:00 info dnsmasq-dhcp[4138]: DHCP, IP range 192.168.5.100 -- 192.168.5.249, lease time 12h
2018-12-22T04:44:34+01:00 info dnsmasq-dhcp[4138]: DHCP, IP range 192.168.4.10 -- 192.168.4.159, lease time 12h
2018-12-22T04:44:34+01:00 info dnsmasq-dhcp[4138]: DHCP, IP range 192.168.3.10 -- 192.168.3.159, lease time 12h
2018-12-22T04:44:34+01:00 info dnsmasq-dhcp[4138]: read /etc/ethers - 0 addresses
2018-12-22T03:44:34+01:00 info dhcp_host_domain_ng.py[]: DHCPv4 new lease
2018-12-22T03:44:34+01:00 warning dhcp_host_domain_ng.py[]: Add_lease, hostname check failed
2018-12-22T03:44:34+01:00 info dhcp_host_domain_ng.py[]: DHCP update hostname [old,whale,192.168.3.201]
2018-12-22T03:44:35+01:00 info kresd[3700]: > hints.del('turris')
2018-12-22T03:44:35+01:00 info kresd[3700]: [result] => true
2018-12-22T03:44:35+01:00 info kresd[3700]:
2018-12-22T03:44:35+01:00 info kresd[3700]: > hints.del('minime')
2018-12-22T03:44:35+01:00 info kresd[3700]: [result] => true
2018-12-22T03:44:35+01:00 info kresd[3700]:
2018-12-22T03:44:35+01:00 info kresd[3700]: > hints.del('whale')
2018-12-22T03:44:35+01:00 info kresd[3700]: [result] => true
2018-12-22T03:44:35+01:00 info kresd[3700]:

#5

I just upgraded to 3.11.1, and DNS on my TO stopped working as well. Just after 10 minutes after a cold reboot. What I noticed is that the kresd process started out quickly after reboot as a 77 Mbyte process, and in 10 minutes (with a low load on the network) it grew to 108 Mbyte.

I saw similar behavior (process growing in size and stopping all work soon) of kresd in 3.11 with DNS over TLS enabled. But DNS over TLS is now off!

With DNS failing constantly, complaints from the family are countless. I kindly ask to look into fixing these DNS issues with priority. Thank you.


#6

Still working over 24 hours later with “Use forwarding” checked, DNS forwarder: Cloudflare.

I’m out of town now for the holidays, and if DNS breaks again then my housemate is just going to swap out the router for another brand.

Good luck tracking this down. Intermittent problems are challenging to fix!


#7

So far we haven’t experienced anything like that. I’ve been even using TLS forwarding on Omnia for me and some relatives, for weeks without issues noticeable by laymen.

I’m afraid the problem will be hard to find without us getting more information somehow, e.g. I’d start with verbose logs from a failing moment, ideally around the moment it starts to fail but not necessarily. Also note that everyone is on vacation now :wink:


#8

@vcunat I have the same issue. What I want to add is that simple restart doesn’t help me every time. Sometimes I have to comment out TLS_FORWARD section in /etc/kresd/custom.conf:

policy.add(policy.all(
   policy.TLS_FORWARD({
     {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'},
     {'1.0.0.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'}
   })
 ))

and restart kresd after that. Then I can uncomment it back and restart again.


#9

I want to add my name to the same problem, I too saw a similar behavior with kresd (process growing in size and stopping all work) in 3.11 and 3.11.1 with DNS over TLS enabled from foris (quad9999 and cloudflare). I did a factory reset to the latest medkit and I did not restore any settings, I used the default config files.

I turned off forwarding and using DNS over TLS in foris, I deleted the foris TLS line in the resolver config file that is listed under “common” and add to the “kresd” section `option include_config ‘/etc/kresd/custom.conf’. I made sure that Forward_upstream was off.

This has been working for the past 5 days without a drop in dns resolving. I agree with the others, there is a problem somewhere between kresd and the resolver. Just my 2 cents.

-john


#10

Same problem here, but with it being the holidays I haven’t had much time to debug it - but I will do once I have some free time.


#11

Ok, I started with your command echo 'verbose(true)' | socat - /tmp/kresd/tty/"$(pgrep kresd)" and got the > true as answer.
Right after that I changed DNS-settings via FORIS to


and ran the connection test - the status is already shown in the picture. DNS stopped working instantly - webpages can be accessed directly via IP (e.g. 1.1.1.1), but not by TLD. When running /etc/init.d/resolver restart DNS works for a couple of seconds before it stops again. Syslog isn’t showing any additional entry.
After that I reverted DoT, went to https://doc.turris.cz/doc/en/howto/dnsdebug#enable_verbose_logging, followed the instructions, started debug-logging and activated DoT again. Ironically DNS is now working, despite connection test telling me it isn’t. I will post cleaned logs tomorrow.


#12

Just note that the configuration commands to kresd through socat are only applied once, i.e. they only make effect until the process is restarted (such as when reconfigured from Foris). The buttons from the tutorial use the same inside, so it also applies to them as well.


#13

I had a similar problem in 3.11.1
The problem was easy to fix: The DNS Serverport was set to “0”; after entering the value “53” everything worked fine. ( … Network … DHCP & DNS … Advanced Settings )


#14

Sorry, but that cannot be the solution. Those settings go to dnsmasq, which only serves for dhcp entries on standard TO setup. DNS is done by kresd whose settings cannot be changed via luci.
The setting you mention is located in /etc/config/dhcp

config dnsmasq
	option port '0'

and has been there unchanged at least since 3.10 - that’s my oldest snapshot which I just mounted to very that.


#15

“Unfortunately” DNS wasn’t broken this night.
I saved the 1,4MB debug-log anyway. I will restart my TO and start debugging again. Hopefully I will have the error printed, when I return in 2 days.

edit: When starting the debug, I get right away three errors:

2018/12/24 12:35:22 socat[5733] E connect(5, AF=1 "/tmp/kresd/tty/5266", 21): No such file or directory
2018/12/24 12:35:23 socat[5847] E connect(5, AF=1 "/tmp/kresd/tty/", 17): Connection refused
2018/12/24 12:35:23 socat[5859] E connect(5, AF=1 "/tmp/kresd/tty/", 17): Connection refused

#16

Ok, I’ve got some time to play with this today. Please scratch my previous message about /tmp/kresd/hints.tmp being corrupted on the first run. I found the real cause. It was my mistake.

Many months ago I tweaked my /etc/config/resolver by following https://doc.turris.cz/doc/en/public/dns_knot_misc specifically what is now labeled as “Setup in Turris OS 3.9.6 through 3.10.8”. I added option include_config '/etc/kresd/custom.conf' with this content:

policy.add(policy.all(
      policy.TLS_FORWARD({
          {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'},
          {'1.0.0.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'}
      })
))

This caused the consistent problem on first run for some reason. It probably conflicts with new DNS custom forwarding system added in 3.11 via option forward_custom.


But I identified another confusing issue when playing with Foris web interface under DNS page. It looks like when disabling “Use forwarding” the script is not clearing option forward_custom - it just flips option forward_upstream in /etc/config/resolver.

I enabled verbose logging in /etc/config/resolver via option verbose '1' and observed the logs.

  1. after enabling “Use forwarding”, and “DNS Forwarder” to “Cloudflare (TLS)”, in /etc/config/resolver I can see option forward_upstream '1' and option forward_custom '99_cloudflare' (newly added), kresd verbose logs are properly mentioning CloudFlare’s 1.1.1.1
  2. after disabling “Use forwarding”, I can see option forward_upstream '0' but option forward_custom '99_cloudflare' stayed intact, in logs I can still see CloudFlare’s 1.1.1.1 being used - I would expect my ISP’s server instead
  3. after enabling “Use forwarding” and setting “DNS Forwarder” to “Use provider’s DNS resolver”, I can see “option forward_custom ‘99_cloudflare’” was removed and option forward_upstream '1'. This is as expected and logs mention my ISP servers.
  4. fter disabling “Use forwarding” while having “DNS Forwarder” set to “Use provider’s DNS resolver”, I can see “option forward_custom ‘99_cloudflare’” is still removed and option forward_upstream '0'. This is as expected and logs mention my ISP servers.

TL;DR; after disabling “Use forwarding” option forward_custom ... should be removed. If this is correct behaviour then the Foris web UI is confusing, because it hides “DNS Forwarder” option.


#17

Seems you are correct and that is the root cause. At least I have rebooted three times and DNS is ok every time while previously it was never working.

Pretty sad that an OS update can cause such serious incompatibility even with the settings slightly altered according to the official documentation. I expected better testing of the updates before making them public since the default configuration updates automatically and if I wasn’t near the router at the moment of that update, I’d lose an access to it completely.

What is strange as well is that all the facts were clearly described in that topic and you, not a member of Turris or Knot team described the solution.

Anyway, thank you!


#18

Also, since TLS_FORWARD is a non-chain action, custom.conf cannot override its settings anymore.
E.g. if you do

config resolver ‘common’
option forward_custom ‘99_cloudflare’

config resolver ‘kresd’
option include_config ‘/etc/kresd/custom.conf’

Then if you put

extraTrees = policy.todnames({‘faketldtest’, ‘sld.example’, ‘internal.example.com’})
– Beware: the rule order is important, as STUB is not a chain action.
policy.add(policy.suffix(policy.FLAGS({‘NO_CACHE’}), extraTrees))
policy.add(policy.suffix(policy.STUB({‘2001:db8::1’}), extraTrees))

from https://knot-resolver.readthedocs.io/en/stable/modules.html#replacing-part-of-the-dns-tree into custom.conf, it won’t work anymore.


#19

So today it worked out - I just got a full debug log containing the time when the DNS gets broken.
As this contains plenty of personal data - is there something specific I can search for as I don’t want to post my data and also don’t want to spend hours anonymizing the logs?

edit: snippet of time frame in which DNS got broken:

2018-12-24 23:49:17 info kresd[26898]: > hints.add_hosts('/tmp/kresd/hints.tmp')
2018-12-24 23:49:17 info kresd[26898]: [result] => true
2018-12-24 23:49:17 info kresd[26898]: 
2018-12-24 23:49:17 info kresd[26898]: > hints.add_hosts('/tmp/dhcp.leases.dynamic')
2018-12-24 23:49:17 info kresd[26898]: [result] => true
2018-12-24 23:49:17 info kresd[26898]: 
2018-12-24 23:50:01 info /usr/sbin/cron[27171]: (root) CMD (nethist_stats.lua)
2018-12-24 23:54:00 warning kernel[]: [40819.695685] <[[---  VPN Traffic ---]]> : IN=eth1 OUT= MAC=d8:58:d7:00:43:00:38:10:d5:89:65:b2:08:00 SRC=112.78.45.158 DST=<router WAN IP> LEN=44 TOS=0x00 PREC=0x00 TTL=244 ID=22109 DF PROTO=TCP SPT=39007 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 
2018-12-24 23:54:30 warning kernel[]: [40849.551932] <[[---  VPN Traffic ---]]> : IN=eth1 OUT= MAC=d8:58:d7:00:43:00:38:10:d5:89:65:b2:08:00 SRC=110.249.212.46 DST=<router WAN IP> LEN=52 TOS=0x00 PREC=0x00 TTL=240 ID=0 PROTO=TCP SPT=55555 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
2018-12-25 00:00:01 info /usr/sbin/cron[27429]: (root) CMD (nethist_stats.lua)
2018-12-25 00:00:01 info /usr/sbin/cron[27432]: (root) CMD (/usr/share/server-uplink/registration_code.sh)
2018-12-25 00:00:01 info /usr/sbin/cron[27435]: (root) CMD (/usr/bin/updater-supervisor -d --rand-sleep)
2018-12-25 00:00:01 info /usr/sbin/cron[27434]: (root) CMD (   /usr/bin/notifier)
2018-12-25 00:00:01 info /usr/sbin/cron[27436]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:00:02 info updater-supervisor[]: Suspending updater start for 1327 seconds
2018-12-25 00:01:01 info /usr/sbin/cron[27501]: (root) CMD ((cat /tmp/nethist.stats | sort ; echo "uptime = $(cat /proc/uptime | cut -d. -f1)" ) | logger -p info -t nethist ; rm /tmp/nethist.stats)
2018-12-25 00:01:01 info /usr/sbin/cron[27502]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:01:01 info nethist[]: fs_avg = nan
2018-12-25 00:01:01 info nethist[]: fs_max = 0
2018-12-25 00:01:01 info nethist[]: fs_samples = 0
2018-12-25 00:01:01 info nethist[]: fs_sum = 0
2018-12-25 00:01:01 info nethist[]: last_timestamp = 1545692399
2018-12-25 00:01:01 info nethist[]: load_avg = 0.0034014598540146
2018-12-25 00:01:01 info nethist[]: load_max = 0.17
2018-12-25 00:01:01 info nethist[]: load_min = 0
2018-12-25 00:01:01 info nethist[]: load_samples = 1370
2018-12-25 00:01:01 info nethist[]: load_sum = 4.66
2018-12-25 00:01:01 info nethist[]: mem_buffers_avg = 1824941.6408759
2018-12-25 00:01:01 info nethist[]: mem_buffers_max = 1841396
2018-12-25 00:01:01 info nethist[]: mem_buffers_min = 1817796
2018-12-25 00:01:01 info nethist[]: mem_buffers_samples = 1370
2018-12-25 00:01:01 info nethist[]: mem_buffers_sum = 2500170048
2018-12-25 00:01:01 info nethist[]: mem_cached_avg = 2424
2018-12-25 00:01:01 info nethist[]: mem_cached_max = 2424
2018-12-25 00:01:01 info nethist[]: mem_cached_min = 2424
2018-12-25 00:01:01 info nethist[]: mem_cached_samples = 1370
2018-12-25 00:01:01 info nethist[]: mem_cached_sum = 3320880
2018-12-25 00:01:01 info nethist[]: mem_free_avg = 1752392.6423358
2018-12-25 00:01:01 info nethist[]: mem_free_max = 1768924
2018-12-25 00:01:01 info nethist[]: mem_free_min = 1745480
2018-12-25 00:01:01 info nethist[]: mem_free_samples = 1370
2018-12-25 00:01:01 info nethist[]: mem_free_sum = 2400777920
2018-12-25 00:01:01 info nethist[]: mem_total_avg = 2070072
2018-12-25 00:01:01 info nethist[]: mem_total_max = 2070072
2018-12-25 00:01:01 info nethist[]: mem_total_min = 2070072
2018-12-25 00:01:01 info nethist[]: mem_total_samples = 1370
2018-12-25 00:01:01 info nethist[]: mem_total_sum = 2835998640
2018-12-25 00:01:01 info nethist[]: temp_board_avg = nan
2018-12-25 00:01:01 info nethist[]: temp_board_max = 0
2018-12-25 00:01:01 info nethist[]: temp_board_samples = 0
2018-12-25 00:01:01 info nethist[]: temp_board_sum = 0
2018-12-25 00:01:01 info nethist[]: temp_cpu_avg = nan
2018-12-25 00:01:01 info nethist[]: temp_cpu_max = 0
2018-12-25 00:01:01 info nethist[]: temp_cpu_samples = 0
2018-12-25 00:01:01 info nethist[]: temp_cpu_sum = 0
2018-12-25 00:01:01 info nethist[]: uptime = 41243
2018-12-25 00:02:01 info /usr/sbin/cron[27540]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:02:01 err server_uplink[]: Failed to get registration code
2018-12-25 00:03:01 info /usr/sbin/cron[27571]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:03:47 warning kernel[]: [41407.248121] <[[---  VPN Traffic ---]]> : IN=eth1 OUT= MAC=d8:58:d7:00:43:00:38:10:d5:89:65:b2:08:00 SRC=183.81.90.216 DST=<router WAN IP> LEN=44 TOS=0x00 PREC=0x00 TTL=49 ID=53708 PROTO=TCP SPT=3264 DPT=80 WINDOW=20811 RES=0x00 SYN URGP=0 
2018-12-25 00:04:01 info /usr/sbin/cron[27602]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:05:01 info /usr/sbin/cron[27632]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:05:01 info /usr/sbin/cron[27633]: (root) CMD ( schnapps cleanup)
2018-12-25 00:06:01 info /usr/sbin/cron[27707]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:06:25 info hostapd[]: iot1: STA 2c:0e:3d:85:b9:92 IEEE 802.11: authenticated
2018-12-25 00:06:25 info hostapd[]: iot1: STA 2c:0e:3d:85:b9:92 IEEE 802.11: associated (aid 2)
2018-12-25 00:06:25 info hostapd[]: iot1: STA 2c:0e:3d:85:b9:92 RADIUS: starting accounting session 68C2C581784F3F44
2018-12-25 00:06:25 info hostapd[]: iot1: STA 2c:0e:3d:85:b9:92 WPA: pairwise key handshake completed (RSN)
2018-12-25 00:07:01 info /usr/sbin/cron[27738]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:07:36 warning kernel[]: [41635.574007] <[[---  VPN Traffic ---]]> : IN=eth1 OUT= MAC=d8:58:d7:00:43:00:38:10:d5:89:65:b2:08:00 SRC=104.131.136.175 DST=<router WAN IP> LEN=44 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=57955 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
2018-12-25 00:08:01 info /usr/sbin/cron[27770]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:09:01 info /usr/sbin/cron[27800]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:10:01 info /usr/sbin/cron[27831]: (root) CMD (nethist_stats.lua)
2018-12-25 00:10:01 info /usr/sbin/cron[27833]: (root) CMD (/usr/bin/get-api-crl)
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'a.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'a.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'b.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'b.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'c.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'c.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'd.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'd.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'e.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'e.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'f.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'f.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'g.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'g.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'h.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'h.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'i.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'i.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'j.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'j.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'k.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'k.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'l.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'l.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'm.root-servers.net.', type: 1
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve address 'm.root-servers.net.', type: 28
2018-12-25 00:10:35 err kresd[26898]: [priming] cannot resolve any root server address, next priming query in 10 seconds

#20

Using dnsmasq for DNS instead of knot-resolver would be better left for other threads.