My pi-hole (docker) is reporting many (80+ at the current count) :
"possible DNS-rebind attack detected: dns.msftncsi.com"
Is there a way to pin down which host/hosts are generating (or receiving) erroneous requests? (and/or what the results are?)
From this machine, it resolves (correctly) to 131.107.255.255 but something is clearly upsetting piHole.
Do you have an ASUS router? I believe they use dns.msftncsi.com to check the WAN status.
Nope, Unifi UDM-Base.
I also have a hybrid DNS setup, which using dnsdist and splits between pi/hole (with blocklists) and OpenDNS (if pihole fails) - but pihole is set to route via OpenDNS anyway 
My PC can resolve the IP, so I'm trying to figure out what device/s is making it go mad...
(I've temporarily blacklisted it for fun to see what breaks)
Where specifically are you seeing this message?
I'm using the LCARS interface/GUI and I'm seeing it in the marked location (although I've restarted and it's cleared). I'll see if I can grab one if/when it does it again. It has a warning triangle and a notification count.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
pihole -d
or do it through the Web interface:
Tools > Generate Debug Log
Will do once I get one reporting again.
The diagnosis messages are stored unless you remove them. They will be included in the current debug log. Please upload the log.
I restarted the container earlier, and have checked and apart from my (disabled) regex there is no matching domain entry in the pihole_debug log atm...
But pihole-FTL.log contains (many) entries which read (all identically, barring timestamp)
pihole-FTL.log:[2022-02-09 14:09:56.101 49387M] WARNING in dnsmasq core: possible DNS-rebind attack detected: dns.msftncsi.com
Can I get the debug token please?
I shall PM you
You can safely post this token publicly. Only members of the Pi-hole team can access the log via the token, and it auto-expires in 48 hours.
From your debug log.
-rw-r--r-- 1 root users 736 Jul 7 2021 /etc/dnsmasq.d/02-override.conf
dhcp-option=vendor:ubnt,1,http://10.74.1.1:8080/inform
stop-dns-rebind
You can configure added exceptions for the domain(s).
AandAAAAanswers are checked against possible rebind attacks whenstop-dns-rebindis enabled. Seerebind-domain-ok=/domain/for adding exceptions.
Hi
My understanding is that the DHCP vendor option (for ubnt/ubiquiti) is just there to point any new Unifi devices at my controller for adoption? (and they're all adopted) - so shouldn't relate? (I may be missing a thing here) - so it's not clear why dns.msftncsi.com is the one domain being alerted on, or which devices are querying for it/responding to it?
My DNS image (which passes the queries onto piHole for resolving/filtering) can log - so I might enable that as it logs the IP/MAC in debug mode.
A DNS rebind would invole an upstream DNS server returning a private range IP address for a public (non-local) domain.
Did you have a look at Pi-hole's logs for the DNS queries that preceded the dns rebind warning?
The interesting part would be the actual DNS replies and where they were sourced from.
You may grep for them, e.g.
zgrep -n -m 1 dns.msftncsi.com /var/log/pihole.log*
...and your debug log contains:
*** [ DIAGNOSING ]: contents of /etc/pihole
-rw-r--r-- 1 pihole pihole 77 Feb 9 17:18 /etc/pihole/pihole-FTL.conf
REPLY_ADDR4=0.0.0.0
It seems you are affected by a known issue (#956).
Please consider setting the recommended FTLCONF_REPLY_ADDR4 Environment Variable for your container to your Pi-hole's IP address.
I'm waiting for it to happen again to trap - I periodically wipe the .db when it gets too large, and/or if I do a docker restart (pihole is part of my custom DNS stack).
The Unifi Router WAN/common settings are set to 8.8.8.8 - however it's also set to block ports 53/853 etc outbound from anything on the LAN, other than from my pihole/DNS servers.
My DNS listener (53, DoH and DoT) passes queries to piHole to ad filter, which passes them to OpenDNS (via DNSCrypt) for wider DNS filtering. If piHole fails, the DNS listener routes directly to OpenDNS as a fallback (I just lose my local LAN domain DNS resolver).
LAN hosts and the UDM are both resolving dns.msftncsi.com to the same (correct) IP - so I do wonder if it's something trying a XSS type attack via a page :\
There is nothing I could see at the time but I'll put some logs on my front end to see what requests the host at least (that will at least get me a device)
The logs (and Pi-hole's long term database) should still have those DNS requests.
By default, the logs should reach back as far as 5 days.
If that's not enough, you could also consider searching the long term database (unless your periodical .db wipe just happened recently).
Via the UI that typically fails with memory errors. sqlite3 queries to the db work but are more irksome.
I've got front end logging on now so can track that way (if any show up now)
Well, I've got one alert. At 22:28, but checking for msft I find the following, which includes some dns.msftncsi.com and some not - but only one (at 22:28) seems to have tripped the alert.
I may need to amend my log to see what the response provided was, but it's a device on my LAN that uses a VPN to connect to another network, so that's likely something....
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:32:34.800465749Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:32:35.773932375Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:36:14.461835367Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:38:45.243577095Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:38:45.403379112Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:42:23.429304852Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:42:23.669020038Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:42:24.287559454Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:45:23.511981516Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:45:24.111180037Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:45:24.53103526Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:48:58.343946879Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:48:58.589256006Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:48:59.216106909Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:51:58.244849692Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:51:58.924605618Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:51:59.146100932Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:51:59.163740819Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:51:59.288974759Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:55:35.781553318Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:55:36.134052039Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:55:36.762385266Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T20:57:08.490411353Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:00:18.387579017Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:00:18.618285266Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:00:19.251379833Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:03:18.318346521Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:03:18.981755412Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:03:19.203895427Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:06:18.349867281Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:07:44.263980495Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:07:45.12183808Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:10:14.999497598Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T21:10:15.822851985Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (www.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T22:28:18.781521721Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (ipv6.msftconnecttest.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T22:28:19.094379914Z"}
{"log":"# DIAB : LOG : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.) - Allowing.\n","stream":"stdout","time":"2022-02-10T22:28:19.146400813Z"}
pihole.log just shows:
Feb 10 22:28:19 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
pihole "long-term" log shows:
|2022-02-10 22:28:19|DS|msftncsi.com|::|OK (forwarded to 10.74.90.136#9001)|Blacklist|
| --- | --- | --- | --- | --- | --- |
|2022-02-10 22:28:19|A (IPv4)|ipv6.msftconnecttest.com|10.74.50.14|OK (forwarded to 10.74.90.136#9001)|
and one entry which shows the internal (VPN) domain, so I think it's something re: that device's VPN - which should be ok to whitelist - but it would be good if piHole could show the requesting client AND response IP, to cut this down
(for reference, the blacklist is disabled, and the forward is the one to OpenDNS)
That lookup seems fresh enough to be even available from Pi-hole's in-memory dashboard, and it would be in the logs as well.
What are the corresponding lines from the log file?
The following grep can be helpful:
grep -n dns.msftncsi.com /var/log/pihole.log*
Of course, we'd need just those that would preceed the warning, around 22:28.
That does not seem to be the case, as it contradicts both your Pi-hole's "long term" quote and your log debug log, showing that another internal DNS server is used as Pi-hole's upstream:
*** [ DIAGNOSING ]: Setup variables
PIHOLE_DNS_1=10.74.90.136#9001
PIHOLE_DNS_2=10.74.90.136#9001
Whatever DNS service is replying on 10.74.90.136#9001, that service would return the offending reply, so I'd expect the log lines to show a private range IP or a loopback address as reply.
In any case, you should also consider to check the corresponding logs at your 10.74.90.136 machine, as well as its configuration in regard to treating dns.msftncsi.com.