Look for DNS Rebind Protection. This is a feature that is designed for security and preventing a rogue DNS server on the local network from doing bad things. In our case though we want it to be able to answer queries and return local addresses.
1 Like
When you access pi.hole/admin in the browser, the browser looks up pi.hole against the DNS server(s) configured in ipconfig /all --> 192.168.0.1.
Same way as how nslookup does.
The router doesnt know the pi.hole domain so it forwards the query to Pi-hole as the logs show.
Pi-hole replies with the correct answer:
"/etc/pihole/local.list pi.hole is 192.168.0.24".
But your router doesnt:
"No internal type for both IPv4 and IPv6 Addresses"
But from the windows PC, it does reply:
1 Like
Its only pi.hole thats failing, other queries do get through.
Could this also be Rebind Protection ?
I have nothing of the sort, unfortunately. This is my Advanced Options config page:
It's possible. There may be some kind of trigger for .hole TLD. Something that tells the router to not forward or answer unreachable domains.
2 Likes
I have just gotten a reply from my ISP:
Thank you for your e-mail. There has been no change to the routers policies.
It's correct, that the DNS on your PC will be 192.168.0.1, unless you change the DNS settings directly on the PC's NIC.
Your PC's DNS will be the router, and the routers DNS will be either default or whatever you choose to change it to.
Come to think of it, when I do set custom DNS settings on my router as 192.168.0.24 (the Orange Pi w/ the Pi-Hole), I do get ads blocked. So despite my ipconfig /all stating that my PC will use as a DNS my router at 192.168.0.1, the router still forwards the request to the Pi-Hole and gets its response from there.
So the question remains why I can't access pi.hole/admin and why I am cannot seem to get proper query logging as I used to just a few weeks ago. I used to be able to tell each and every device's traffic and get the correct separate counters.
I was leaning toward the fault being in a new update of the router, but given that did not happen, it's more likely a Pi-Hole or an OS issue. Just to put it out there, I have tried uninstalling pihole by running
pihole uninstall
and following it with
sudo rm -rf /etc/.pihole /etc/pihole /opt/pihole /usr/bin/pihole-FTL /usr/local/bin/pihole /var/www/html/pihole
as mentioned by How to fully uninstall pihole - #2 by RamSet
The only thing is that I DID NOT delete the associated packages it asks me to review one by one. I avoided deleting them because I am uncertain what each and every one of them is used for and I do not wish to mess up my headless server. However, given the circumstances, when I get home today, I will remove each and every one of them during the pihole uninstall and then also run the second command. Other than flashing a brand new OS on the server, I don't think I can get a cleaner install.
Its your router thats pushing the DNS server IP address 192.168.0.1 via DHCP to the clients and not Pi-hole!
If the clients dont query Pi-hole directly, you wont see individual stats.
And as we already figured out, the DNS route:
Client --> Router --> Pi-hole --> upstream DNS server(s)
doenst work for the pi.hole domain.
Probably bc of some router safety feature
EDIT: Mail your ISP to figure out how to disable DHCP on the router and let Pi-hole do this part.
EDIT2: reason this, if DNS fails (Pi-hole), everything on your LAN becomes useless anyway as most work with names instead of IP's.
So why not let here do DHCP as well.
EDIT3: When do so, you even have more control over your network then you ever can with the router DHCP.
I shall attempt to do so!
What's weird about this is that I never touched my router and it stopped working. I only ever updated the server and the Pi-Hole. <- This also being the reason why I opened this topic, instead of somewhere else, more relevant to my router.
I'm halfway through a complete uninstall of the Pi-Hole, as I said in my last post. By the way, @deHakkelaar, if you're here, should I purge any of these packages while I'm at it?
apt-utils dialog debconf dhcpcd5 git iproute2 whiptail cron curl dnsutils iputils-ping lsof netcat psmisc sudo unzip wget idn2 sqlite3 libcap2-bin dns-root-data resolvconf libcap2 lighttpd php7.0-common php7.0-cgi php7.0-sqlite3
If this cleanup doesn't yield acceptable results, I am resetting the router.
No dont purge any 
apt-utils and iproute2 are vital for the functioning of your system.
Purge iproute2 and you break networking.
Purge apt-utils and you wont be able to install/uninstall anny.
Your realy looking at the wrong end.
But if want to know what packages Pi-hole installed, I believe the install log shows:
less /etc/pihole/install.log
I haven't run the installer for a while so things might have changed 
1 Like
Above 4 are safe to purge if really need to purge anything 
sudo apt purge <PACKAGE1> <PACKAGE2> ...
1 Like
If want to know more bout a package:
apt show <PACKAGE>
If want to know content of an installed package:
dpkg -L <PACKAGE>
If want to know reverse dependencies of a package:
apt rdepends <PACKAGE>
1 Like
Cleanup, as expected, didn't help.
Going to reset the router when I have the chance and report back. It annoys me I haven't touched the router, yet it stopped functioning.
Did we ever came to a plausible solution for the detected here:
[LOGS]
Not sure.
Do you know why you have a dummy interface ?
Where and how is this one defined, in dhcpcd.conf or in /etc/network/interfaces ?
Some bridging going on ?
sudo brctl show
Its also a bit weird the eth0 interface reported as not being connected at first (no carrier):
The dummy interface on the Orange Pi Zero H2+ used to be the wireless antenna. It got disabled by the developers of the OS at one point due to it infamous performance issues.
Within /etc/dhcpcd.conf I have:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
interface eth0
static ip_address=192.168.0.24/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
Within /etc/network/interfaces I have:
# armbian-config created
source /etc/network/interfaces.d/*
# Local loopback
auto lo
iface lo inet loopback
# Interface eth0
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.24
netmask 24
gateway 192.168.0.1
dns-nameservers 8.8.8.8
The sudo brctl show command has nothing listed. I have never established any bridges.
What's weird is that if I run ifconfig -a the wlan0 interface is there and working. I have gone and disabled them via ifconfig wlan0 down and ifconfig dummy0 down, but they seem to reactivate upon reboot.
When have dhcpcd5 installed that comes with Pi-hole:
pi@noads:~ $ apt policy dhcpcd5
dhcpcd5:
Installed: 1:6.11.5-1+rpt7
Candidate: 1:6.11.5-1+rpt7
And active:
pi@noads:~ $ sudo service dhcpcd status
[..]
Active: active (running) since Sun 2019-09-08 22:28:43 CEST; 1 weeks 0 days ago
[..]
IP settings belong in /etc/dhcpcd.conf only!
pi@noads:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
static ip_address=10.0.0.2/24
static routers=10.0.0.1
static domain_name_servers=127.0.0.1
And /etc/network/interfaces should resemble below:
pi@noads:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
When have corrected this and rebooted, check journalctl -u dhcpcd again if the routes get removed again ?
About the dummy0 interface, dhcpcd5 sees this interface and if not told otherwise, like done with the eth0 interface, its going to try acquire IP details via DHCP and IPv6 for the interface.
Try add below directive to the dhcpcd.conf file:
denyinterfaces dummy0
Reboot and see if ignored now with:
journalctl -u dhcpcd
1 Like
By the way, I reflashed the latest Armbian Strecth on the board and reinstalled Pi-Hole. I have since enabled the DHCP service on the Pi-Hole and the dhcpcd5 policy and dhcpcd.conf resemble yours.
However,
this looks a bit different for me. I don't have the comment on top and I only have the iface lo defined:
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback
without the iface eth0. What you see above is the entire contents of my file.
A further fun discovery:
Once I enabled the DHCP on the Pi-Hole, I was able to restore my environment as it was before. The Pi-Hole now has individual queries for each device and is accessible via pi.hole/admin. However, it comes with a catch.
If I disable the DHCP on my router, my entire network dies, despite me having the DHCP enabled on the Pi-Hole. 
I have also added my Pi-Hole's IP to the upstream DNS settings in the Settings tab (the "#53" was added automatically):
Why have you done this? Pi-Hole needs an upstream server to get DNS resolution, it cannot do this itself. By the time an upstream server is needed, Pi-Hole has already seen the request.
1 Like
To be honest, I seem to have misunderstood it's function. I will remove it promptly. 
Thanks for the quick tip!
To clarify, I have now the DHCP and DNS server on my PC set to the correct: 192.168.0.24 as seen here:
by enabling the following DHCP settings on the Pi-Hole:
AND keeping the DHCP on my router ON like:
Any attempt to disable it, as instructed, has rendered my network unconnectable. I tried both with setting the checkmark on the router's DNS Server Config and putting the Pi-Hole's IP and without it. In both cases, after I disable the DHCP, everything crashes, no matter how many times I restart the router, the Orange Pi or the clients.