I’m trying to configure my Fedora 34 clients on my LAN to use local DNS for resolving LAN hostnames using Pi-Hole. I have configured my Fedora clients using the Network GUI (Network Manager?) in Gnome with static IP addresses and looking at my Pi-Hole for DNS. Once I applied that I have noticed that /etc/resolv.conf does not change and has the IP address of 127.0.0.53. Of course, this isn’t going to work if I am trying to resolve local hostnames I have added to my Pi-Hole.
Can someone tell me why /etc/resolv.conf doesn’t change when you configure the networking in the Network GUI? If I edit /etc/resolv.conf with my Pi-Hole IP address, will it stick?
Thanks.
As @vgaetera already posted in replies to your question, the recently changed “Split DNS” results in /etc/resolv.conf being set to 127.0.0.53; the article he linked to tells you more about how this works. There are a few tools you can use to check how your static addresses are working out for you, including doing an nslookup on your clients, and resolvectl. If the article leaves you more confused than satisfied, please add more information to this thread and we’ll see if we can help you out.
Personally, I have a number of workstations, some of which are assigned a fixed IP address and others dynamic; I use dnsmasq for both the DHCP address assignment and local DNS scope. Sounds somewhat similar to what you are doing.
Thank you both for your reply.
I read the article and I am not sure that information applies to what I am trying to do. Definitely, it’s helpful if I was using my machine for a VPN connection and need to resolve two different LAN networks.
I guess mostly what I would like to know is if there is any issue with replacing my Pi-Hole IP address to the resolv.conf. instead of the 127.0.0.53. I’m just trying to get local LAN hostname resolution working, even PTR records, for ssh to host on my LAN. So far, I have unbound installed on my Pi-Hole and my Pi-Hole is doing all the DNS while my router is doing the DHCP. I have LAN hostname resolution working, as long as I use the FQDN (e.g. myworkstation.example.lan, myserver.example.lan). My only issue I am working with now is trying to get LAN hostname (e.g. myworkstation, myserver) resolution working so I don’t have to use the FQDN.
You can either
Disable systemd-resolved.service
(For the following commands you need to use sudo or your root user.)
systemctl disable systemd-resolved.service
systemctl stop systemd-resolved.service
and set your DNS name servers in /etc/resolve.conf
or probably more recommended
Configure systemd-resolved.service to use your pi-hole as dns upstream server.
mkdir /etc/systemd/resolved.conf.d/
nano /etc/systemd/resolved.conf.d/resolved.conf
enter your IPs ofcause:
[Resolve]
DNS=192.168.0.1
FallbackDNS=192.168.2.1
systemctl restart systemd-resolved.service
verify it with
resolvectl
If this method does not work, you may have to disable dnssec.
Regarding your fqdn, you need the “search” keyword
Or “Domains=” with systemd
https://www.freedesktop.org/software/systemd/man/resolved.conf.html#Domains=
4 Likes
Thanks for the information. I will try out systemd-resolvd.
That worked. I created the file, placed my Pi-Hole IP address and used the “Domains=” in the file.
Thank you so much.
1 Like
Glad it worked . 
Even though I have marked your post as the solution, I have one other question about systemd-resolved service that I hope you can answer.
Now that I have created /etc/systemd/resolved.conf.d/resolved.conf with the DNS looking at my Pi-Hole IP address, is there a reason that when I run a dig command that it seems like it is still using /etc/resolv.conf since it references that it is using 127.0.0.53 as the SERVER, especially for local records?
[ed@edfed: ~]$ dig enas.offworld.lan
; <<>> DiG 9.16.21-RH <<>> enas.offworld.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41278
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;enas.offworld.lan. IN A
;; ANSWER SECTION:
enas.offworld.lan. 0 IN A 192.168.15.8
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Oct 13 04:28:32 EDT 2021
;; MSG SIZE rcvd: 62
I would think the IP address listed in the SERVER section would be the IP address of my Pi-Hole.
Here is the service status:
[ed@edfed: ~]$ sudo systemctl -l status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-10-13 04:40:55 EDT; 3min 41s ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 192793 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 19077)
Memory: 9.4M
CPU: 138ms
CGroup: /system.slice/systemd-resolved.service
└─192793 /usr/lib/systemd/systemd-resolved
Oct 13 04:40:55 edfed systemd[1]: Starting Network Name Resolution...
Oct 13 04:40:55 edfed systemd-resolved[192793]: Positive Trust Anchors:
Oct 13 04:40:55 edfed systemd-resolved[192793]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Oct 13 04:40:55 edfed systemd-resolved[192793]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa >
Oct 13 04:40:55 edfed systemd-resolved[192793]: Using system hostname 'edfed'.
Oct 13 04:40:55 edfed systemd[1]: Started Network Name Resolution.
Systemd-resolved acts as a local stub resolver.
This stub resolver is listening on the loopback interface with ip 127.0.0.53 and port 53 and forwards all incoming queries to your Pi-Hole.
The /etc/resolv.conf includes the name server entry 127.0.0.53, so the system knows to always ask the local stub resolver for dns queries.
Edit
Hopeful fixed my weird explanation to be understandable