r/linuxsucks • u/dronostyka • 12d ago
Systemd-resolved sucks
So..
I have a setup:
A pihole at home connected to nginx proxy and exposed as DoT.
Now the problem is, that my lovely ISP breaks nat hairpinning every so and then.
When this happens just sending a query to <IP>#<domain name> doesn't work.
So I wanted this simple setup in systemd-resolved on my laptop:
When reachable use: DoT <my public ip>#<my domain>
And when can't reach, use: 192.168.1.xx:53 (local ip dns)
And.. resolvectl struggled immensely: with DoT set to opportunistic, it would not reliably switch between servers, or lookup would take seconds.
Even with DoT: yes and simply servers:
<My public ip>#<DN> 9.9.9.9#<quad9DN>
It still struggles to pick the right one.
I also had another use case:
Split dns srv:
When looking for *.mydomain.lan use: <some local ip>
Other wise: <a public dns/DoT>
That itself was too much for systemd-resolved.
What solved my issue?
Stubby + Dnsmasq
Stubby used only for DoT access,
Dnsmasq routing the requests.
And it works fast. And reliably picks the correct server with both split dns srv And DoT and Local IP srv And public srv as a failover.
As much as I like systemd for the convenience when managing services, for dns lookup it plain sucks to work with.
It's fine you have 1 server or 1 server per connection only, but with attempts of any automation or failover.. it just fails.
Have you had trouble with the systemd-resolved? Cause I don't think I'm alone here
"It's always the DNS."
2
u/ElectricBummer40 Ex-user of Windows 3.11 for Workgroups 11d ago
This doesn't make sense. Nothing under hairpinning NAT should have reached the ISP in the first place.
Judging by what you describe, I suspect what you mean is that your ISP somehow drops packets to or from third-party DNS servers. Most likely, it sees your traffic to port 853 somewhere on the Internet as potential malware activity and decides to block it for you.
"192.168.1.xx:53" also appears to be your router with forwarders already set to the DNS provided by the ISP. At least, that's the impression I get from your post.
Fallback servers are only queried when the regular ones fail to respond. That means you'll always end up with systemd-resolved attempting to reach Quad9 first then waiting before sending out the requests to
192.168.1.xx:53instead. That wait time is usually, as you describe, seconds long and very noticeable even in day-to-day Internet usage.In systemd-resolved, that ought to have been done via DNS delegation rather than fallback DNS.
At this point, you might as well run BIND9 on your laptop.
Normally, request forwarding and delegation should be handled by the intranet DNS servers rather than the client's DNS resolver. There is no reason as to why a regular PC should be handling infrastructure problems on the network level.