Browsing web on wifi - server not found

When browsing web on an iPad connected to Omnia, I sometimes encounter a “server not found” error and the page is not loaded. It happens e.g. with articles on archiv.ihned.cz (Czech news server).

What I’ve checked so far:

  • No errors in /var/log/messages
  • wifi disconnect -> works (the page loads just fine on cellular connection)
    While on wifi:
  • nslookup the server from Omnia -> works
  • ping the server from Omnia -> works
  • wget the page from Omnia -> works (even without previous checks)

When I try any of the above (nslookup/ping/wget), and then hit reload on the iPad, the page is loaded correctly.

What causes this strange behaviour?
Any hints for me where and what to check?
Thanks.

This looks like problems in DNS resolving. I gather you use knot-resolver on Omnia with forwarding disabled? We were now squashing multiple similar bugs in kresd, but the fixed version isn’t deployed to Omnias yet.

I haven’t tinkered DNS resolving in any way yet; using whatever was installed by default. Looking forward checking updated version. Hope it’ll make this go away.

I noticed the same problem occasionally too (last time this morning). But I have DNS forwarding enabled…
Unfortunately I had no time to do more test yet.

I think forwarding is the default. If it’s a DNS problem, it’s most likely from the server(s) forwarded-to, which are from your ISP unless you overrode that.

I can see no problems with archiv.ihned.cz (if that’s the exact domain) even on knot-resolver-1.1.1, which is the default version on Omnia, so it seems likely that turning forwarding off would fix the issue. Another way is to use some more reliable servers to forward to, e.g. those from CZ.NIC or others.

So I have checked - I have DNS forwarding disabled. Any other ideas?

@czbird, you mean the issue is still happening?

Yes, it’s still happening from time to time - just now I had the same issue with zive.cz

zive.cz is sometimes a bit problematic, as 3/4 of their nameservers currently fail to answer and kresd doesn’t do many retries by default. Trying again immediately should work around that.

Happened again on ihned.cz. Were the knot issues fixed, that you talked about earlier? Thanks.

again, when I performed nslookup on ekonom.ihned.cz, it started working (same as before)

Some notes from my experience …:

Everytime i visit some page for first time, it is loading very slowly (sometimes i receive ‘time-out’, instant reload get the page correctly). Any next visit is perfectly fine, fast like hell. I assume (as it was reported by several users) it is due dns/dnssec/knot/dnsmasq setup.

in FORIS there is in general DNS section (option to disable DNSSEC and enable ‘forwarding’). Some pages are not dnssec compatible so it make resolving a bit slower. Some readings and check if you have dnssec setup correctly: https://www.dnssec.cz/

That’s a confusing description (to me). Forwarding means that the resolution isn’t done in the router but just passed-through to some other DNS resolver (which you can configure) - as a consequence it is up to that one if they do validation and you’re not safe anyway if you don’t trust the link to that resolver, e.g. if it’s not very close (like 8.8.8.8).

Validation requires the resolver to do more queries to get all the records to establish trust chains from root to each resolved domain (or verifying that the chain ceases to be secured at some point). Doing all that will increase latency on cold cache, e.g. on the first query to a domain after a long time. Domains that are not secured require less work and thus suffer less from that cold-cache penalty.

1 Like

There are lots of fixes in recent new knot-resolver releases, but Omnia still uses older version by default AFAIK.

have the same issue - when I did troubleshooting i noticed i have some packet-loss on WIFI NW. As DNS is UDP i though this can be causing that … I also have random high pings on WIFI. Try to ping your router (keep it running for a while) to see if it behaves the same. I opened another topic on ping latency issue.