[solved] Use Pi-hole as LAN DNS is not working


#1

Expected Behaviour:

Pi-hole providing DNS service in LAN

Actual Behaviour:

Pi-hole is resolving to public IP

Hi,
after setting up Pi-hole as DNS + Adblocker I want to extend the functionality by LAN DNS to access local webservices, e.g. Dev-landscape for Nextcloud.

Therefore I followed these instructions created file /etc/pihole/lan.list with this content:

root@ct101-pihole:/opt/dnscrypt-proxy# cat /etc/pihole/lan.list
192.168.100.101 ct101-pihole.whl.meilocal.net           ct101-pihole
10.0.0.102      ct102-haproxy.whl.meilocal.net          ct102-haproxy
192.168.100.103
192.168.100.104
192.168.100.105
192.168.100.106
192.168.100.107
10.0.0.108      ct108-cal.whl.meilocal.net              ct108-cal
192.168.100.109 
192.168.100.110
192.168.100.111
192.168.100.112
192.168.100.113
192.168.100.114 ct114-devcloud.whl.meilocal.net         ct114-devcloud          devklaud.mydomain.de

and created another dnsmasq config file with this command:
echo "addn-hosts=/etc/pihole/lan.list" | sudo tee /etc/dnsmasq.d/02-lan.conf
and restarted DNS with
pihole restartdns

However when I check this URL devklaud.mydomain.de I get the public IP and not the expected host IP 192.168.100.114.

root@ct101-pihole:/opt/dnscrypt-proxy# nslookup devklaud.mydomain.de
Server:         46.182.xxx.xxx
Address:        46.182.xxx.xxx#53

Non-authoritative answer:
Name:   devklaud.mydomain.de
Address: 94.79.xxx.xxx

root@ct101-pihole:/opt/dnscrypt-proxy# ping devklaud.mydomain.de
PING devklaud.mydomain.de (94.79.xxx.xxx) 56(84) bytes of data.
64 bytes from mydomain.de (94.79.xxx.xxx): icmp_seq=1 ttl=64 time=0.409 ms
64 bytes from mydomain.de (94.79.xxx.xxx): icmp_seq=2 ttl=64 time=0.311 ms
64 bytes from mydomain.de (94.79.xxx.xxx): icmp_seq=3 ttl=64 time=0.310 ms
^C
--- devklaud.mydomain.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.310/0.343/0.409/0.048 ms
root@ct101-pihole:/opt/dnscrypt-proxy#

Why is DNS for LAN not working correctly?


#2

Is this machine you are running nslookup using pihole as dns?..
nslookup
server=192.168.100.101
devklaud.mydomain.de

what is the answer?


[solved] Testing dnsmasq configuration with dnsmasq embedded in FTL
#3

I applied some modifications to dnsmasq.

  1. Changed the domain name of my local network to: whl.mydomain.lan
  2. Dropped file /etc/dnsmasq.d/02-lan.conf
  3. Created file /etc/dnsmasq.d/03-lan-dns.conf with this content
root@ct101-pihole:~# more /etc/dnsmasq.d/03-lan-dns.conf
expand-hosts
local=/whl.mydomain.lan/
listen-address=127.0.0.1
listen-address=192.168.1.101
bind-interfaces
  1. Modified /etc/hosts by adding these lines:
192.168.100.100     host0
192.168.100.102     host2    wiki.whl.mydomain.lan
192.168.100.103     host3    cloud.whl.mydomain.lan

Now I can ping any server listed in /etc/hosts also by FQDN.
However, nslookup still trying to resolve the hostname by Upstream DNS Servers.

root@ct101-pihole:~# nslookup wiki.whl.mydomain.lan
Server:         46.182.19.48
Address:        46.182.19.48#53

** server can't find wiki.whl.mydomain.lan: NXDOMAIN


#4

change server to your pihole


#5

Actually the dnsmasq configuration uses this parameter: server=127.0.0.1#53000
This is defined in /etc/dnsmasq.d/01-pihole.conf (see output below).

root@ct101-pihole:~# ack server= /etc/
/etc/dnsmasq.conf
66:#server=/localnet/192.168.0.1
70:#server=/3.168.192.in-addr.arpa/10.1.2.3
90:# server=10.1.2.3@eth1
95:# server=10.1.2.3@192.168.1.1#55

/etc/dnsmasq.d/01-pihole.conf
45:server=127.0.0.1#53000

