DNS server changes not being applied

Ask Fedora
, ,
1

hello! i just installed nobara linux and today is my first time using fedora. i have been using debian based distros for a while now and due to random restrictions from govt. and/or isp, i have always had a better experience when i change my dns to cloudflare’s with quad9 as fallback. i am used to of using the resolvconf package, but in fedora that doesnt seem to exist and refers me to an already installed openresolv package.

so then i gave up on that and decided to follow the manpage’s instructions and also found this answer here referencing the same, and created /etc/systemd/resolved.conf.d/override1.conf with the content:

[Resolve]
DNS=1.1.1.1 9.9.9.9 2606:4700:4700::1111 2620:fe::fe
FallbackDNS=1.0.0.1 149.112.112.112 2606:4700:4700::1001 2620:fe::9

this however doesnt get used as even after relogging in and restarting, dig shows my isp’s dns servers are being used. what am i doing wrong? any help is appreciated.

1 Like
2

Fix SELinux labels and discard DNS pushed by DHCP:

sudo restorecon -F -R /etc/systemd/resolved.*
sudo rm -f -R /run/systemd/resolve/netif
sudo tee /etc/NetworkManager/conf.d/00-custom.conf << EOF > /dev/null
[main]
dns=none
systemd-resolved=false
EOF
sudo systemctl restart NetworkManager.service
sudo systemctl restart systemd-resolved.service

If the issue persists, check the output:

resolvectl --no-pager status
resolvectl --no-pager query example.org
3

hi! thank you for the reply.

i followed the instructions, but still no good. according to dig www.google.com:

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

and dig -6:

;; communications error to ::1#53: connection refused

Output of resolvectl --no-pager status:

cd@laptop:~$ resolvectl --no-pager status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 1.1.1.1
DNS Servers: 1.1.1.1 9.9.9.9 2606:4700:4700::1111 2620:fe::fe
Fallback DNS Servers: 1.0.0.1 149.112.112.112 2606:4700:4700::1001 2620:fe::9

Link 2 (wlo1)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

Outpur of resolvectl --no-pager query example.org:

cd@laptop:~$ resolvectl --no-pager query example.org
example.org: 93.184.216.34 – link: wlo1
2606:2800:220:1:248:1893:25c8:1946 – link: wlo1

– Information acquired via protocol DNS in 51.0ms.
– Data is authenticated: no; Data was acquired via local or encrypted transport: no
– Data from: network

4

although i am observing something curious. on chromium, dns provider is selected to 'OS default (when available) and i cleared cache at chrome://net-internals/#dns.

but i am still able to visit sites that i know for a fact my isp’s dns doesnt resolve. i dont know if this is relevant, just thought i’d mention it if it helps.

1 Like
5

Your output is correct according to the documentation:
resolved.conf: Network Name Resolution configuration files | systemd-resolved File Formats | Man Pages | ManKier

Perhaps there’s a misunderstanding and you expected to see something else?

6

well (from debian) i am used to of seeing 1.1.1.1 (or one of my other specified dns ips) in the server line.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Apr 10 10:09:59 IST 2024
;; MSG SIZE rcvd: 59

also i have never before seen dig -6 give:

cd@laptop:~$ dig -6 www.google.com
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused

; <<>> DiG 9.18.24 <<>> -6 www.google.com
;; global options: +cmd
;; no servers could be reached

so i assumed it wasnt working. is this expected behaviour?

7

Yes, this is how it is configured on Fedora by default.
The stub resolver binds to 127.0.0.53 IPv4 only, no IPv6.

8

okay. thank you so much.

i am so sorry if i wasted your time.

thank you again.

1 Like
9

Note that FallbackDNS is ignored when DNS is specified explicitly, so it is best to list all resolver IPs in the latter option and remove the former.

By the way, some ISPs perform content filtering with DNS hijacking, so be sure to enable DNS encryption if you want to bypass it.

2 Likes
10

thanks, i will look into dns encryption. thank you again for your help.

1 Like
11

this.

[Resolve]
DNS=1.1.1.1 9.9.9.9 2606:4700:4700::1111 2620:fe::fe 1.0.0.1 149.112.112.112 2606:4700:4700::1001 2620:fe::9
DNSSEC=true
DNSOverTLS=true

See the manpage on systemd resolved.conf

1 Like
12

yep. that is pretty much how mine looks after following vgaetera’s instructions.

13

In your case I would also enforce DNSSEC and DOT, instead of using “opportunistic”, to really enforce using secure DNS

14

I dont understand what this does, does Networkmanager have any priority in setting DNS?

This is useful to know, but when setting a DNS server manually normally it should be preferred, if not isnt that a bug?

15

You are missing SNI suffixes necessary for hostname verification.

Also note that DNSSEC is disabled by default due to compatibility problems, and if your DNS provider validates DNSSEC on their side like Google does, then enabling local validation is essentially overkill, just increasing latency.

Personally, I prefer a setup like this:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/00-custom.conf << EOF > /dev/null
[Resolve]
DNS=8.8.8.8#dns.google
DNS=8.8.4.4#dns.google
DNS=2001:4860:4860::8888#dns.google
DNS=2001:4860:4860::8844#dns.google
DNSOverTLS=yes
EOF
sudo systemctl restart systemd-resolved.service

Interaction with NetworkManager is redundant in this case, so disabling it prevents any possibility of DNS leaks and helps clarify otherwise ambiguous status output.

1 Like
16

Thanks! What is the hostname verification needed for?

1 Like
17
1 Like