After update, many DNS records in NSEC zones are not resolved. Problems in browsers checked with 0skar DNS test (same as many times before).
Problem caused Omnia settings with enabled forwarding (Cloudflare, CZ.NIC and provider DNS setting). With disabled forwarding all 0skar DNS test passed again.
The 0skar situation discussed in January should not be changed. Is that what you mean? EDIT: end of explanation is in a pair of posts below that.
I know, but the scope of the problem is now wider.
Well, what exactly fails, if not just some of the 0skar tests? I’m not aware of any potentially related change in this release.
Don’t worry, @viktor just wants to discourage users to try this release. 
After 11 days of this release, he again raises issues about some tests, which does not prevent to use the Internet and it was already discussed in the post, which was mention
This is a serious discussion. That you sit on me and try to disparaged my contributions is obvious.
The question is still same.
And it´s not your question. Your answer came after 12 minutes. You just want to bully and censor my posts under the auspices of purity, because I don’t always have the same opinion.
It was tests 2a - 4. I don´t know why, but test 5 passed (Cloudflare and CZ.NIC, both TSL). Forwarding with provider DNS also passed 2b.
I also observe strange DNS behavior with the latest Omnia firmware. Just now Omnia isn’t able to resolve “http://www.projektsypo.cz/”
I have a similar experience. Approx. 15% of websites (none was a popular site) weren´t resolved (usually some smaller e-shops). Then I tried the test.
That one is like 3b test from 0skar.cz/dns . (to both of you) On my Omnia 3.11.15 I’ve been unable to reproduce any of these errors so far, with TLS forwarding or without. Assuming you’re not forwarding to some very old resolvers (like BIND < 9.9 mentioned on the test), I again see no better option than gathering verbose logs from some moment of failure: https://doc.turris.cz/doc/en/howto/dnsdebug#enable_verbose_logging
Fun part: http://anything-but-www.projektsypo.cz will throw an unfriendly error message, but yeah… wildcard CNAMEs are cool 
I reproduce this issue anytime. After switch from disabled forwarding is change not immediate.
Turning on verbose logging.
Switching configuration does not clear cache. That’s perhaps surprising and worth changing in future.
Why are you sarcastic?
It wasn’t intended as sarcastic. It honestly feels like it would be better if we change that behavior in future.
Then I do not understand what is to be surprising. It does not change of DNS tests the results of presented by me. It was also confirmed by another user.
I think it may be surprising e.g. that when people change the target of forwarding, records from the previous servers remain in cache. This combining may (theoretically) lead to changes seemingly not completely apply immediately or to more complex consequences. I certainly wasn’t trying to claim it causes the issue you reported, but it might have some temporary effect on these experiments when you switch the forwarding configuration.
Thank you for the explanation and I fully agree.
