Pi-Hole not working as expected

Radu_Stefan_Ciubotar · June 4, 2020, 9:49pm

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

I don't know how the router would issue the dns requests as the DNS settings inside the router(for the internal dns server) are not even send to direct them to pihole. I am 100% sure the DHCP server is set to propagate the pi-hole DNS server to all the devices in the network. The pi-hole functionality is perfect. Everything worked perfectly until about 2-3 weeks ago when all of a sudden the report regarding DNS requests was full of request from the router IP rather than individual IPs.

RamSet · June 4, 2020, 9:52pm

I am not familiarized with this interface (can't recognize it) at all.

Is that the DHCP server setting for DNS ?

Is it an ISP provided device ?

Your debug log looks a lot better compared to the last one.

One thing i noticed though. You are using conditional forwarding, pointing at 254 instead of 1.
That's not going to work ...

Is 254 your DHCP server ?

Radu_Stefan_Ciubotar · June 4, 2020, 9:57pm

Not at all, it's not a ISP device. It's a Mikrotik router. That screenshot is for the DNS server inside the router.

This are the settings for the DHCP. 192.168.88.9 is the IP for the Raspberry PI.

Radu_Stefan_Ciubotar · June 4, 2020, 10:17pm

254 is the Active Directory Domain Controller for my domain, I need to forward specific requests to that DNS server.

RamSet · June 4, 2020, 10:40pm

That does look right ...

Your Pi-hole is set to listen to queries oneth0.

See if changing the listening behavior changes anything but I highly doubt that as it shouldn't be related at all.

The nslookup flurry.com still shows the same thing ?

It should record as blocked. What IP shows as originating from in the log ?

The only thing I can think of is somewhere, the query gets intercepted and .1 is used as the de-facto DNS server.

Pi-hole based on your debug log, is working as expected. The problem is with the request not reaching it the right way.

The DNS request originates from the client, and it hits the router, despite the DNS option set at DHCP server lever.

I understand the complexity of your network and using Pi-hole as the default DHCP server right now, ever for testing, is a bit of a pain.

I did see this behavior before and it always had to to with the router that played tough to get and didn't allow 53 traffic to be relayed with the network (fear of OpenResolver).

What about your firewall?

And restrictions on port 53 ?

It highly points at a configuration issue on the Router

DanSchaper · June 5, 2020, 1:41am

9 posts were split to a new topic: Something broke, fix it for me

Radu_Stefan_Ciubotar · June 5, 2020, 12:40am

In my case it is working, is just the reporting that is not going on right.

Radu_Stefan_Ciubotar · June 5, 2020, 12:49am

Default Server: raspberrypi
Address: 192.168.88.9

flurry.com
Server: raspberrypi
Address: 192.168.88.9

Name: flurry.com
Addresses: ::
0.0.0.0

The only firewall rules I have regarding port 53 is to drop incoming DNS traffic (WAN side).

RamSet · June 5, 2020, 12:51am

How did this record in the interface ? as originating from the client or still the router ?

Can you disable Conditional Forwarding for now, I have a slight suspicion it might have something to do with that

Radu_Stefan_Ciubotar · June 5, 2020, 12:56am

I will disable the forwarding and will report about changes in 10-15 minutes.

Meanwhile, you have attached the recordings.

RamSet · June 5, 2020, 12:58am

Ok that's the router.

Not good

Once conditional forwarding has been disabled, run a few tests without the domain controller, and post results....

Radu_Stefan_Ciubotar · June 5, 2020, 12:59am

Yeah, still the same behaviour, even with conditional forwarding diabled.

Radu_Stefan_Ciubotar · June 5, 2020, 1:31am

Personally I am out of ideas. I don't know what else to try.

RamSet · June 5, 2020, 1:41am

I think the last resort would be to run Pi-hole as DHCP server olly for testing purposes.

You can set the lease as low as 1h for that. Let's see if when the simple DHCP server (of Pi-hole) is enabled, the queries record properly.

That way, once isolated, focus can be shifted to whatever is causing this.

Remember that the clients need to pull a fresh lease from Pi-hole ...

DanSchaper · June 5, 2020, 1:43am

Have we confirmed the client only has Pi-hole's IP add the sole DNS server?

What version of RouterOS is running the Mikrotik? What model is it?

Are you comfortable with throwing a protocol analyzer on the network segment? Wireshark or tcpdump to get some packets and see the source/destination IPs in the packets?

Radu_Stefan_Ciubotar · June 5, 2020, 8:39am

The Pi-hole is the sole DNS server, I checked that on multiple machines.

The Mikrotik is a RB4011 with RouterOS 6.47.

You have the wireshark dns capture attached.

DanSchaper · June 5, 2020, 8:55pm

Okay, I'm on a RB4011iGS+ with 6.46.6 Firmware and Packages.

Can you run tail -f /var/log/pihole.log on the Pi-hole instance and then run some queries on a client? Check and see what IP addresses are showing from the log, specifically the from addresses.

Edit: When did you update the ROS? I see this ticket was opened on Jun 02 which is the date of the release of 6.47 which did change the DNS functions of ROS.

Radu_Stefan_Ciubotar · June 5, 2020, 11:03pm

I did upgrade the router 2 days ago, I saw that an update was available and I did it hoping it would fix the issue by itself.

Jun 6 01:59:04 dnsmasq[5268]: query[A] google.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:04 dnsmasq[5268]: forwarded google.com.DC-CONTAB.root to 192.168.88.254
Jun 6 01:59:04 dnsmasq[5268]: reply google.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:04 dnsmasq[5268]: query[AAAA] google.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:04 dnsmasq[5268]: forwarded google.com.DC-CONTAB.root to 192.168.88.254
Jun 6 01:59:04 dnsmasq[5268]: reply google.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:04 dnsmasq[5268]: query[A] google.com from 192.168.88.1
Jun 6 01:59:04 dnsmasq[5268]: forwarded google.com to 2606:4700:4700::1001
Jun 6 01:59:04 dnsmasq[5268]: validation result is INSECURE
Jun 6 01:59:04 dnsmasq[5268]: reply google.com is 216.58.213.14
Jun 6 01:59:04 dnsmasq[5268]: query[AAAA] google.com from 192.168.88.1
Jun 6 01:59:04 dnsmasq[5268]: forwarded google.com to 2606:4700:4700::1001

Jun 6 01:59:03 dnsmasq[5268]: query[A] flurry.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:03 dnsmasq[5268]: cached flurry.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:03 dnsmasq[5268]: query[AAAA] flurry.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:03 dnsmasq[5268]: cached flurry.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:03 dnsmasq[5268]: query[A] flurry.com from 192.168.88.1
Jun 6 01:59:03 dnsmasq[5268]: gravity blocked flurry.com is 0.0.0.0
Jun 6 01:59:03 dnsmasq[5268]: query[AAAA] flurry.com from 192.168.88.1
Jun 6 01:59:03 dnsmasq[5268]: gravity blocked flurry.com is ::

Jun 6 01:59:07 dnsmasq[5268]: query[A] facebook.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:07 dnsmasq[5268]: forwarded facebook.com.DC-CONTAB.root to 192.168.88.254
Jun 6 01:59:07 dnsmasq[5268]: reply facebook.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:07 dnsmasq[5268]: query[AAAA] facebook.com.DC-CONTAB.root from 192.168.88.1
Jun 6 01:59:07 dnsmasq[5268]: forwarded facebook.com.DC-CONTAB.root to 192.168.88.254
Jun 6 01:59:07 dnsmasq[5268]: reply facebook.com.DC-CONTAB.root is NXDOMAIN
Jun 6 01:59:07 dnsmasq[5268]: query[A] facebook.com from 192.168.88.1
Jun 6 01:59:07 dnsmasq[5268]: forwarded facebook.com to 1.0.0.1
Jun 6 01:59:07 dnsmasq[5268]: validation result is INSECURE
Jun 6 01:59:07 dnsmasq[5268]: reply facebook.com is 185.60.218.35
Jun 6 01:59:07 dnsmasq[5268]: query[AAAA] facebook.com from 192.168.88.1
Jun 6 01:59:07 dnsmasq[5268]: forwarded facebook.com to 1.0.0.1
Jun 6 01:59:07 dnsmasq[5268]: validation result is INSECURE
Jun 6 01:59:07 dnsmasq[5268]: reply facebook.com is 2a03:2880:f1ff:83:face:b00c:0:25de

The DNS requests look like they are coming from the router rather than from the client itself. What is strange is that right now I'm connected over VPN to the location with the problem and over the VPN I have an IP in 192.168.50.0/24 and I see that specific IP as being logged inside the PI-Hole correctly. I have connected to a local machine, one in 192.168.88.0/24 network and request are still shown incorrectly.

DanSchaper · June 5, 2020, 11:34pm

What do your firewall rulesets look like?

Radu_Stefan_Ciubotar · June 6, 2020, 12:13am

Sorry for the screenshot, I'm currently away and with no access to a pc.