Local dns records not being read?

General
1

I just created a new pi-hole on a RPI4. it's versions are:

The ad blocker part is working fine. I had to put the DNS in the router DHCP server section since the pi-hole is on a static address in the same subnet but out of the range of the pool of IPs.

My problem is getting DNS to work, sort of. I must be missing a step. I added the dns records and it seemed to take the adds. But it didn't work. I tried rebooting the pi-hole. Still nothing. I then added the same ips and hostnames to the pi-hole's /etc/hosts. After rebooting the hostnames could now be reaching by name in the browser.

So while getting my facts straight for this post, I went back to the /etc/hosts and the records were not there. They were still in the /etc/pihole/custom.list and on the web admin page.

Not sure what made that start working. I added a new dns record using the admin page and that hostname is not working but the other 2 are.

what is the proper sequence of things to restart or reboot to make this work? do I need to reboot the router??

2

These are two different files and only one of them (custom.list) is written directly from Pi-hole (via the web admin GUI local DNS records).

Have you checked the permissions on these files? My working install (V5) has these permissions:

nanopi-neo:~:# ls -lha /etc/hosts
-rw-r--r-- 1 root root 2.2K Feb 17 17:32 /etc/hosts
nanopi-neo:~:# ls -lha /etc/pihole/custom.list
-rw-r--r-- 1 root root 63 Jan  2  2024 /etc/pihole/custom.list

The various hosts files on the Pi are accessed in the following order by Pi-hole:

  1. Configured in a config file in /etc/dnsmasq.d/
  2. Read from /etc/hosts
  3. Read from the list containing the device's host name and pi.hole (stored in /etc/pihole/local.list)
  4. Read from the "custom DNS" list (stored in /etc/pihole/custom.list)

Only the first record will trigger an address-to-name association.

There is no specific sequence required to make this work. The files have to be intact and readable, then FTL will do the rest.

1 Like
3

Thanks for the information. I'm guessing there is some timing issue with my router picking up the new dns records. I didn't reboot the router. However, I did add the new dns record to the /etc/hosts file and rebooted. It was immediately available by hostname anywhere on the network.

Can't say I understand why, but I can get it working.

4

Run from a client in your network, what's the result of:

nslookup pi.hole

nslookup <hostname>

Substitute <hostname> with a hostname you've created via Pi-hole's Local DNS records (e.g. laptop).

5

So I had 2 dns records in my list on the pi-hole admin page and they were working. I added a third and while ssh'd into the pi-hole I saw it had update the /etc/pihole/custom.list. I then on the pi-hole did the command pihole restartdns

But the new hostname is not found on the network

jim@Office-PC:~$ nslookup rpi4-dns
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find rpi4-dns: SERVFAIL

jim@Office-PC:~$ nslookup iotstack
Server:         127.0.0.53
Address:        127.0.0.53#53

Name:   iotstack
Address: 192.168.68.91

jim@Office-PC:~$ nslookup kubuntu
Server:         127.0.0.53
Address:        127.0.0.53#53

Name:   kubuntu
Address: 192.168.68.67

I also tried rebooting the pi-hole (called rpi4-dns), same result on nslookup

6

I just rebooting my router and still get the same results for the nslookup

Could it be that the rpi4-dns name is a problem? That is the hostname of my rpi4 which host the pi-hole server?

7

I just added a new dns record for a PC on my network that is at a reserved address. I use the admin page and reserved it, it showed up in the custom.list file and I restarted the pihole dns.

Still no look seeing it on the net by hostname

8

So far, you have just provided nslookup results for a hostname.

Please also run the requested:

Also, mind that those commands should he run from a client, i.e. not from the machine hosting Pi-hole.

9 
jim@Office-PC:~$ nslookup pi.hole
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find pi.hole: NXDOMAIN
10

I just rebooted the client PC that I was using the run the nslookup pi.hole

As a result I now see this:

jim@Office-PC:~$ nslookup pi.hole
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   pi.hole
Address: 192.168.68.30
Name:   pi.hole
Address: fe80::50af:edb1:5c76:4aeb
11

The machine you ran that nslookup from is using a localhost stub resolver, and that stub resolver does not (or not always) use Pi-hole for DNS, else it would've returned your Pi-hole's IP.

