Sometimes domains fail to resolve with DNS redirection

I've been using pi-hole with unbound for a long time with no trouble, but today after testing a device with a hardcoded Google DNS resolver on my network, I decided to try to force all traffic on my home network through the pihole. I did this by enabling an option on my router to forward all outgoing DNS requests to local DNS proxy which is the pi-hole/unbound DNS it is configured to use.

The problem that I am having is that now some sites do not resolve. They are not being blocked at the pi-hole according to the query log, but in chromium I get an error that the site that I am trying to reach does not have an IP address. I'm certain it has to do with my router since pi-hole and unbound work otherwise, but I cannot figure out what the issue is.

Another interesting thing is that when I try to force all traffic through my router to use the pi-hole for dns and I run a DNS test, I suddenly have 22 DNS servers. I usually have one when I test when I do not force traffic on the router to be rerouted to the pihole.

Hey henrydon, welcome to the pihole community.

I can't help with your current issues, but maybe can offer an alternative solution:
Have you tried to block all outbound DNS traffic except for the Pihole via firewall rules instead of using NAT to force all your traffic to pihole? I got good results with bocking as the devices with hard-coded Google DNS used to fallback to my DHCP announced DNS-Server (pihole) after a few unsuccessful attempts to resolve via Google DNS. Of course it depends on how it is implemented in the specific devices but might be worth a try.

If this is a very recent change, this might be a caching issue.
Try to clear your caches and see if the problem persists.

That's highly unusual.
How did you determine that? Would you be able to provide output for the command you used, or any screenshots?

Also, it might help to know what make and model router you are using, if just to attract other users with similar experiences.

As for the jump in DNS servers, I used the DNS leak tests on routersecurity dot org and I've attached before and after screenshots from browserleaks dot com below:

I'm using a Pepwave Surf SOHO MK3 router, and the only option I've changed is to forward all outgoing DNS requests to local DNS proxy.

I'm going to play around with things and try clearing the cache, but so far no luck.

Aye, that tool is providing an answer to a different question than I thought to be asked.
Externally observing 22 DNS server contacts is not unusual if you are using unbound. :wink:

How many DNS servers are clients in your local network using?
That should be answered with one, i.e. your Pi-hole.

Pi-hole in return forwards non-filtered DNS queries to unbound, and unbound then does a recursive lookup, contacting root servers first and authoritative DNS servers next and so forth until a name is returned.

Caching issues should mostly be gone by now.

If you're using DNSSEC, that may lead to ocassional failures in lookups, sometimes due to diverging times between the public DNS servers and on the Pi-hole machine (especially on an RPi, as that lacks a hardware RTC).
Normally, on of the next few consecutive lookups succeeds, and this goes unnoticed.

But maybe it is something related to your browser. Are you experiencing DNS lookup failures with other programs as well? Also, can you provide an example for a domain name that defied resolution in Chromium?

Is it this device? According to the manual page 23 you can "Include Google Public DNS Servers". Did you enable that?
Can you share a screenshot of your router's settings?

I appreciate your help, guys. I'm using one DNS within the Pi-Hole, 127.0.0.1#5353 and DNSSEC is not enabled -- should I enable it?

Is there a reason why the externally observed DNS would jump from 1 server to 22 after forcing all traffic through the Pi-Hole? Just curious.

Interestingly, this time around (I rebooted my router and my Pi-Hole) everything on the web (using Chrome and Chromium) seemed to result in a lookup failure. I tried it on a laptop, a Raspberry Pi connected to my TV, and my phone. Initially it was only a few sites I tried, like grc dot com, but I only rebooted the router before and not the Pi-Hole.

As for the router, the manual is the correct one. I do not have the Google Public DNS Servers option enabled. I will include screenshots of my router's settings in the next reply.

Something I noticed while looking at my router settings was that WAN DNS settings were set to obtain automatically, while LAN DNS is set to the pi-hole. When I try to set the WAN to use the pi-hole as well, I lose access to the internet.

Is 192.168.50.24 your Pihole server? This IP is overlapping with your DHCP Range which might cause trouble. You should assign a static IP to your Pihole outside of your DHCP range (e.g. below 192.168.50.10) and run pihole -r again.

