I am having some issues with kresd on a Turris Omnia that I am fairly sure is going to be down to user error.
Any way to get multiple TLS connections upstream?
The biggest problem is that, I manage my own forwarder externally from my network. The Omnia is configured to forward (over TLS) to this external forwarder. The external forwarder has 2 IP addresses.
What I am seeing is, that if kresd gets hit hard with a lot of queries (and by hard I only mean like 10 requests a sec) and the responses its getting from upstream are slow (say 1 second for the sake of testing), then things back up and everything time out. At all times, kresd only holds 2 connections open (one per IP) to the upstream resolver. I would expect it would open more connections when under load? Can I configure it to do this? Since there is no concurrency at all right now
DNSSEC
The other question is my knowledge on DNSSEC is sketchy. If the final resolver in the chain is doing DNSSEC then I should turn OFF the DNSSEC option in Reforis right? otherwise I am just creating more performance problems?
No, that would be against the RFCs. They mandate keeping one persistent connection and all queries go over it. It’s like HTTP/2, so the queries and answers don’t block each other in any way, except for when on-path packet loss happens (which is inherent thing for TCP-based transports).
Maybe your proxy doesn’t support this asynchronicity well, but DNS over TCP has exactly the same for decades, and DoT simply added encryption on top of that.
No, it’s better to keep it on. Otherwise you can get into issues. For example if one of the servers has bad DNSSEC: if you validate, you’d retry with other servers until you get a good answer. If you accept a bad one (because you don’t validate), you will keep serving it from cache to your users – and if those validate, their retries won’t help…
I’ve read in the documentation about some upstream servers are not supported. I can see that for example CoreDNS does open more connections upstream when using DNS over TLS when its under load.
Do you happen to know if CoreDNS falls into the category of servers that don’t play nicely with kresd? I am probably going to replace CoreDNS with kresd at some point anyway.
Be glad when DoQ is adopted more, might help with some of this stuff
I’m not aware of that. And I can’t recall hearing any CoreDNS feedback, positive or negative.
DoQ doesn’t change this. It mainly reduces handshakes by one round-trip, and it behaves better in case some packets get lost a lot (not common, but perhaps in some wireless cases). And we do work on DoQ support this year, incidentally.
@vcunat So I’ve got set up on Knot Resolver 5 with some lovely bits of LUA that serve a different block list based on systemd instance.
So you can imagine my face when I read about the changes coming in 6
I looked at views and tags which looks cool, but can only set a tag from subnets or protocols at the moment. Would be awesome to set based on listener port also (or just be able to set tags on the listener themselves).
Possible to PM me with how I can get Gitlab access or where to email such suggestions?
Sorry this isn’t Turris specific, whenever I google stuff about Knot Resolver your name always pops up
My use case is I’m running a personal (though public) resolver and I have two ports for DoT and two for DoH. The extra port on each is for a much tighter blocklist (kids for example).
Since I’m keeping cloud costs low I dont want to double the amount of servers or even public IPs.
I know non standard DNS ports are frowned upon but they can and do work.
So I guess I’d be looking for a view rule for dst_port to tell if or not to add the supplementary blocklist.
I’m fairly bad at C but I could try and pull request this since I know its probably niche
This function does not work properly, does not take into consideration for ACLs. Use case: a server has a TLS certificate shared between a few services, so it is owned by root and each service that needs to use it gets a “read” ACL applied. Can’t make it owned by lots of different usernames so must use ACL.
In this patch I just deleted the function but it might be better to re-write it so it actually checks access to the file rather than compares file permissions.
. It does work but probably isn’t a great implementation.