I don’t think there’ve been any relevant changes for months. You can gather verbose logs for a failing moment.
1 Like
Looks like I had Forwarding enabled in Foris - I usually only go to LuCI.
I remember enabling it because there were issues in the past. I’ll test some more and report back.
Have been able to make problem disapear. Seems that resolver options were been taken from network files and not from Luci interface dns options. Only resolvers being used were google’s 8.8.8.8 and 8.8.4.4. After a while they would be rejected and being considered non trustable by the resolver (had installed dns debugging logs).
To solve i added in the network file cloudfare 1.0.0.1 dns and troubles seem to have disappeared… Sometimes resolving seems to get slow… I will organize logs and send them when possible…
I experience the same issues. After some time Omnia is not able to resolve some names.
For example:
root@turris:~# nslookup amazonaws.com
nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'amazonaws.com': Name does not resolve
Forwarding disabled, DNSSEC enabled. Connection test in Foris shows both OK.
Restarting the resolver does not help. The only thing which works is restarting the router. Quite annoying.
@Pepe This is definitely something the support should look into!
1 Like
Followed the instructions in Debugging DNS problems on Omnia but something is wrong.
Installed the resolver-debug package, enabled verbose logging, waited until the problem occurred and downloaded the debug log.
To my surprise all I got was the regular system log, nothing related to name resolving.
@Pepe, @vcunat Is there any way how to effectively debug this issue?
It may be possible the router has rebooted on it’s own or some services has been restarted automatically and debug logging has been disabled. If that is the case, there is an additional issue with Omnia.
The luci pages only configure dnsmasq which does not do DNS on Turris (by default). I expect all luci stuff is just taken from upstream OpenWRT, I think (or almost all). I believe for any configuration it’s best to try Foris first, unless you “know what you’re doing”.
27.10.2018 about 10:05 and subsequently failed to connect to technet.idnes.cz.
After 2-3 failed reload, I started the DNS debug and continued to try to access this page and other functional sites. After the connection succeeded, I stopped debugging.
In support I sent debug log, sys log, kernel dump and files '/tmp/kresd/*. mdb ’
Total 1.2 Mb zipped
Hello @JardaB,
I know that you’d like to solve your issue as soon as possible, but this doesn’t give it a higher priority. We received your email yesterday, and as it is currently weekend even today we have the public holiday, it needs to wait for tomorrow or at the beginning of the next week. Thank you for your patience.
I noticed that somebody tags me here. I know about it, and more answers will follow.
I now, don`t hurry … 
>/]
In the specific case of amazonaws.com the issue may be connected to adblock.
# /etc/init.d/adblock query amazonaws.com
::: results for domain 'amazonaws.com'
+ amazonaws.com
After whitelisting, resolving works again. For now at least.
I am confused by the fact, that it has worked for some time, then not.
Also I am still wondering how to gather the logs. The debugger stops for some reason or logging is restarted so there is nothing useful in the log anymore.
Just spotted:
2018-11-02 13:12:01 notice syslog-ng[17834]: syslog-ng shutting down; version='3.10.1'Hello,
I have good news for everyone here.
Knot Resolver developers including @vcunat found the culprit for the issue, which affects mostly domains hosted at IGNUM. Yesterday, they released a new version 3.1.0 of Knot Resolver. Changelog can be found here.
Our developer Honza (@paja) was working on updating it to Turris routers. 2 hours ago, he updated in nightly branch Knot Resolver to version 3.1.0, if everything goes well as I hope so, I’d like to do my best to include it into Turris OS 3.11, which is currently in RC or at the latest by 3.11.1 as we don’t want to delay the release 3.11, but I’m fully aware that this issue can bother someone of you.
@DavidO: We understand that it is a little bit confusing how to do forwarding to some DNS servers in OpenWRT, because they are two ways how to do it, but only the way, which you described is correct as the devices use DNS resolver on Turris routers, so they use cache and DNSSEC on Turris.
First, you’d need to enable DNS forwarding in Foris and then fill there the IP addresses of DNS servers in LuCI → Network → DHCP and DNS. Sometimes you need to restart the devices, which you’re using, so they reflect the change. They could have it in the cache.
A few days ago, we released Turris OS 3.11 into RC, where you can find predefines list of DNS servers, which you can use and some of them with DNS over TLS to avoid this issue, but this issue should be fixed very soon in Turris OS.
I think it’s a good idea to have Turris OS version included in LuCI, we’ll think about it.
3 Likes