Please follow the below template, it will help us to help you!
Expected Behavior:
Display data about the local network.
Actual Behavior:
Displays data only about the very immediate network.
Essentially local collision domain.
Not all domestic networks are flat L2 networks.
Is this intended behavior, is there provision to configure a larger range of networks?
In my case the pihole server is on a LAN segment that has only other servers on it, I'd be much more interested in the segments that support clients.
Yes if its arp based then that explains the strange results I've seen. The devices I can see are all connected via a gigabit switch, devices show up very very slowley, and so far not all the devices on that segment show up. The switch will only forward broadcast arps to all ports, directed arps will be filtered out,
It was designed to be passive as we (I) didn't feel that actively mapping a network was the proper behavior for a DNS server. If you use Pi-hole as your DHCP then you should have that information for any client that is a DHCP client. Or you may be able to put an arp relay on the discontinuous segments to populate the Pi-hole's cache.
The DHCP servers are MikroTik routers, don't want the pihole conflicting with them.
I have the information fine from the MikroTiks, just wondered at the odd selection of addresses showing up on the pihole.
Posting arp requests across the collision domains does not appeal either, I'll live with it as it is thanks.
backman@namepi:~ $ arp -a
? (172.25.25.147) at b8:27:eb:68:ba:eb [ether] on eth0
? (172.25.25.150) at b8:27:eb:41:a9:19 [ether] on eth0
? (172.25.25.1) at 4c:5e:0c:54:93:d3 [ether] on eth0
? (172.25.25.148) at b8:27:eb:f9:db:38 [ether] on eth0
backman@namepi:
backman@namepi:~ $ nmap -sP 172.25.25.0/24
Starting Nmap 7.40 ( https://nmap.org ) at 2020-01-05 18:43 GMT
Nmap scan report for 172.25.25.1
Host is up (0.0012s latency).
Nmap scan report for namepi (172.25.25.146)
Host is up (0.00076s latency).
Nmap scan report for 172.25.25.147
Host is up (0.0011s latency).
Nmap scan report for 172.25.25.148
Host is up (0.00098s latency).
Nmap scan report for 172.25.25.149
Host is up (0.0027s latency).
Nmap scan report for 172.25.25.150
Host is up (0.0025s latency).
Nmap done: 256 IP addresses (6 hosts up) scanned in 2.58 seconds
backman@namepi:~ $ arp -a | grep ether
? (172.25.25.149) at b8:27:eb:3e:6a:ab [ether] on eth0
? (172.25.25.150) at b8:27:eb:41:a9:19 [ether] on eth0
? (172.25.25.1) at 4c:5e:0c:54:93:d3 [ether] on eth0
? (172.25.25.147) at b8:27:eb:68:ba:eb [ether] on eth0
? (172.25.25.148) at b8:27:eb:f9:db:38 [ether] on eth0
backman@namepi:~ $
But arp is a very chancy locator to use, with even the most minimal "hub" devices providing switch function these days.
I was just idly thinking maybe you could locate the clients when they make their enquiries.
Presumably not using the network menu, since I presume it provides information of some use to some people.
Maybe have a set of IP addresses ranges "of interest" and mark off clients on them as they request names. It will never find devices that are not using the pihole directly, but could provide a strong hint that somethings amiss by what does not turn up there.
And queries from outside the ranges of interest could trigger alarm bells..
It works fine in switched environments. It works fine for the intended use which is to show if there are clients that are not using the Pi-hole DNS services. It is not meant for security or alarms or showing if unauthorized clients are using DNS.
I see that. I like the idea a lot, its pointed out at least one issue among those few servers it sees. I just would like it to work in a slightly wider field.