Since it doesn't use Pi-hole, it won't be able to resolve names as defined in Pi-hole.

Either configure your stub resolver to use Pi-hole as its only upstream, or disable it.

Edit: Note that Local DNS records take effect immediately. It is not required to restart Pi-hole or reboot the entire machine.

12

Thanks for the help. The client machine that is running the nslookup is running Linux Mint 21.3. I don't know what a stub resolver is so I probably didn't setup one up. I know that all machines on my network run avahi-daemon systemd service and that allows me to get to any machine using hostname.local. That works for ping and ssh but not http:hostname.local:port in a browser.

I just found out that to get around my two original dns records not working in pi.hole I had added them to the /etc/hosts file on the client PC. That was why it was working originally. I've now removed those.

Now none of them work

im@Office-PC:~$ nslookup pi.hole
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   pi.hole
Address: 192.168.68.30
Name:   pi.hole
Address: fe80::50af:edb1:5c76:4aeb

jim@Office-PC:~$ nslookup kubuntu
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find kubuntu: SERVFAIL
13

FYI, I guessed you may mean stub resolver is systemd-resolved and I tested disabling that. It could not even find google.com then. So I reenabled it and I'm back to where I was.

14

NEW info:

I changed my client PC over to a brand new N100 nuc that I just setup with Endeavour OS which is based on Archlinux. On that machine it looks like things are working correctly:

[jim@jim-nucboxg3 ~]$ nslookup pi.hole
Server:         192.168.68.30
Address:        192.168.68.30#53

Name:   pi.hole
Address: 192.168.68.30
Name:   pi.hole
Address: fe80::50af:edb1:5c76:4aeb

[jim@jim-nucboxg3 ~]$ nslookup iotstack
Server:         192.168.68.30
Address:        192.168.68.30#53

Name:   iotstack
Address: 192.168.68.91

[jim@jim-nucboxg3 ~]$ nslookup rpi4-dns
Server:         192.168.68.30
Address:        192.168.68.30#53

Name:   rpi4-dns
Address: 192.168.68.30
Name:   rpi4-dns
Address: fe80::50af:edb1:5c76:4aeb

So it's a client problem or a Linux Mint problem. If I can't find the mystery stub resolver I may just have to reinstall linux on this client and then restore the data from the NAS.

Something fun to do today!

15

You can run cat /etc/resolv.conf and see what you client shows as its nameserver. It will likely shows the 127.0.0.53. So either your not being served pihole as the dns resolver through DHCP or your network interface is set to use that 127.0.0.53 as its resolver.

16

Another thought. The bad client is configured with a bridge so my KVM VMs that use that bridge can appear on the same local network as all my real systems. Could that have introduced a problem?

I added the bridge by following https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/

Basically:

sudo nmcli con add ifname br0 type bridge con-name br0
sudo nmcli con add type bridge-slave ifname eno1 master br0
sudo nmcli con modify br0 bridge.stp no
sudo nmcli con down "Wired connection 1"
sudo nmcli con up br0
17

I've done a lot of moving from PC to PC and running this nslookup test.

The bridge is not the problem.
Running on a VM is not the problem.
Only problems show up on Linux Mint 21 or 22 (ubuntu based) either native or in a VM

So I'm not sure how to identify what's in LM's networking settings that could be causing this?

18

This IP being used for DNS is a loopback address, not the IP of the Pi-hole, it appears.

Run this command and post the output:

nslookup rpi4-dns {IP of your Pi-hole here without the brackets}

19

If I'm on a client running Linux Mint I get the following:

jim@jim-NucBox-G3:~$ nslookup rpi4-dns
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find rpi4-dns: SERVFAIL

If I'm on a debian 12 client I get:

pi@iotstack:~ $ nslookup rpi4-dns
Server:		192.168.68.30
Address:	192.168.68.30#53

Name:	rpi4-dns
Address: 192.168.68.30
Name:	rpi4-dns
Address: fe80::50af:edb1:5c76:4aeb
20

In your Linux Mint machine, what is the output of this command?

nslookup rpi4-dns 192.168.68.30