On nightly the generated rule is “given least precedence”, so this inconvenience shouldn’t be an issue anymore (soon). BTW, this shadowing is nothing new in 3.11.* – it’s always been so on Omnia with the classic plaintext forwarding.
Could you please explain how the configuration should look now to resolve every host via cloudflare except the few hosts which are resolved via another dns server, specified by the ip address? I don’t get if this even possible with the latest Turris OS
With the change I mentioned, such combinations of generated and custom configs will be usable, as custom policy rules will apply before the generated forwarding rules. Of course, the warnings from knot-resolver docs apply, etc.
Ok, so such configuration is now broken until the next update or the manual /etc/init.d/kresd replacement. Got it, thanks.
Could you please also explain what does actually forward_upstream option mean. As far as I can see, wiki page got updated. Previously this option had to be disabled while now it must be enabled for DNS over TLS to be working. It’s not clear what is the reason of that. There is the following sentence on the wiki-page: “Forwarding now works properly”. Was it a bug in previous version of Turris OS?
I don’t get how dns-resolving would now work if forward_upstream is set to 0. Which scenarios require that?
1 Like
If not mistaken forwarding makes the difference between dns queries recursion and dns queries iteration and may include dns response validation well. Basically setting the scope of the participants in the dns query chain - who is doing what and to which extent.
Forwarding dns queries to an upstream server might be necessary/imperative if such queries being controlled/censored by a third party, commonly an ISP or cooperate governance.
And on the contrary it enables the administrator of a dns resolver to specify which upstream server to utilize, e.g. CF and not having to contact the root domain name servers for their referrals to the TLD and further down the chain to subdomains. Which can enhance privacy and/or speed up dns queries.
Merry Christmas everyone!
I’ve done no troubleshooting as of yet, but I am having DNS issues as well as of the latest update(s). After a certain period of time (~8 hours?) DNS just stops working, and then I get complaints that “the internet isn’t working”. A reboot of the router fixes the issue.
Given the length of this thread, it would seem something is seriously broken with this update and it needs to be fixed ASAP. Nothing in my setup has changed except for the update to the Turris Omnia so it must be this.
1 Like
It look like i have the same issue.
I’ve done some troubleshooting, and I believe I may have found something that could be related. I’ve enabled verbose logging in kresd, and from what I can tell, whenever it starts to fail, kresd gives the ipv6 dns server a score of 1, while the ipv4 one gets a score > 1. I have ipv6 completely turned off in WAN though as my ISP currently does not support it, which I’m guessing is why it fails? I tried commenting out the ipv6 server address in the dns conf file, and it seems to work consistently now.
So to everyone who has this issue, do you have ipv6 disabled?
Seems to me like it shouldn’t use the ipv6 address at all if t’s disabled in wan, is that a wrong assumption?
Also, I added some debugging code to lib/nsrep.c in kr_nsrep_sort, and I happen to know that rtt_cache_entry is null on the ipv6 address, which is why it gets a score of 1.
The DNS has been working for me ever since I used foris to switch to “use forwarding” checked, DNS forwarder: Cloudflare (8 days now). I’m not sure why the DNS was breaking every day, and now is working. It was not working after a factory reset with “use forwarding” unchecked.
My ISP (Comcast in Boston, MA, USA) does not appear to support IPv6. (It is also possible that my cable modem does not work with IPv6, but the specifications of the Zoom Model 5350 modem says it is fully supported.) Having just done a 3-led factory reset on my Turris Omnia, it is running with all default settings (except SSID, pasword, and DNS, which I configured via foris as above). It appears to be assigning IPv6 addresses to local devices, but I don’t think these can be used without an IPv6 address from the ISP.
Right, the problems you have are known to us for a while, so you didn’t need to dig into c sources 
It’s a combination of several issues (and a misunderstanding within cz.nic, kind of). With kresd >= 3.2.0 most of that should be mitigated, but that version isn’t in stable Omnia yet.
I can only hope that most of people suffer from the same reason, though e.g. the first post in this thread does not fit that (has problems even without TLS). That’s why I’m always asking for verbose logs; it’s usually difficult to be certain without them.
ATM you should experience this “IPv6 issue” if your /tmp/kresd.config ends up with TLS_FORWARD containing IPv6 address(es) and you have kresd <= 3.1.0 (default stable Omnia). Right now I don’t remember when exactly IPv6 gets generated into the config (e.g. I don’t get it in there even though I do have working IPv6), which is why I’m writing it in such a round-about way.
Well, my DNS just broke after 8 days. I tried the verbose logs command and it gave me a ‘broken pipe’ error:
root@turris:~# echo ‘verbose(true)’ | socat - /tmp/kresd/tty/“$(pgrep kresd)”
2018/12/28 14:53:55 socat[31083] E write(5, 0x16c4010, 14): Broken pipe
My DNS is not working:
opuntia:~ kslays$ time nslookup forum.turris.cz
;; connection timed out; no servers could be reachedreal 0m18.037s
user 0m0.005s
sys 0m0.007s
I used foris to generate diagnostics for the dns module and for all the modules. I’ll email them to vcunat.
I also logged into LuCI and noticed the notification at the top right “unsaved changes: 4”
dhcp.cfg02411c
dhcp.cfg02411c. filterwin2k
dhcp.cfg02411c. nonegcachedhcp.cfg02411c.nonwildcard= 0
dhcp.cfg07fe63= host
I don’t know how that got there. I might just do another 3-led factory reset, then update to 3.11.1 with this command:
/usr/bin/updater.sh
I’m skeptical that will work though because it didn’t work last time.
Unfortunately, I won’t be able to help for a week due to travel. When I get back we are switching from Comcast to Verizon FiOS.
I decided to change the foris settings to:
Use forwarding [check]
DNS Forwarder [Use provider’s DNS resolver]
Disable DNSSEC [check]
I then tried the logs again:
root@turris:~# echo ‘verbose(true)’ | socat - /tmp/kresd/tty/“$(pgrep kresd)”
> true
I’m don’t know what that means.
Then I checked the DNS:
opuntia:~ kslays$ time nslookup forum.turris.cz
Server: 192.168.1.1
Address: 192.168.1.1#53Non-authoritative answer:
forum.turris.cz canonical name = proxy.turris.cz.
Name: proxy.turris.cz
Address: 217.31.192.69real 0m0.261s
user 0m0.006s
sys 0m0.010s
It looks like foris has not configured the router correctly, and it is not sending my ISP the DNS request, is that right?
No, nslookup can’t show anything like that. It shows name resolution result, in this case a good-looking one for forum.turris.cz.
1 Like
That’s probably the wrong place to ask but still. Could you please tell how to disable logging of those
info kresd[32116]: > hints.del(...) and
> hints.add_hosts(...) messages? Looks like kresd logs every command received via control socket to syslog with info level and that produces a lot of noise I’d like to get rid of.
There’s only very little choice about what gets logged on kresd side. On config side I believe changing log_stdout in /etc/config/resolver would do it, but it will disable lots of other messages as well.
That’s what I am talking about. Do you mind adding more options for precise logging configuration in future?
I’m not against that, but honestly it seems very unlikely to happen soon. We now have a long list of stuff that’s considered much more important and the dev team is tiny.
Is this issue with DNS queries scheduled to be fixed soon?
That’s not what I am experiencing.
I did turn of wan6 completely, but yet the /tmp/kresd.config shows the following entries right after turning on Cloudflare DoT:
net.ipv4=true
net.ipv6=false
cache.open(20*MB)
policy.add(policy.all(policy.TLS_FORWARD(
{{'1.1.1.1'
,hostname='cloudflare-dns.com'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
}})))
But I provided a log file - could you have ->a look into it?
I found the real cause. It was my mistake.
Considering the OP says the router is set to its default factory settings, your solution isn’t relevant, since it would require an already modified config.