Windows 10 now bypassing pihole?

[jpgpi250]

Hope I'm wrong (logic error?) but...

Like a lot of you, I've implemented a NAT rule, redirecting all DNS queries, not originating from pihole. We all know this happens (android, chromecast, nvidia shield, ...), so once it works, we never look back (I didn't).

In order to get a clear picture of the culprits, I've added something to my pihole to be able to log these redirections, full manual (how to) here (pfsense + pihole-FTL + dnsmasq).

Looks like it works, the devices mentioned above all try to bypass pihole, the queries are logged (by the additional dnsmasq - NOT listening on port 53) and eventually replied to by pihole.

Today, however (192.168.2.228 is a windows 10 laptop):

thus redirected to pihole (all redirected requests arrive from the secondary IP address 192.168.2.47)

I checked, before today, all the requests for the domain fe3cr.delivery.mp.microsoft.com went straight to pihole (no attempt to bypass), however, as of this morning, these queries (only for the above mentioned domain) attempted to bypass pihole.

Unfortunately, pfsense doesn't have a logging option on NAT rules, so I have no idea where these requests would like to get a reply from (the original query -> NS target).

I haven't installed anything additional on the laptop recently, so this has to come from something that was already installed, behaved as it should (use configured DNS server) and changed it's behaviour (trying to bypass) today.

[Bucking_Horn]

Couldn't you just run a pfsense Package Capture for all DNS requests not going to your Pi-hole's host address?

That should at least reveal the evasive DNS server your client intended to use.

[jpgpi250]

from this (v.1909) document:

the domain (fe3cr.delivery.mp.microsoft.com) doesn't appear anymore in this (v.21H1) document, but the wildcard does (*.delivery.mp.microsoft.com)

forcing a windows update causes a bypass attempt -> packet capture:

23	280.265594	192.168.2.228	162.159.36.2	DNS	91	Standard query 0x92a4 A fe3cr.delivery.mp.microsoft.com
24	280.266415	192.168.2.228	162.159.36.2	DNS	91	Standard query 0x02d3 AAAA fe3cr.delivery.mp.microsoft.com
25	280.271603	162.159.36.2	192.168.2.228	DNS	179	Standard query response 0x92a4 A fe3cr.delivery.mp.microsoft.com CNAME fe3.delivery.mp.microsoft.com CNAME glb.cws.prod.dcat.dsp.trafficmanager.net A 40.125.122.151
26	280.272082	162.159.36.2	192.168.2.228	DNS	191	Standard query response 0x02d3 AAAA fe3cr.delivery.mp.microsoft.com CNAME fe3.delivery.mp.microsoft.com CNAME glb.cws.prod.dcat.dsp.trafficmanager.net AAAA 2603:1020:2:3::67

dig -x 162.159.36.2 -> NXDOMAIN
host 162.159.36.2 -> Host 2.36.159.162.in-addr.arpa. not found: 3(NXDOMAIN)
ping 162.159.36.2 -> reply

not really getting much information here (NS server name)

any ideas?

[Bucking_Horn]

Hmm, are you running an enterprise Windows on that laptop?

Sorry I can't be too specific as I do not run Win10 personally, but I think that looks similar to the default fallback DNS server configured by Windows group policies in case Windows has difficulties contacting the Windows update server.
I can't name a source, but there should be a registry key pointing to that specific address. Overwriting its value should address your issue, but I wouldn't expect that registry entry on Windows consumer editions.

[jpgpi250]

@Bucking_Horn

are you running an enterprise Windows on that laptop?

found a registry key containing the IP address

that contains, among a lot of other XML info, a string:

ID="DNSResiliency-CloudFlare-Live"

This fallback must of been activated by something, no idea why, I haven't noticed any pihole DNS delays or problems...

[Bucking_Horn]

Just guessing here:
A recent Windows update may have introduced that change.

Or it was always present, but a recent change of one of your blocklists blocked a domain that previously has been accessible by Windows' update feature, which in turn triggered the use of that fallback server.

In any caase, it may be a good idea to watch that registry key on Windows updates.

[jpgpi250]

@Bucking_Horn

a recent change of one of your blocklists blocked a domain that previously has been accessible

Not the case, I monitor this (automated - using the old gravity database to calculate 'new blocked' and 'new allowed' / compare with my actual queries, used code here). This week, only one domain that was accessible (and used) before the weekly gravity update is now blocked (collector.github.com). Also, windows update would have failed, since redirection (to pihole) is in place, everything is always resolved by pihole.

@Bucking_Horn

A recent Windows update may have introduced that change.

Or it was always present

Just guessing here:
could have been a temporary DNS resolution problem, it (redirection) didn't happen today (windows update is triggered every 22 hours). Recently, I see more unbound problems reported, latest I've seen (reddit) here, on this forum here.

I just need to improve on alerting.