Please follow the below template, it will help us to help you!
I am trying to install Pi-Hole on my local network on my Raspberry Pi Model B. Installation went fine and is running the latest version. In this scenario I set my local machine's DNS resolver to point to the pi-hole IP. I tested both UDP and TCP using the dig utility.
I'll bet my router is intercepting all UDP/53 calls and sending it to the configured DNS server, nixing my ability to set it on the OS (or even test it with dig). Someone on gitter called it "DNS Rebind Protection". Unfortunately there's not a switch for this feature in my router settings.
My next test will be to disable DHCP on my router and let the Pi Hole take over.
This is a really ugly feature and we're aware of some Google routers that cannot be used with Pi-hole (or any custom internal DNS server). They are doing exactly what you described
I don't think switching to the Pi-hole DHCP server would help, but please still try it, maybe the router also disabled rebinding protection when the DHCP server is disabled. Can you set the Pi-hole's IP as DNS server somewhere in your router's settings?
I don’t think switching to the Pi-hole DHCP server would help, but please still try it, maybe the router also disabled rebinding protection when the DHCP server is disabled. Can you set the Pi-hole’s IP as DNS server somewhere in your router’s settings?
You were right, disabling DHCP didn't do anything.
But I did solve it, though it probably won't be very helpful to others with the same issue. I updated the firmware of my router to the latest and the problem went away. Perhaps they had a change of heart on this feature.
My backup plan was to install DD-WRT (which does offer a checkbox for this feature).
I wouldn't demonize DNS Rebind Protection as such - it's a security feature (click for more).
DNS Rebind Protection is indeed a useful means against a certain type of attack against your network, namely DNS Rebind, where a foreign public DNS server has been compromised and would answer DNS requests for certain public domains malicioulsy with a local IP address in order to snoop your network for further angle's of attack or even to deliver harmful content that appears to be coming from a trusted source.
Your router will therefore discard any DNS answers received from a public DNS server that contains a local IP address.
That's a good thing, generally.
What makes this a hassle is that each router model and even firmware version exhibits a different behaviour for DNS Rebind Protection, and may or may not offer ways of configuring it, either globally or specifically for a device (click for more).
Your router will likely consider any of its configured upstream DNS servers as being of public (=foreign) origin, regardless of that DNS servers actual IP address allocation.
This is not a misbehaviour of your router per se, just a security precaution.
If changing your upstream DNS servers is your only option of injecting Pi-hole into your network, then you need to disable Rebind Protection for Pi-hole.
Your router may also treat local DNS servers as defined within its DHCP settings as foreign, but may or may not respect local IP addresses as exempted automatically.
Hence, it would depend on your router's model and firmware version whether DNS Rebind Protection will discard DNS answers with local IPs.
If so, you also need to disable Rebind Protection for Pi-hole.
Some routers will allow you to define exemptions from DNS Rebind protection (e.g. by putting pi.hole or its IP address on an exemption list, which would be the preferred way) or to disable it completely, either locally (i.e. for DNS servers in your local network, which is OK as well) or globally (which I would only consider as a last resort, as this will leave you open to DNS Rebind attacks). Why won't Pi-hole work with DNS rebind protection enabled? contains a few examples for configuring exemptions.
Note that some routers require a full restart to activate those settings.
Yet in all cases, DNS Rebind Protection would affect both UDP and TCP protocol DNS answers.
In contrast to this, the behaviour that your setup was showing - treating UDP different from TCP - is definitely dodgy.
I wouldn't be a 100% sure whether this is accountable to a bad DNS Rebind Protection implementation, but I am glad you were able to resolve this.
I wouldn't demonize DNS Rebind Protection as such - it's a security feature
That's good insight, thank you. It wasn't my intention to demonize the feature.
Yet in all cases, DNS Rebind Protection would affect both UDP and TCP protocol DNS answers.
That leads me to revisit my assumption that the router was trying to implement DNS Rebind Protection, since UDP was treated differently. Perhaps it was simply a bug in the firmware that was squashed with the latest update.