I don’t know - I know why I use it - to ensure the resolver is reset on disconnecting VPN.
Same reason I run a bind nameservice using only root servers with response policy zone to filter domains on network level - control - leave nothing to chance.
Why do you have to do this step?
You don’t have to - systemd-resolved can work with an existing resolv.conf - but it creates a possible point-of-failure - and using the stub symlink is the recommended (upstream) method.
I’m not sure i understand what a stub symlink is?
Edit: I’ll read up on it.
It is the link to the stub file systemd-resolved uses to write dynamic resolver info to - the file only exist when systemd-resolved is started
I sort of understand what it’s doing. 
1 Like
@Root
I don’t use a vpn or have any fancy network setup. It’s just the standard EOS install. I do have fast internet connection though. Just trying to understand this and if needed or useful. 
I am replying late because your long and thorough post inspired me to do some research/testing.
I tested the speed/latency for both systemd-resolved and knot-resolver. Using the same DNS systemd-resolved always toped it. I used drill and compared Query time. Please see the edit.
So what is the lag I am talking about? When I just login and open Firefox, type in a website and hit enter it takes a good few seconds to load the website (loading symbol on tab and the page is blank for more than 5 seconds) when using systemd-resolved (with DNS over TLS) but not with any other DNS resolver. Sometimes it happens even after browsing for quite a while, so it’s just not “cold start”.
So finally, after some glourious years of web browsing experience with Firefox I switched to ungoogled-chrome with almost the same extensions I used on Firefox. I see no such lag with systemd-resolved + DNS over TLS and I am shocked to see how snappy youtube.com is compared to Firefox on my low-end system! Nothing shady I hope. Also this and this.
Now, the domain manjaro.br is interesting. The config I asked you to test out, 45.90.28.0#3faf98.dns1.nextdns.io, is one provded on NextDNS homepage (whick keeps changing from time to time). I created an account with NextDNS and my config is different but other than the block list everything should be the same.
Now when I try to query the domain manjaro.br:
❯ resolvectl query manjaro.br
manjaro.br: resolve call failed: 'manjaro.br' not found
❯ drill manjaro.br
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 14477
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; manjaro.br. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
br. 229 IN SOA a.dns.br. hostmaster.registro.br. 2022150114 1800 900 604800 900
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.53
;; WHEN: Mon May 30 10:30:06 2022
;; MSG SIZE rcvd: 90
Interesting, drill works but not resolvectl. But both use systemd-resolved!
My DNS config:
❯ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .
❯ ls /etc/systemd/resolved.conf.d
dnssec.conf fallback_dns.conf nextdns.conf
❯ cat /etc/systemd/resolved.conf.d/nextdns.conf
[Resolve]
DNS=45.90.28.0#xxxxxx.dns1.nextdns.io
DNS=45.90.30.0#xxxxxx.dns2.nextdns.io
DNSOverTLS=yes
❯ cat /etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=84.200.69.80 195.10.195.195 2001:1608:10:25::1c04:b12f 2a03:4000:4d:c92:88c0:96ff:fec6:b9d
❯ cat /etc/systemd/resolved.conf.d/dnssec.conf
[Resolve]
DNSSEC=false
❯ resolvectl status
Global
Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 45.90.28.0#xxxxxx.dns1.nextdns.io
DNS Servers: 45.90.28.0#xxxxxx.dns1.nextdns.io 45.90.30.0#xxxxxx.dns2.nextdns.io
Fallback DNS Servers: 84.200.69.80 195.10.195.195 2001:1608:10:25::1c04:b12f
2a03:4000:4d:c92:88c0:96ff:fec6:b9d
Link 2 (ens32)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
I disabled DNSSEC hoping it will make the querying faster. Wonder if it’s worth it. When I test with DNSSEC off , query time is 90ms - 160ms. With on 200ms - 370ms. But maybe more testing is needed.
EDIT
I forgot to turn off DNSSEC in knot-resolver while I turned off DNSSEC in systemd-resolved. From my meager testing, it looks like DNNSEC is in fact time consuming and DNS resolvers perform much better when it is turned off. And both systemd-resolved and knot-server perform the same.
Firefox is typically not that slow. Can your problem have something to to with dns-over https?
Firefox is typically not that slow.
That’s true. I am only talking in this scenario of using systemd-resolved with DNS over TLS. Also I made sure I disabled / Opted out Firefox’s internal DoH option. Also I used DNS Leak Test to confirm that Firefox is indeed using the DNS I specified in systemd-resolved.
I do something far simpler: create your OWN resolv.conf and then chattr +i it. Systemd can’t touch it and you DONT have to stop the service. works fine every time. I just use my own resolver on my firewall.
Thomas