Turris OS 3.11 is out!

release

#153

Hi @vcunat,

the Luci was slow even when DNS worked. The problem is that it didn’t work time to time - not constantly.

I used to have custom config for TLS over Cloudfare but I removed it from /etc/config/resolver so I hope it shouldn’t be used.

I can switch back to Cloudfare TLS and provide any input / details if you advice on what to look for.

Thanks.

config resolver 'kresd'
        option rundir '/mnt/var/kresd'
        option log_stderr '1'
        option log_stdout '1'
        option forks '1'
        list hostname_config '/etc/kresd/custom.hints'

#154

Thanks, @AreYouLoco. Adding the user and group should be easy, but then what directories and files to chown to kresd? The reason I reported this is that the software maintainers can take this along in their next release.


#155

No need to do that yet. A this moment the kresd process still runs as root anyway, so it’s unaffected by permission stuff. These are just partial preparations for future.


#157

Yes, that helped. Thank you!


#158

May not be new to 3.11, but I couldn’t get the Pakon page in Foris to filter by either hostname or client properly, until I realized that the fields are case sensitive. Logged https://gitlab.labs.nic.cz/turris/foris-pakon-plugin/issues/29


#159

Unbound is not working due to permission issues with the unit script https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/276.


#160

Are you sure about it? Because I’ve just tested it on Turris 1.1, and it’s working. It could be related to your configuration, which is not standard as the default DNS resolver on Turris Omnia is Knot Resolver even with that we’re aware of your issue, and @paja is looking into it.

root@turris:/# /etc/init.d/resolver restart
Called /etc/init.d/unbound stop
remove dhcp script
Check generated config /var/etc/unbound/unbound.conf:
unbound-checkconf: no errors in /var/etc/unbound/unbound.conf
Called /etc/init.d/unbound start
remove dhcp script

#161

I would not have reported it otherwise.

Why this is being kept repeated, like a mantra/promotion? I am aware of it and yet have chosen unbound and which had no issue with the configuration prior to 3.11. Hence I posted it in this thread since it seems like a regression bug.


#162

Same issue here. When changed back to “Use Provider’s DNS resolver” Luci starts to respond pretty quick. Weird thing is that even after changing it back to Cloudflare TLS will not slow Luci down. It comes occasionally after some time maybe?

I am not facing other issues you are describing. Only that Luci interface is slow.


#163

#164

I have my local dnsmasq configured to respond to DNS on port 5353
for local host resolution. Either since 3.11 or since I changed my resolver setup to use the GUI to set the DNS forwarding to use Cloudflare (and commented out my custom rule that set that up), I lost my local dynamic host resolution.

Here are the lines that set that up:

policy.add(policy.suffix(policy.STUB('127.0.0.1@5353'), policy.todnames({'localnet.home','45.168.192.in-addr.arpa'})))
policy.add(policy.suffix(policy.DENY, policy.todnames({'168.192.in-addr.arpa'})))
-- Allow reverse lookups
policy.add(policy.suffix(policy.PASS, { todname('45.168.192.in-addr.arpa') }))

After I reversed the changes I still couldn’t look up local dynamic dhcp hosts. If the hosts are set in /etc/config/dhcp (and thus in /tmp/kresd/hints.tmp)it works fine.

If I ask dnsmasq directly, it answers fine. I’m trying to figure out what changed recently to cause this to happen.

My decision to use this configuration is that in the past reverse lookups didn’t work. Has that changed as well?


#165

Forwarding to somewhere is implemented by a policy rule that forwards everything. The first matching rule wins. Custom config is included after this, and your rules get appended to the rule list, so they get shadowed. It feels really difficult to design such configuration systems in a way that the pieces compose together just as users expect.


#166

I was under the impression that

policy.add(policy.suffix(policy.STUB('127.0.0.1@5353'), policy.todnames({'localnet.home','45.168.192.in-addr.arpa'})))

would take care of forwarding requests only for the listed zones to dnsmasq.

In my case, selecting “Use forwarding” in the GUI and picking Cloudflare results in

policy.add(policy.all(policy.TLS_FORWARD(
{{'1.1.1.1'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'2606:4700:4700::1111'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
}})))

Added after the initial stanza.

My own stanza

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'}
      })
))

sits at the bottom (commented out if I pick “Use forwarding”).

Does adding the policy.TLS_FORWARD negate the policy.STUB statement later on?

In reversing the order does the policy.STUB negate the policy.TLS_FORWARD statement?

Even if I reverse the statements, I no longer have lookups of my local dynamic DHCP entries. It all seems a little opaque how it’s supposed to work. I also don’t get much enlightenment if I enable verbose output for kresd, but I’m not an expert in reading that output either.

