this may be interesting - or it may not. I can't explain it either way.
Installed pihole fresh last night just before heading to bed. Aimed my router at the pihole ip address, rebooted all the devices. All working, I thought...
wake up in the morning and have a look at the dashboard and see this...
Created a debug file if anyone wanted to take a look. the IP address these connections were made from... (while I am asleep?) is a linux machine.
[✓] Your debug token is: 7s8dtd40vd
I can't find much on it a quick google-fu shows https://productforums.google.com/forum/#!msg/chrome/5NKGtr5p3yk/yODNJtoc5KAJ where it appears Malware Bytes blocks this url every now and then. Oh if it's not clear from the debug token, I blacklisted it as soon as I woke up that's why it will appear there
pihole log shows:
Dec 30 03:46:06 dnsmasq[684]: query[A] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:06 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
Dec 30 03:46:06 dnsmasq[684]: query[AAAA] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:06 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[A] 0-undefined.facebook.com from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[AAAA] 0-undefined.facebook.com from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[A] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[AAAA] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[A] 0-undefined.facebook.com from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[AAAA] 0-undefined.facebook.com from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[A] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
Dec 30 03:46:20 dnsmasq[684]: query[AAAA] 0-undefined.facebook.com.lan from 192.168.1.102
Dec 30 03:46:20 dnsmasq[684]: cached 0-undefined.facebook.com.lan is NXDOMAIN
I don't use facebook so I'm not familiar with their app ecosystem. But my first thought is that some app on 192.168.1.102 is in a phone-home-frenzy. The app might be bugged; the name of that facebook subdomain[?], "0-undefined..." doesn't look right. Some programmer likely dropped the ball and the app isn't correctly loading whatever name that should be. Since the app can't phone home, its probably, annoyingly, programmed to keep trying until the server responds.
Actually, that was my second thought. My first thought was that this isn't a pihole problem. Its a pihole benefit. Your pihole discovered a problem on your network of which you took immediate notice. Check out these these pihole posts for many many eyepopping stories where a pihole discovered Gadgets Gone Wild. Its definitely a benefit.
So like I said, I don't know squat about facebook. Check around on 192.168.1.102 for facebook related apps and shut them down as a test. I think that's the problem there. Also it might be worth looking into whether other people are having this problem with 0-undefined.facebook. com.
it looks like the URL belongs to the web chat interface so when you browse to the site it fires up all the chat domains. so you're right, if the chat wouldn't connect automatically for some reason, I guess it just continually retries until it does. still incredibly weird and annoying.
I don't see how a browser should be making that many repeated attempts at something in the first place. 12,000 connections in a few hours. It seems to be on malwarebytes blocklists every now and again too I guess for this reason
I just noticed something. There is something wrong with your pihole after all. Look at the first two "top domains''. The pihole is looking up each query twice, once out in the world and once again locally with the .lan suffix. I haven't seen this behavior before. Could this be a matter of toggling the FQDN setting in the pihole? Solving that won't fix the app, but it will cut those queries almost in half.
