Can't reach pi.hole/admin, IP works, also failed lookups going to Spectrum DNS

Expected Behaviour:

When I browse to http://pi.hole/admin, I can reach the pihole console.

Actual Behaviour:

On Apple devices (Macbook, iPhones, etc.), this fails and eventually a Spectrum ISP Search Page opens. Web sites on the Internet have all opened without issue or delay.

Debug Token:


More details:
I can access the console page via http://<local_PI_IP_address>/admin without issue. pi.hole/admin also works on my Windows-based devices.

My ISP is Spectrum (formerly Charter Communications). They intercept 404-not found pages with their own "helpful" search page. However, I cannot see in my configuration where my DNS providers are anything but Google.

I have seen similar topics posted in this regard, so in that vein maybe this will provide more info:

dig pi.hole/admin

; <<>> DiG 9.10.6 <<>> pi.hole/admin
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17070
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;pi.hole/admin. IN A

pi.hole/admin. 10 IN A
pi.hole/admin. 10 IN A

;; Query time: 45 msec
;; WHEN: Fri May 25 05:52:54 CDT 2018
;; MSG SIZE rcvd: 63

Thanks in advance.

The situation describe where it is working from some devices but not others strongly suggests that at some point on your network you have an IP other than that of your Pi-hole set as a DNS address. Likely as a "secondary DNS".

I'd be looking first at Cable/DSL modem and then probably wireless router if it's a separate device.

Often DNS settings can be set in several locations on these devices. On some wireless hubs there are different DNS settings for wired and wireless connections (eg old D-links), and on others, different DNS settings in the WAN settings and on the LAN/DHCP pages (eg Asus).

Also if your modem is carrier provided, it's unfortunately possible for this to be a setting that you A) can't change and B) can't even view.

Well that sort of led me down a path.

I have a Synology 2600 router with a Spectrum-provided Cisco DPC3216 cable modem. There is no way to set DNS or anything else on the modem. The router has sections labelled "Internet" and "Local Network".

I had nothing specifed under Internet/Manually configure DNS server. I had my piHole IP address (only) under Local Network ipV4, but DHCP is disabled as I'm letting piHole handle DHCP.

For Local Network ipV6, I have it enabled to pull in the prefix, but it is set to Stateless mode with a specifed DNS pointing to the fe00:: autoconfigured address for my Pi.
--EDIT-- Actually the setting I use is "Stateless DHCPv6 mode" which according to Synology automatically configures ipV6 addresses but pulls DNS from DHCPv6, which I specified as my Pi's address.

As a test, I went to "Internet/Manually configure DNS server" and changed it from nothing to the local IP address of my Pi. This caused subsequent attempts at loading pi.hole/admin to query and, then eventually fail with a DNS_PROBE_FINISHED_NO_INTERNET in Google Chrome web browser.

So it appears if an address cannot be resolved, Synology eventually sends the query to whatever it's getting from my ISP as the default DNS -or- what is specifed in Manual DNS on the router.

The true root of the problem, though, is why can't I resolve http://pi.hole/admin on Apple devices when they have the same (apparent) DNS setup as Windows machines that work?

To narrow it down, you could try setting the DNS manually on one of your apple devices, pointing it at your Pi-hole's address, and see what happens then when you visit http://pi.hole

That has the same result.

I have also disabled all ipV6 on the router and rebooted my computer so that it's no longer being assigned an ipV6 address. Also, I turned off ipV6 support in PiHole DHCP and removed the Google ipV6 servers from DNS.

Often Apple devices use IPv6 over IPv4, so the issue might be that your router is sneaking in the ISP's DNS servers through the IPv6 DHCP setup. Are you able to view the IPv6 information on the Apple devices? What do they return when you run nslookup pi.hole?

At this time, only the IPv4 information:
nslookup pi.hole

Non-authoritative answer:
Name: pi.hole
Name: pi.hole

Note the difference between my server address and the non-authoritative answer. This is consistent with what the dig commands were showing above.

I should also mention that I did try PiHole's "Enable IPv6 support (SLAAC + RA)" trying to see if it would affect this and/or if it would have an affect on PiHole not showing any of my IPv6 host names instead of the IP addresses on the Query Log and Dashboard. So the Apple weirdness with name server as it concerns DIG and NSLOOKUP commands behaved the same in all the scenarios I've outlined so far.

I realize this is really looking like some bizarre quirk of Apple, since Windows machines behave properly, but I'm trying to understand the cause.

Make a new debug token. Is the expected IP address of the Pi-hole?

New debug token is:

And yes, the is the expected static address for PiHole.


New debug token is:

And yes, the is the expected static address for PiHole.

You don't seem to have IPv6 internet access, so that is probably not the issue. However, I could not find the anywhere in your debug log (I was thinking it might have been incorrectly used as the IP address used for blocking). When you make the DNS request, do you see it show up in the Pi-hole's log (/var/log/pihole.log or pihole -t)? If not, your router might be intercepting the request and preventing it from actually reaching the Pi-hole. sure doesn't show up in the log when I make the request as you suggested.

So I guess it's the router. Following that logic, I changed my Synology router config under Internet/Manually Configure DNS Server (I had entered nothing here before) to and when I tried to browse to pi.hole/admin on a Macbook, it gave me a simple Google "page could not be found ERR_NAME_NOT_RESOLVED" message (no ISP error page like I'd had before). If I change the DNS to my PiHole IP, it still can't find it and give the same page I got with Google as the manual DNS.

Obviously I misunderstood the way the router would behave, assuming it would always and only take the DNS specified in "Local Network" instead of ultimately failing over to settings in "Internet." It still doesn't really tell me why pi.hole/admin can't be resolved in the first place on Apple devices, but it clarifies some things.

It surely would be nice if all this stuff worked consistently across hardware, but I suppose you know that much better than I do! :slight_smile: At this point, it's more of an exercise in curiosity than trying to correct a problem.

Usually routers will stick to separating "Internet" DNS from "Local Network" DNS, although they may not actually listen to what you put there. If you're able to, I would try flashing a custom firmware on the router or getting a better one, if you can't find a solution just by changing config settings.

1 Like

Yeah, thought crossed my mind a few times, but I've not found any custom firmware that appears to support this it's only about 2 months old and I'm a bit hesitant to make drastic changes.

All that aside, though, many of my attempts at workaround would be rendered moot if I could get a custom firmware on here.

Anyway, thanks for your insight on this. We can consider the matter closed if you like.

Along the lines of the "exercise in curiosity" that you called it. I've been thinking about your problem being limited to your apple devices, and not any others.

(Full disclosure : I am not at all familiar with apple products). But I did came across bonjour which apple describe as "enables automatic discovery of devices and services on a local network". To me this seems like a thing that could potentially override or disregard your network settings if they were in conflict with what it expects.

If your curiosity does get the better of you, it could be interesting to see if there are any "bonjour" related services offered by your router that your apple devices could be getting other instructions from.

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