pihole.local blocked because is NOT found on any blacklist?

Please follow the below template, it will help us to help you!

It seems pi-hole disrupts mDNS/Bonjour/Avahi queries in Safari and Chrome on macOS.

Pi-hole Version v4.3 Web Interface Version v4.3 FTL Version v4.3.1

Expected Behaviour:

I expected to be able to visit http://pihole.local in the browser.

Actual Behaviour:

When I try to visit it using Safari or Chrome on macOS, I get the “Not found on any Blacklist” reason for why a website is blocked. This makes absolutely NO sense to me. Why would it block something because it’s NOT found on a blacklist? Moreover, as you can see in the screenshot, it’s expressly whitelisted (I did this the first time I got the message), but it still doesn’t go through.

I’ve restarted Safari and run through every macOS DNS cache flush I can think of (sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache).

Debug Token:

https://tricorder.pi-hole.net/t171n9ofpy

Why don’t you use pi.hole?

If you try it with pihole.local/admin the you could get lucky. You are now visiting the old type of blocking page because you called it and not because you tripped any rules.

That is why whitelisting won’t help, because it is not blacklisted or blocklisted.

Indeed, that does seem to work, while pihole.local continues to fail.

I’d sure like to know what’s going on though.

It is designed that way. The blocking page is on level one and the prime page. The admin page is a rewrite and on level two as a service page. So you can use an IP address to activate it easier. It would be more difficult to call 192.168.0.1/blocking and that would be a URL.

More modern way of blocking Null blocking.

It still doesn’t make sense to me. BTW, mine is configured for NULL blocking.

But if I can go to http://192.168.2.251/ and http://pi.hole/, I should be able to go to http://pihole.local/.

I notice that only http://pi.hole/ redirects to the admin portal.

Null is good but the blocking page is still there for those who want to use the old way.

192.168.2.251 being the IP address of Pi.hole? should be showing you the blocking page.

webservers can rewrite a domain to a different URL and that is used here.

URL http:/ /IP-adress = homepage
URL http:/ /domain.tld = admin page (as example)

pi.hole is set in the hosts file to be used when that domain is called. pihole.local is handled by mDNS/avahii which has it’s own resolvers and does not resolve through pi-hole to the IP address of the pi-hole device. The pi-hole device does not know how to resolve .local domains so you see the page which is actually a 404 page, when it says it’s not on any lists it’s just returning a 404.

It appears mDNS is converting the pihole.local domain to an IP address but lighttpd has no idea who that domain is so it does not have any page to give you. Instead it does a 404 and gives you the block page.

That is because the configuration of lighttpd is set to redirect that particular URL to http://pi.hole/admin/

I understand redirects and 404. I guess I’d argue that the Pi-Hole 404 is very confusing for several reasons, not the least of which is that it says (paraphrasing) “You were blocked because that address is whitelisted and not on any blacklists.”

I’d argue that Pi-Hole should probably understand its Avahi name and handle that the same as pi.hole.

At the very least, it should send all unknown traffic to the home page or the admin page, as it does with <ip address>.

And I’d counter that we don’t know what the mDNS/Avahi/Bonjour name is going to be. We don’t interact with any of those systems. We do DNS and we can set up pi.hole as the local domain name and that’s what we have built Pi-hole to use. All of the documentation refers to that URL for administration.

Sending all unknown traffic to the admin page would defeat the use of a block page. Any domain that you are blocking would then show the admin page instead of the block page.

As far as the IP address working every time, that’s because there is no DNS name resolution involved if you use the IP address, so we don’t send all unknown traffic to the admin page. We send very specific domain names to the admin page and the IP address of the Pi-hole device itself. Those are items we can know without any possible confusion.

Per the argue/countering here, I’d like to throw my hat in the ring real quick. I got linked here by my similar issue Not Found On Any Blacklist

In my case I’m using an AD domain which has its own DNS servers, and I’m using a format of pihole.domain.local rather than pihole.local. Although to @DanSchaper’s point I wouldn’t expect PiHole to know what to do with any .local address, I did tell PiHole to forward those requests to my AD DC/DNS servers, and they know exactly what to do with .local addresses (so long as they are my AD domain). To @JetForMe’s point, I also would expect that any URL linked by an A record to an IP would return the same result in my browser as entering the straight IP. Which means that because when I go to http://###.###.###.###/ I see the PiHole logo :vortex: and text telling me what I found and the link to the admin page, I would expect that exact same page to pop up when I go to http://pihole.domain.local/, presuming that my AD DNS returns an A record with that IP for pihole in domain.local. I agree that returning a valid page for all unknown addresses is not ‘good’, but in this case my existing DNS said it’s not an unknown address. I don’t expect PiHole to know what to do with an address it isn’t configured for, but I do expect it to return the same as what it would return for the IP, instead of “this page blocked because it’s not configured to be blocked”. At the very least, it’s an error message which could be improved.