If I enable “Enable DHCP clients in DNS” in the GUI, will I be able to reverse lookup my hosts?

I probably should create this as a separate thread.


#167

@paja: Could you please have a look inside these two errors Erno104 and Erno 32 and constantly failing resolver after provider automatical compulsory isolation? I do not have any “specials” so TO standard configurations should work for me… :frowning:


#168

See Samba4 experience for complete install instructions.


#169

I have been using DNS over TLS with kresd for a few days now, and this is to let you know that I had to switch back, away from DNS over TLS. Observations:

  1. resolving stops after a few hours
  2. no error messages in /var/log/messages from kresd
  3. kresd grows to 114 Mbyte (as seen by ps)

After a /etc/init.d/resolver restart, resolving works again for a few hours. Not sustainable, hence the switchback.


#170

Well, it must be the other way around – these messages show that there’s something wrong about the /tmp/kresd/tty/$PID socket but the script itself just feeds the DHCP names into DNS. I don’t know the source of the reported problems yet.


#171

yep - I switch off DNS over TLS and DNS resolution using kresd works fine now. I didn’t check the size of kresd process but the symptoms #1 and #2 were identical.


#172

As I mentioned elsewhere, I switched off the DNS over TLS from the GUI and I’ve re-enabled my custom stanza. I’ve not noticed any issues on my end of things.

I don’t get any messages ever from kresd. I don’t think it sends stuff to the system log unless you go through some hoops.

Also, should I have 6 PIDs in /tmp/kres/tty. Only one seems valid. All are owned by kresd:kresd except for the current one, owned by root.


#173

FWIW, and for debugging purposes, kresd does sometimes say something in /var/log/messages, I guess especially at boot time:

root@jib-router:/tmp/log# grep kres messages
2018-12-18 06:22:46 err kresd[1895]: [ ta ] active refresh failed for . with rcode: 2
2018-12-18 06:22:46 info kresd[1895]: [ ta ] next refresh for . in 4.8 hours
2018-12-18 06:22:48 err kresd[1895]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:22:58 err kresd[1895]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:09 err kresd[2868]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:09 err kresd[2868]: [detect_time_skew] cannot resolve '.' NS
2018-12-18 06:23:17 err kresd[2868]: [ ta ] active refresh failed for . with rcode: 2
2018-12-18 06:23:17 info kresd[2868]: [ ta ] next refresh for . in 4.8 hours
2018-12-18 06:23:19 err kresd[2868]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:29 err kresd[2868]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:36 err kresd[3116]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:36 err kresd[3116]: [detect_time_skew] cannot resolve '.' NS
2018-12-18 06:23:44 err kresd[3116]: [ ta ] active refresh failed for . with rcode: 2
2018-12-18 06:23:44 info kresd[3116]: [ ta ] next refresh for . in 4.8 hours
2018-12-18 06:23:46 err kresd[3116]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:23:56 err kresd[3116]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:24:03 err kresd[3432]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
2018-12-18 06:24:03 err kresd[3432]: [detect_time_skew] cannot resolve '.' NS
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'a.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'a.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'b.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'b.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'c.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'c.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'd.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'd.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'e.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'e.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'f.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'f.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'g.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'g.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'h.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'i.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'i.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'j.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'k.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'k.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'l.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'l.root-servers.net.', type: 28
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'm.root-servers.net.', type: 1
2018-12-18 06:24:04 err kresd[3752]: [priming] cannot resolve address 'm.root-servers.net.', type: 28
2018-12-18 06:24:12 info kresd[4720]: net.ipv6 = false
2018-12-18 06:24:12 info kresd[4720]:
2018-12-18 06:24:28 info kresd[5645]: [ ta ] key: 19036 state: Valid
2018-12-18 06:24:28 info kresd[5645]: [ ta ] key: 20326 state: Valid
2018-12-18 06:24:28 info kresd[5645]: [ ta ] next refresh for . in 24 hours
2018-12-18 06:24:39 info kresd[5645]: net.ipv6 = false
2018-12-18 06:24:39 info kresd[5645]:
2018-12-18 06:25:06 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:06 info kresd[5645]:
2018-12-18 06:25:09 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:09 info kresd[5645]:
2018-12-18 06:25:10 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:10 info kresd[5645]:
2018-12-18 06:25:12 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:12 info kresd[5645]:
2018-12-18 06:25:14 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:14 info kresd[5645]:
2018-12-18 06:25:16 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:16 info kresd[5645]:
2018-12-18 06:25:18 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:18 info kresd[5645]:
2018-12-18 06:25:19 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:19 info kresd[5645]:
2018-12-18 06:25:21 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:21 info kresd[5645]:
2018-12-18 06:25:23 info kresd[5645]: > net.ipv6 = false
2018-12-18 06:25:23 info kresd[5645]: