I want to set the system to send DNS queries with a custom port, not 53. I added DNS=127.0.0.1 9053 to /etc/systemd/resolved.conf and DNS=127.0.0.1:9053 to /etc/systemd/networkd.conf. But now DNS queries are sent via the default DNS with port 53. What can I do?
DNSis aresolved.confonly setting. systemd docs are comprehensive and help navigating what to put where, no need to throw shit at the wall and see what sticks. :)man resolved.conf:
OPTIONS The following options are available in the [Resolve] section: DNS= A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can optionally take a port number separated with ":", a network interface name or index separated with "%", and a Server Name Indication (SNI) separated with "#". When IPv6 address is specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats are "111.222.333.444:9953%ifname#example.com" for IPv4 and "[1111:2222::3333]:9953%ifname#example.com" for IPv6. DNS requests are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from systemd-networkd.service(8) or set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS servers listed in /etc/resolv.conf are used instead, if that file exists and any servers are configured in it. This setting defaults to the empty list. Added in version 213.TL;DR: Create a drop-in for resolved and put the DNS= line there, with colon separating the port. Reload the config of the service to activate.
install -o0 -g0 -dm755 /etc/systemd/resolved.conf.d install -o0 -g0 -m644 <(cat <<EOF [Resolve] DNS=127.0.0.1:9053 EOF ) /etc/systemd/resolved.conf.d/90-dns_port.conf cat /etc/systemd/resolved.conf.d/90-dns_port.conf [Resolve] DNS=127.0.0.1:9053 systemctl reload systemd-resolvedinstall -o0 -g0 -m644 <(cat <<EOF [Resolve] DNS=127.0.0.1:9053 EOF ) /etc/systemd/resolved.conf.d/90-dns_port.conf
The output is an error:
install: cannot stat '/dev/fd/63': No such file or directory.Don’t slap a sudo in front where it doesn’t belong. Run this as root, or the shell redirection will fail. Or just create that file with these contents in any other way you like and feel comfortable with, it’s not a magic incantation you have to use verbatim, after all.
I ran the command with
sudoand got the error. I created the file withsudoeditand added the contents in it andsystemctl reload systemd-resolved. But the DNS requests are sent with port53to the default DNS server yet and:cat /etc/resolv.conf # This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients directly to # all known uplink DNS servers. This file lists all configured search domains. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.1 nameserver 192.168.1.1 search .I ran the command with sudo and got the error.
Yes, that’s why I said don’t do that. It’s a common, non-intuitive interaction with sudo and shell redirections. Don’t stress over it, I shouldn’t have done it all that fancy in the first place.
Regarding your problem: Your setup is likely inconsistent now due to your experiments and previous setup attempts. HOLD THE REINSTALL, learn to fix it, it’s not that complex. First off: you’re not running in the recommended “stub mode” where
/etc/resolv.confis symlinked to/run/systemd/resolve/stub-resolv.conf, and where the configuration you did is actually actively used. Fix that first. Have some docs. This is my stub/etc/resolv.conf, for example, so you know what to look for, roughly:[root@e15g4 gyroplast]# cat /etc/resolv.conf # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # [...] nameserver 127.0.0.53 options edns0 trust-ad search fritz.boxDon’t create that file with these contents manually. Read the docs, follow the instructions, don’t ruin your day.
Assert you have no lingering, conflicting setup in the
/etc/systemd/resolved.confmain config. The default file is effectively empty / commented out, to allow for automatic system updates without conflicts. You could reinstall the package to get the original file back if you’re unsure.Make sure the
systemd-resolved.serviceis enabled and started:systemctl enable --now systemd-resolved.serviceYou might want to installsystemd-resolvconfas well if you commit to a systemd-resolved setup, for maximum compatibility.Make use of
resolvectl statusto verify the status:Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 127.0.0.1:9053 DNS Servers: 127.0.0.1:9053 Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google [...]If that’s still not what is expected, crank up debugging and check the logs of the service to see if for some reason your config file isn’t loaded due to a typo somewhere, or if it’s loaded, any other reason that may override your settings later. It’s practically guaranteed there’s an inconsistency left somewhere, and reading the debug log points you at the actual problem.
It’s worth fixing this in that way. With stub mode, you gain a lot of flexibility in your setup, and it works well in tandem with NetworkManager, DHCP, VPNs, and libvirt/qemu networking. You have to make sure you’re not inadvertently setting up some broken “hybrid” of old-school /etc/resolv.conf manual config and systemd-resolved, this will drive you mad, and it’s a pain to diagnose. Read that wiki page, do not intermingle with crap you pick up on stackoverflow or AI bullshit, and you’ll end up with a DNS config that actually works like magic.
Thank you for spending your time. Yes,
resolvectl status’s output is like yours inGlobalpart, but in the end of the output there is this:Link 3 (wlp3s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 Default Route: yesAs you see,
wlp3s0uses the default ISP DNS. Wireshark’s output confirms this.Yeah, that’s normal, intended, and does not prevent general lookups taking the global DNS first. Do you see an issue with this?
I gave this setup a try real quick, to make sure I’m not overlooking something, with dnsmasq for testing on 127.0.0.1:9053:
[gyroplast@e15g4 ~]$ dnsmasq --listen-address=127.0.0.1 --port=9053 --address=/testme.localnet/127.42.0.69 --no-daemon --no-hosts --no-poll --log-queries dnsmasq: started, version 2.90 cachesize 150 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq: warning: no upstream servers configured dnsmasq: cleared cacheWhen triggering a query on that test record, f. ex. with
ping -c1 testme.localnet, you’ll see it’s directed to the dnsmasq instance and working as intended:dnsmasq: query[A] testme.localnet from 127.0.0.1 dnsmasq: config testme.localnet is 127.42.0.69 dnsmasq: query[AAAA] testme.localnet from 127.0.0.1 dnsmasq: config error is REFUSED (EDE: not ready) dnsmasq: query[AAAA] testme.localnet from 127.0.0.1 dnsmasq: config error is REFUSED (EDE: not ready)The DNS setup with systemd-resolved is pretty confusing, and outright contradicts many, MANY previously correct instructions of how to set your
/etc/resolv.conf. I’m not surprised if it is giving you a headache right now, but all I can say is to diligently work through its configuration, and understand how systemd-resolved is supposed to work. From experience, make sure your tests are sound and representative, or you’ll continue looking for errors in your setup despite everything actually working just fine, maybe because you missed a reload or had a typo or misunderstanding in your wireshark filter.In the same vein, make sure your DNS listening on :9053 is really working as intended, otherwise you can bark up the wrong tree all day long. Debug logging is your friend, and more accessible and less error prone than tcpdump/wireshark.
You’ll figure it out from here, I’m sure.
Thanks! I wasted your time. As you said the problem caused a headache to me. I stop trying on it for some days.