Ultimately, I can also use http://pi.hole/, which is IMO a functional workaround but not optimal in an environment where everything else uses naming conventions like http://web1.domain.local/ and http://mail1.domain.local/, and we’d really prefer to use http://pihole.domain.local/ for consistency’s sake. So +1 for passing that request onto the external LAN DNS instead of returning a wonkey error message, but if it’s an insurmountable thing to fix, it’s not a huge thing to ‘suffer’ with. Overall PiHole is an amazing tool and I’m glad it exists. :woohoo:

You could add to the lighttpd configuration and set lighttpd to understand what URL you would prefer and have that URL forward to the admin page. See the existing lighttpd configuration on how we do that and how you can replicate that with an external configuration.

The reason for the 404 page is that lighttpd doesn’t know how to answer the request since we can’t know beforehand what URL you would like to use. We include a URL that should work everywhere but if you would like different we provide for you to be able to customize to that.

1 Like

Further, to see what is happening and why you are getting this page, tail the lighttpd access log, look for the 404 and you will see why lighttpd has decided to return this page.

Thanks for your responses. You first stated that " The reason for the 404 page is that lighttpd doesn’t know how to answer the request", and then that I could “tail the lighttpd access log” to “see why lighttpd has decided to return this page”. Didn’t you just answer that, or did I misunderstand?

Ultimately, my goal is to write up a deployment and maintenance document so people who are not me can spin the VM/Docker/PiHole thing up as-needed, and the end-goal is to have as much configuration done in the webui as possible. Extra config modification for things under the hood is just asking for my techs to have issues. http://pihole.domain.local/admin/ works fine, it’s http://pihole.domain.local/ that returns a confusing message, and it’s probably easier for me to just include in the document “don’t go there; go here instead” rather than debate it until it’s smooth.

Its just that lighttpd doesnt know how to deal with your pihole.domain.local domain so it throws a 404.

You could configure a vhost in the /etc/lighttpd/external.conf file:

$HTTP["host"] == "pihole.domain.local" {
    server.document-root = "/var/www/html/admin/"
}

And reload to apply:

sudo service lighttpd reload

Lighttpd doesn’t have a problem serving up the admin page at pihole.domain.local/admin, so it seems to have no problem redirecting that to my AD DNS. And to be clear, I wouldn’t want pihole.domain.local to redirect to pihole.domain.local/admin. I would want pihole.domain.local to display the same exact page that I see from the IPv4 ip.ad.dr.ess. The same way that pihole.domain.local/admin displays the same page as ip.ad.dr.ess/admin.

$HTTP["host"] == "pihole.domain.local" {
    $HTTP["url"] =~ "^/$" {
        url.redirect = ( "" => "http://pihole.domain.local/admin/" )
        url.redirect-code = 302
    }
}

Sorry, it needs a doc root:

$HTTP["host"] == "pihole.domain.local" {
    $HTTP["url"] =~ "^/$" {
        url.redirect = ( "" => "http://pihole.domain.local/admin/" )
        url.redirect-code = 302
    }
    server.document-root = "/var/www/html/"
}

The special thing here is that blocking is done in the past with that page as IP. Why, because the table can be kept simple and efficient:

must.be.blocked 192.168.0.1
must.also.be.blocked 192.168.0.1
.
.

The client gets on a hit, 192.168.0.1 returned and that is not the real address in the internet but of the blocking page.

I think that we are now using a even simpler list and are omitting the IP addres. If you are on the list then you get blocked with the method you are using.

Webservers are great in being smart in handling many domains on one IP address and that is used by Pi-hole.

Now you have better methods of blocking and Null, nxdomain are popular. Null is very efficient and don’t trigger repeated requests by the client.

This page blocking page still exists because some still use it for users that need more information why the domain can’t be reached.

If one time the blocking page is fased out and/or we get the new API interface, the need for a webserver is not there any more. That take some time but it is coming for sure.

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