As far as I have understood the function of the router for DNS Proxy I can see no way how to use it as long as Pihole/unbound is part of your LAN. Imagine you have no Pihole, and DNS Proxy is enabled. All DNS traffic will be interceped and forwarded to the WAN's DNS Server. But if you use Pihole also its traffic will be intercepted.
If you configure Pihole also as WAN's DNS you create a DNS Loop: Client-> PIhole -> Intercept -> WAN -DNS (a.k.a Pihole) - Intercept....
If Pihole is not your WAN DNS it should work, but unbound might be worthless: Client -> Pihole\unbound -> Intercept - WAN's DNS (Cloudflair, etc)

I changed the title of the topic to include more info for following readers.

Thank you for clearing that up, I understand why it's not working now. I wonder if there's a way to force all traffic through my Pihole so rogue devices have to use the Pihole DNS.

What I would do now:

  1. Assign a static IP to the Pihole outside of the DHCP range
  2. Distribute Piholes IP as DNS via DHCP to Clients
  3. Set Pihole as DNS for your WAN Interface
  4. Disable DNS Proxy

(What you really want to have is NATting for all DNS traffic that is not directed to your pihole. I had a quick look at the manual - there is a section about NAT mapping but it seems it is not possible to only redirect DNS traffic with your router.)

I did address that in my previous post - please check.

With regards to your router's DNS proxy option, I find your manual to be inconclusive.

The DNS proxy screenshot shows a section labeled DNS Resolvers that would allow you to define a custom DNS server for a LAN connection, which seems to be what you want.

However, the description for DNS Resolvers reads

Check the box to enable the WINS server

From your observation, yubiuser is right in diagnosing a DNS loop, but it is not entirely clear if you had used that last option or not.

Either way, you may want to seek clarification with the folks at Pepwave - their forum runs on Discourse as well, and they seem friendly enough over there.

The term NAT might lead to misunderstandings when used to discuss with Pepwave support.

Commonly, a full NAT (or network address translatin) would be understood to comprise your entire network traffic and include address rewriting, i.e. replacing the sending computer's IP with your router's, forcing all traffic -send and receive- through your router.
You'd effectively be double-NATting your network to the external public and to internal Pi-hole, which is not required.

What you need here is a simple port redirection for DNS protocols, rerouting DNS traffic directed at an arbritary IP to your Pi-hole machine and have Pi-hole provide answers directly to clients in the same local network.

While this is still achieved by defining a rule in the NAT table, it is distinctively different from the rules and behaviour invoked when using the term NAT for routers.

If your router ultimately does not support DNS port redirection, you should consider yubiuser's early advice of blocking DNS ports at your router. Again, you should probably check the Pepwave forums for configuration specifics - they likely are more experienced in these matters over there.

That said, our forum would appreciate if you'd still share your findings here once you've got things sorted.

Independent from that, we'll be here to assist you with any Pi-hole issues you may encounter. :wink:

Thanks for making this clearer.

Thank you, guys. I apologize for any misunderstanding, because English is not my first language occasionally I have some difficulty with comprehension, though I am overall pretty good!

I have also created a posting on the Pepwave forum and was provided the following link, just in case it helps anyone searching this forum.

I will try suggestions later today.

The link describes the basic setup of pihole and the settings necessary to distribute its IP as DNS server via DHCP to other devices in the LAN.

It will not solve the problem of hard-coded DNS-Server in some devices, as noted in #5 of the instruction.
"Pi-Hole should now be functional. Test. If it’s working, also test whether it works when RPi is shut down. It shouldn’t work, but some devices have hard-coded DNS that will work when your Pi-Hole DNS is off. It’s good to know either way."


No need to apologize. It isn't mine neither.

Yes, you're right. I just finished reading it and it's the same setup as I already have, except I didn't select the luggage tag DHCP reservation. I'll follow your suggestions mentioned above!

This is not necessary if piholes IP is outside of the DHCP range.

Sorry for the delay, I only now got to trying your suggestions. The Pihole is now outside of the DHCP range, it is also set as the WAN DNS, I have selected the option in the Pihole settings to enable the DHCP server, and I have disabled the DNS proxy setting on my router. But I updated my mobile phone to use Cloudflare DNS and am still able to bypass the Pihole DNS. I've been playing with the router settings for the firewall, and even though I realize I don't know what I'm doing, it doesn't seem that I am able to block all outbound DNS except for the Pihole. I will spend some time later trying to understand how to setup the firewall for this situation later today.

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