Common browsing on all websites except those are blocked.
Actual Behaviour:
Some domains give the ERR_ADDRESS_INVALID error in Chrome. Firefox gives another error. If I disable blocking (either by changing DNS settings in Windows or in the admin panel) all domains work like a charm. I have already re-installed Pihole on a new machine, removed cloudflared from the options but to no avail. This wasn't happening before the last Pihole-update but I'm not sure about that. It started with a single domain, now more and more domains are failing like web.whatsapp.com but also googleadservices.com (which used to give me a DNS lookup failure until I temporarily turned off blocking, which was working as intended).
Total amateur here. Googling, I see someone got this error and found they had disabled the google helper service. The browser is responsible for downloading all the html content and the helper service downloads the rest such at video and other none-html content. Since Pi-hole works for most and not for you it could be your choice of adlists preventing the helper service from working if you haven't disabled it..
I've narrowed it down to a single blocklist regarding WhatsApp (https://raw.githubusercontent.com/blocklistproject/Lists/master/facebook.txt). Now I did a lookup (stupid I didn't think of this myself..) and it appears to be on this list. Either this list was updated or I switched to another domain in the CDN.
I still think it is weird that it doesn't show me the regular DNS error message in both Firefox and Chrome but the current error I am getting. I'm getting the same invalid_address error with other domains like the Google Ads from the Google search results either. It gives the exact same error code. So I'm not exactly sure what is happening but I think it is sort of bug combined with a work as intended sort of thing. Downside is that before with a ERR_NAME_NOT_RESOLVED turning off PiHole with a browser extension for 10 seconds and then refreshing was sufficient. This new error it is not and that is sort of frustrating. I can refresh for 10 seconds and nothing happens. Incognito-window does work though so I guess the error adds something to the cache of Chrome as well.
I tried to set-up a block-page just now without a custom page and now the error changes to ERR_CONNECTION_REFUSED which works a little bit better but still not the error message that I should be getting. All I did was add 'BLOCKINGMODE=IP-NODATA-AAAA' to the pihole-FTL.conf.
It's good to know it has something to do with blocklists but somewhere in the DNS response the Pi gives it goes wrong I guess. Could do a Wireshark thing if that is helpful?
Your nslookup results for web.whatsapp.com are identical, regardless whether resolution is forced through your Pi-hole at 10.2.1.8 or a public DNS resolver at 1.1.1.1.
In other words:
Pi-hole is not blocking that domain.
Therefore, for Pi-hole to be involved, any irregularities you observe in conjunction with browsing web.whatsapp.com must implicate other domains.
It is blocking it, think I accidentally turned off the adlist that is blocking that domain during the previous lookups:
I can get around that by adding a regex or something to whitelist the Whatsapp CDN. What I still can't get my head around is the fact that I'm not getting and ERR_NAME_NOT_RESOLVED errors anymore when a domain is blocked but the ERR_ADDRESS_INVALID. As mentioned before the new error message does something with cache as well as I can't just turn off blocking for a few seconds and refresh. It takes a significant amount of time before it actually works. With nearly 4.5 million domains blocked this is no problem for most of the time but sometimes when you want to quickly disable Pihole because an ad-domain is on a blocklist then it's very anoying.
Hm. Then how were you able to still trigger the error when that adlist was turned off?
Pi-hole has no say in what a client does after a domain has been resolved or blocked, or what messages it may present.
The change you are observing may be triggered by one of your many adlists updates, or maybe you are using additional filtering/caching (e.g. dedicated firewall or web proxy), or is that client accessing Pi-hole via a split tunnel VPN?
Also, as you've noticed a change in client behaviour, that may warrant investigating the client further. Specifically, try to find out which ADDRESS the client complains about, and see if that would be
The error was triggered by turning the adlist back on. I'm still convinced that something in PiHole isn't going as it is supposed to regarding the errors. If I add BLOCKINGMODE=IP-NODATA-AAAA to pihole-FTL.conf the error given when accessing blocked domains changes to ERR_CONNECTION_REFUSED. The refused-error also appears on other devices like Android 13. I'm not sure what to believe anymore regarding this fact or where to look. I've checked again with the blockingmode set to default (by removing the blockingmode from the config file) and with the IP-NODATA with another domain that is blocked when SSH'd into one of my Ubuntu virtual machines that is in the same network:
PiHole is on my local network in the same subnet as my machine. My VM's are in different subnets (except the one I just screenshotted) and so are my wifi-devices.
I think I solved it by setting the blockingmode to NXDOMAIN, now I get the ERR_NAME_NOT_RESOLVED error as expected and what I am used to work with. Disabling PiHole for 10 seconds lets me refresh and the domain gets loaded as well without any problems like the other error-messages gave me. My Android-phone gives the same error now as expected. When changing blocking mode back to NULL I get the original ERR_ADDRESS_INVALID error which gives problems.
Not entirely sure what this piece of the support-pages means exactly in practice. I'm pretty used to networking and things but I'm feeling pretty stupid now
This mode is similar to NULL blocking mode, but experiments suggest that clients may try to resolve blocked domains more often compared to NULL blocking.
