I am done with you. If you are continue with this, we can start using confidential issues. You are acting like one mayor of one unnamed part of Prague. The issue does not mean anything.
Did we release it to RC? No.
Are we confident to release it to RC? No without proper testing. It is internal release of Turris OS 3.11.14.
Did we do kernel update as you wish? Yes, we do.
Will we release Turris OS 3.11.4 RC with updated kernel? We will see if we narrow down the issue, which was in the past.
I also have DNS problems to. kresd stops resolve dns addresses.
I sent a description of a cli error with and diagnostic foris support file in support. The support number is [turris-L1 # 1055088] kresd.
I received a text from the support confirmation email to contribute to the forum:
Hello,
thank you for your message. A request for support has been created. We will reply to your message as soon as possible, but due to number of questions regarding our recently finished campaign, it may take a little bit longer.
What you would like to tell us? It does not make sense include two links in your post without anything. As I told you earlier, it does not mean anything. We havenāt released 3.11.14, yet. Anything may change and you can see when I was committing those changes.
Last week I failed to find the right part of your log. Today I tracked it to a known bug. I didnāt recall it at that moment. This test just wonāt be reliable (for now); itās a bit confusing that it only fails sometimes.
The linked bug has been there since forever. Theoretically itās possible that some other recent change resulted in it happening āmore oftenā. In any case, this validation failure hasnāt been confirmed anywhere in practice so far (except on testing domains), so it has low priority and thus itās been waiting for larger careful rewrite of the corresponding code.
Continuing in English.
Your logs show running Unbound with TLS forwarding to cz.nic (and validating DNSSEC locally). I assume Turris 1.x, but I guess the main thing is that itās Unbound and not Knot Resolver.
Iām not good at reading Unbound logs, but I did found occurrences where rhybar domains were correctly refused due to invalid signatures (and no forwarding config can make that pass), so I wouldnāt expect issues in there.
I donāt know, if it happens reliably, Iād perhaps first try checking that your client machine isnāt trying another (non-validating) server as a fallback on āfailuresā. How? Hopefully running nslookup rhybar.cz on the client machine would show that (even on Windows). On a Linux machine it looks like
$ nslookup rhybar.cz
;; Got SERVFAIL reply from 192.168.1.1, trying next server
[...]
Thank You for checking the log (that is, if you responded to my problem). Command nslookup rhybar.cz
Putty reply:
;; connection timed out; no servers could be reached
Yes, I responded to you.
The server correctly fails to resolve the name, so DNSSEC validation would seem to work (a bit at least). Currently Iām out of ideas.
Iām a bit surprised by usage of fd** address. I canāt remember ever seeing these on Turrises in ip -6 a output, but I donāt expect a problemās in there and your Turris really replies (also) on this address.
It is also interesting that I do not use IPv6 addresses and in foris i have forward to DNS cz.nic. Test me connected to the non-functional DNSSEC voice. On the second PC connected to the same Turris 1.1, the DNSSEC test is in counseling.
