Originally posted by aht0
View Post
The reality here is once you have sent resolved configuration files to have a DNS the "FallbackDNS" is not used unless there is a bug in systemd. This bug is a person asking for the behaviour you are talking about and being refused. So /etc/resolved.conf existing with entries automatically kills built in FallbackDNS entry even a stupid entry like 0.0.0.0 will prevent FallbackDNS built in being used.
There are complains that resolved cycles too fast though the resolved.conf list.
https://github.com/systemd/systemd/issues/5755.
But the logs show everything functional as expected. Sometimes as the person here does you need to run a proper dns cache. Dnsmasq is a local cache.
A dns resolve not a DNS cache. The DNS resolver built in libc behaves no better in fact worse.
aht0 just because something appears random does not mean it is. From all those who have in fact looked at their logs no one has found it a random problem coming from the way resolved does things but from issues with the DNS server the system is dealing with. Yes some routers are known for being under powered and causing these issues and some cases with VPN having time out problems so it does what its meant to moving on to the next DNS server in the lookup list.
If your problem requires dns cache and dns cache intelligence attempt to use systemd-resolved will give you problems because it the wrong tool for the job. Maybe someone might put in a feature request for systemd-resolved to add the features of dnsmasq with domain being direct-able to particular DNS servers and caching so that unstable dns servers get less requests basically grow DNS cache functionality.
Comment