I don’t think kresd should be noticeably slower, at least if you give it the same conditions – same target to forward to, disabled dnssec, etc.
Yes, I think it is DNSSEC causing significant slowdowns.
Well, I guess I couldn’t wait until Saturday. My Omnia is back, alive and kicking. And now with today’s OpenWrt 18.06 snapshot. Seems to be working great, I obviously lost the RGB control of the LEDs, but it’s no biggie (and just a matter of time, I wager), compared to the huge benefits of an updated kernel/distro.
1 Like
Your issue seems to me as related to unchecked DNS forwarding in Foris’s DNS tab, but keep in mind that DNSSEC should be enabled. Did you try to change DNS servers?
Why must DNSSEC be enabled? Why do you need it?
The answer is pretty simple - security.
If you understand Czech that we have a really cool website for DNSSEC, where you will also find short education video, which explains what is DNSSEC and why you need it, but if you don’t understand Czech don’t worry. I’ll give you a short explanation.
Technology DNSSEC protects against data spoofing and ensures that the content is authentic.
It’s been about a month since the attack to the site, which provides open-source client interface for generating Ethereum’s wallet was hijacked by using DNS Cache Poisoning if they were using DNSSEC/HSTS it’s possible that the attack would be avoided.
I know a very interesting article, unfortunately, in Czech, but I think you can also find some in English.
That’s why the DNSSEC is required by default on the Turris routers to avoid such of these problems.
If you’re interested in more details of DNSSEC you can look at this site.
Anyway, I really don’t get, why do you want to use dnsmasq, because dnsmasq doesn’t support DNS over TLS with many other things.
@paja is working to have support for DNS over TLS in Foris, which will be for Turris Omnia, which is using Knot Resolver and it is also used by Cloudflare and also for Turris 1.x, which because of the architecture using unbound, so it’s not really necessary to create issue on Gitlab for updating unbound.
We said here many times that the state with packages is just temporary. We’re doing our best to bring it to you faster, because it will help us, too. Well, we have only two people, which are maintaining a large number of packages. To bring you Turris OS 4.0 on the Turris Omnia it depends also on our kernel guys. Don’t forget that we need to have the smooth update from Turris OS 3.x. to Turris OS 4.0 or with minimal manual intervention. There is a really a lot of work before we’ll be able to bring it to you.
For advanced users, we will bring it sooner. We’re tweaking updater, so we could migrate e.g. from uClibc to musl on Turris 1.x. You can see what we’re doing on our Gitlab. We’re working on Sentinel, which was mention in our first Developer updater.
We’ll publish another update soon. E.g. since Turris OS 3.10 you can even boot from mSATA SSD.
But let’s focus on bright future, right? Don’t forget that we’re people and it doesn’t help us much, because we know about it. :’(
1 Like
[ Well, isn’t this thread well-and-truly hijacked! ]
You have my sympathy. My point was: If Turris OS is mainlines with OpenWrt, then there’ll be a much greater pool of people keeping the packages up to date. Maybe don’t update any more packages, just concentrate on getting Turris in sync with OpenWrt?
BTW, @Pepe, did you see my points about adblock - maybe that could be addressed? The ddns-scripts issue may also be worth chasing, but I warn you that ddns-scripts has other problems running on my TO (and I note with other people routers) & I’ve had to disable it (it was causing serial reboots). These are easily two of the top ten packages on Turris OS.
I note that dnsmasq supports DNSSEC, and kresd doesn’t support CNAMEs…
Anyway, I once was an IT security boffin (consultant, guest lectures at Uni, etc.). What I used to teach my students right at the beginning was (amongst other things) the CIA model:
- confidentiality,
- integrity,
- accessibility
You have to get all 3 right. If two are perfect, but there other isn’t, then you’ve got a problem.
I know how DNSSEC works, and TLS, etc. DNSSEC is all about integrity (the address given for a name is the correct address for that name) but (for me, and others too), the price paid in accessibility is currently too high. That is, it is too slow: I am talking about 3-5 seconds to resolve a name.
Just.
Too.
Slow.
I tried everything to fix it & gave up - not supporting CNAMEs was the final insult.
Being a good citizen, I have submitted a bug:
1 Like
TO is aware of the fact. unlikely to change prior to TOS 4 with unknown eta and probably still far out
Thanks for these instructions… the vfat note caught me. ick.
I’ve flashed 18.06, including an 18.06 that I built from source. I noticed that the openwrt builds do not use very much of the disk space. I think that we need some different partitioning to make it work right.
I wanted to go back to the Turris firmware, so I prepped a USB key as per https://doc.turris.cz/doc/en/howto/omnia_factory_reset
It didn’t work yet, I suspect that I may need to restore additional partitions?
How were you able to unbrick your Omnia, I’m in the same situation that you were in?
You will need a usb to TTL cable to restore the default environment (search the commands at openwrt forum) at boot.
Then for openwrt just use an ext4 formatted usb with the 4 leds method. Probably the same method for turris os.
First reset uBoot (removing the OpenWRT customizations) with:
env default -a
saveenv
Wow! Thanks. This worked for me, after a failed flashing of upstream OpenWRT. First time I’ve had a success with a USB UART device.