Looking for some guidance here as I've created a new Raspberry Pi OS install image and installed Pihole on it, teleported my configuration over with great success.
I have the RPi-OS set to use non-Pihole DNS addresses while the Pihole is using Unbound. Again, the Pihole side is working great. But when I go to a terminal on the RPi, I can't resolve hostnames on the LAN. I can ping/resolved IPs on the LAN with no issue.
I had this working on my previous RPi-OS install (was Bullseye I think, now Trixie). I can't remember how I made it work so that the RPi could resolve local hosts while not depending on Pihole. I was not using a HOSTS file to my recollection.
This OS uses Network Manager:
# Generated by NetworkManager
search home.arpa
nameserver 9.9.9.9
nameserver 1.1.1.1
If I ping, for example, hoth.home.arpa or hoth, I get "Name or service not known."
Since my configuration is not using Pihole with these above examples, I realize it's not a Pihole setup issue (unless I'm overlooking something), but I'm presenting this to the community at large for some guidance.
I have included the Pihole debug in case that lights some fires, but I really feel like I just forgot how I made it work on my prior OS image and didn't set this new one up properly.
Shocking, I used Google AI as follows: "trixie configure nmtui to use gateway for local hostnames and public dns for everything else". This actually came up with a workable answer for me. Since I'm new to Network Manager, this was helpful.
I edited /etc/NetworkManager/system-connections/Wired connection 1.nmconnection to include the setup under the [ipv4]
section to list my VLAN gateway along with the public DNS addresses. Then I added a dns-priority=-10
line (EDIT: I see now this line is AI slop and not needed) and a dns-search=home.arpa;~.;
line which reportedly (?) routes home.arpa locally while forcing everything else to use the other listed DNS servers.
This appears to have gotten the desired result, although technically it's using my gateway (which uses a non-Pihole DNS) instead of directly querying the public DNS. I can live with how it's running for now, but if anyone knows of an improvement, I'd welcome it.
Do you have some process running on the Pi that depends on those hostnames getting resolved?
Or why do you need to resolve those hostnames on the Pi itself?
If you do have a process dependency, there is nothing wrong with configuring loopback 127.0.0.1.
Lots of distros do where a stub resolver for caching etc is listening.
But do mind that when things go wrong with FTL, all processes on the host lose DNS resolution which complicates diagnosing!
The debugger (pihole -d) and reconfigure/repair (pihole -r) both depend on whats configured in resolv.conf.
Yeah, I should have specified my goals better. The only need for hostname resolution is because I run some remote access software on the RPi that allows me to securely access other machines on my network. So host name resolution is needed for those services to find the target machine. Those machines typically have dynamic IP addresses.
Any reason to not configure 127.0.0.1 for DNS instead of 9.9.9.9 & 1.1.1.1 ?
Probably not; does that address the potential issue of the Raspberry Pi using its own Pihole as DNS?
I apologize for asking what are probably easily-answered questions. It's just this change to Network Manager/nmcli has been a little challenging when I've been using the older ways of network configuration, and I want to be fairly sure I'm not missing something important.
Indeed, what you show is pretty much how I have it configured right now. The one item that I'm hazy on is the external lookups. Internal and external DNS lookups via nslookup show the server as 127.0.0.1. I was thinking in my prior setup, external lookups were showing the server as 9.9.9.9; maybe that recollection is faulty.
Do mind that if you flashed the latest Pi-OS Trixie, you have to configure static IP details via Netplan instead of via network-manager etc!
$ apt show netplan.io
[..]
Description: YAML network configuration abstraction for various backends
netplan reads YAML network configuration files which are written
by administrators, installers, cloud image instantiations, or other OS
deployments. During early boot it then generates backend specific
configuration files in /run to hand off control of devices to a particular
networking daemon.
.
Currently supported backends are networkd and NetworkManager.
EDIT: forgot I had attempted to enable dnsmasq via the NetworkManager.conf file. Removed the dns=dnsmasq line and now resolv.conf reads:
cat /etc/resolv.conf
# Generated by NetworkManager
search home.arpa
nameserver 192.168.3.200
This results in pings to localhosts responding "Name or service not known." So I changed it back to match what was in my first set of results, but I still can't resolve local hosts from the Raspberry Pi. Perhaps I need to let this sit a while before I really muck things up.
EDIT 2: I was pinging an offline host. Never mind.
Yeah your note above sorta fits what I'm seeing. But on another note regarding the difference in DNS IP addresses, that is now matching once I change NetworkManager.conf to not use dnsmasq. Both show 192.168.3.200 now.
Using nmcli to set the DNS server to 127.0.0.1 as you suggested, everything is resolving locally and Internet-based, and dig says the answering server is 127.0.0.1.
From a Pihole perspective, is this a solid configuration?
Oh no, thats not what I suggested.
You have to configure 127.0.0.1 for DNS via Netplan instead of via NetworkManager!
Probably your changes wont survive a reboot.
EDIT: Check out "More about Netplan":
But below from the link is a bit confusing:
You can still use nmcli as usual to inspect or manage connections.
I guess you can also alter via the NetworkManager toolstack but am not sure!
EDIT2: Man thats confusing having three abstract layers + hooks to configure networking
I think I've rebooted and my past changes held, but it's been a few days so I can't be sure. In any case, I really appreciate all the pointers. Good reading.
EDIT2: Man thats confusing having three abstract layers + hooks to configure networking
Right, imagine what it's like for relative novices like myself!
Here's the output (not 100% sure of a direct answer as I leave the interpretation to you).
pi@raspberrypi:~ $ sudo netplan status
Call failed: The name org.freedesktop.resolve1 was not provided by any .service files
Online state: offline
DNS Addresses: 127.0.0.1
DNS Search: home.arpa
● 1: lo ethernet UNKNOWN/UP (unmanaged)
MAC Address: 00:00:00:00:00:00
Addresses: 127.0.0.1/8
::1/128
● 2: eth0 ethernet UP (unmanaged)
MAC Address: [REDACTED] (Microchip Technology, Inc. (formerly
SMSC))
Addresses: 192.168.3.200/24
Routes: default via 192.168.3.1 metric 100 (static)
192.168.3.0/24 from 192.168.3.200 metric 100 (link)
1 inactive interfaces hidden. Use "--all" to show all.
Thanks!
It appears the two talk to each other via D-Bus:
$ man dbus-daemon
[..]
DESCRIPTION
dbus-daemon is the D-Bus message bus daemon. See
http://www.freedesktop.org/software/dbus/ for more information
about the big picture. D-Bus is first a library that provides
one-to-one communication between any two applications; dbus-daemon
is an application that uses this library to implement a message bus
daemon. Multiple programs connect to the message bus daemon and can
exchange messages with one another.
$ systemctl is-active dbus.service
active
On my Bookworm without Netplan:
$ busctl --full --no-pager list
NAME PID PROCESS USER CONNECTION UNIT SESSION DESCRIPTION
[..]
:1.4 386 NetworkManager root :1.4 NetworkManager.service - -
[..]
org.freedesktop.NetworkManager 386 NetworkManager root :1.4 NetworkManager.service - -
And I, in trying to customize my configs above, ended up putting myself in a black hole. I changed /etc/NetworkManager/NetworkManager.conf and added dns=dnsmasq -- this was to supposedly give me the ability to use "split-horizon" DNS (have different DNS servers based on which domain was being queried). That didn't have the expected result, but I left the conf edit in place.
This morning at around 9am, Pihole reported the DNS Server was not active, so I unravelled things and figured out my mistake (dnsmasq was taking over port 53, for those playing at home). All is well now, but it reminded me to sometimes leave well enough alone.
All queries for the fritz.box domain are forwarded to IP 192.168.0.1.
And also all reverse lookups for 192.168.0.0/24 addresses.
You can configure multiple of those revServers rules for different domains with different destinations.
Another example, I have below on my second Pi-hole node pointing to the first node 10.0.0.2 who is doing DHCP services:
Yes, that's my understanding and matches my Conditional Forwarding configuration already. The case I'm trying to account for is resolution of local hostnames from the R-Pi itself, where the R-Pi has a non-Pihole DNS server to allow for lookups from the R-Pi if Pihole is not available for whatever reason.
Only repeating the following because I've been going around in circles with my explanation, but this is in trying to replicate behavior from what I recall on my previous Bullseye configuration where I had 9.9.9.9 set as DNS for my R-Pi (using dhcpd.conf) but somehow had it so local host.arpa hostname lookups were resolving.
In any event, this are working now with the Trixie setup using 127.0.0.1 as my DNS but it doesn't seem like I've got things where they were before. And that's okay for now, if there's no quick ideas to the contrary.