And service dnscrypt-proxy is listening on port 53000.
There’s nothing wrong with this setup as DNS resolution and filter for WAN works like charm.

root@ct101-pihole:~# netstat -tulpen | grep 53
tcp        0      0 127.0.0.1:53000         0.0.0.0:*               LISTEN      0          258704467  72/dnscrypt-proxy
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      999        258702852  245/pihole-FTL
tcp        0      0 192.168.1.101:53        0.0.0.0:*               LISTEN      999        258702850  245/pihole-FTL
tcp6       0      0 ::1:53000               :::*                    LISTEN      0          258704469  72/dnscrypt-proxy
tcp6       0      0 fe80::8798:a602:a18f:53 :::*                    LISTEN      999        258704664  245/pihole-FTL
tcp6       0      0 ::1:53                  :::*                    LISTEN      999        258702854  245/pihole-FTL
udp    32256      0 127.0.0.1:53000         0.0.0.0:*                           0          258704466  72/dnscrypt-proxy
udp        0      0 127.0.0.1:53            0.0.0.0:*                           999        258702851  245/pihole-FTL
udp    17664      0 192.168.1.101:53        0.0.0.0:*                           999        258702849  245/pihole-FTL
udp6       0      0 ::1:53000               :::*                                0          258704468  72/dnscrypt-proxy
udp6       0      0 fe80::8798:a602:a18f:53 :::*                                999        258704663  245/pihole-FTL
udp6       0      0 ::1:53                  :::*                                999        258702853  245/pihole-FTL

#6

Hi, there is nothing wrong with your setup.

your nslookup query is done on the upstream dns.

comaand prompt
nslookup
set server 192.168.100.101
devklaud.mydomain.de

what is the answer?


#7

Here’s the output:

root@ct101-pihole:~# nslookup
> set server 192.168.1.101
*** Invalid option: server
> devklaud.whl.mydomain.lan
Server:         46.182.19.48
Address:        46.182.19.48#53

** server can't find devklaud.whl.mydomain.lan: NXDOMAIN
> server=192.168.1.101
Server:         46.182.19.48
Address:        46.182.19.48#53

** server can't find server=192.168.1.101: NXDOMAIN
> set server=192.168.1.101
*** Invalid option: server=192.168.1.101
>

What do you want to achieve with this?

I agree dnsmasq is using the upstream DNS server, but I don’t see a plan how to analyse the root cause for this.


#8

your nslookup query is done directly on a external dns.not on your pihole.

Try this.

nslookup devklaud.mydomain.de 192.168.100.101


#9

Looks good.

root@ct101-pihole:~# nslookup devklaud.whl.mydomain.lan 192.168.1.101
Server:         192.168.1.101
Address:        192.168.1.101#53

Name:   devklaud.whl.mydomain.lan
Address: 192.168.100.114

#10

sorted

set pihole as dns to your clients and test.
mark as sorted when satisfied


#11

Pi-hole is running as DHCP, too.
This means Pi-hole server is listening on port 53 in my LAN.
Your proposal cannot be the solution for this issue.

I’ve continued investigation and found some information how dnsmasq is typically configured to resolve requests for LAN.
In my understanding this is controlled by this parameter:
local=/example.com/
Our local domain, queries in these domains are answered from /etc/hosts or the static-hosts files.

I have added this parameter (and some others that are important in my opinion) in file /etc/dnsmasq.d/03-lan-dns.conf :

root@ct101-pihole:~# more /etc/dnsmasq.d/03-lan-dns.conf
expand-hosts
#domain=whl.mydomain.lan
local=/whl.mydomain.lan/
listen-address=127.0.0.1
listen-address=<pi-hole IP in LAN>
bind-interfaces

Based on this I conclude that this parameter is not working with embedded dnsmasq in FTL.


#12

again: there is nothing wrong with your setup.
On a client make sure the one and only dns server set is your pihole and run an nslookup to your devklaud.whl.mydomain.lan

Your pihole is not set on the network interface to listen to itself, but it has the external dns servers. So if you run nslookup on your pi, wihout changing the server that quesry will always answer the external Ip, not the ip defined in the conf files.
A ping reads the host file first, so you get the answer you want. The nslookup is default quering the dns server set on your network cards. So you get external ip.

So: test on a client other than pihole itself.
First make sure the dns server on the client is set to pihole.
Flush the cash, remove and re-insert the network cable and test the nslookup on the clinet.


#13

Test from any other client than Pi-hole server is successful.
I will set this ticket to “solved”.


#14

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.