Specifically for detecting if a user is not using their DNS, yes you could correlate a user's http requests (unless you are using ESNI the requested domain is in plaintext by design) with traffic logs on their DNS server and observe that there was no DNS request to the ISP DNS server before a request was made, I don't think that would be necessary. Most users use the ISP default DNS - that's your baseline. If most customers hit your DNS X times per Mb of web traffic, then someone using a custom DNS is going to stand out like a sore thumb.
Again, 100% agree that ISPs are not very technically competent (to put it mildly), but as time marches on the ability to both capture and more importantly analyze and report on that data is becoming cheaper and easier. ISPs want to get value from (sell) your data and vendors want to sell ISPs subscriptions to analytics and other platforms that bring them reoccurring revenue. Data from customer DNS is one of the most valuable sources of information an ISP has and I would be surprised if there was not at least an attempt to know how many customers did not use it.
Looking at you, Chromecast that tries 8.8.8.8 40 times an hour even though you know perfectly damn well that 10.10.10.1 is working
And with newer decides that use DoH, you can no longer prevent devices from contacting their own DNS provider without totally firewalling them (or perhaps using some IP blacklist or whitelist, if available?)
Everything that I don't have complete visibility into the network stack of goes on a VLAN that does not forward traffic to the internet, it advertises a proxy via WPAD and DHCP option 252. I have a whitelist of hostnames that each device is allowed to make CONNECT requests to, so far there is only one.
If it's not a plain unencrypted HTTP request to my proxy, or a CONNECT request involving a server/device pair I've decided to trust, it's not going anywhere.
This breaks a lot of things that I would just as soon rather do without. I can't change my universal remote hub settings from the vendor portal, boo-hoo. I can't view my cameras from the hardened VLAN or from the internet (unless I VPN in first since the only copy of the recordings is on my local NAS)... good.
I have an "XFi Gateway" combination modem/router provided by Comcast (perhaps my first mistake) so the DNS settings are restricted and cannot be changed. I have the Comcast modem/router set to bridge mode and connected my own router where I can control the DNS settings.
My understanding is the DNS settings closer to the client control. So in addition to having set my router to Cloudflare's DNS I also set my devices as well. One day, maybe a year ago or so, I'm on HN and I click an archive.is link, read the article, and go to the discussion thread only to see several comments about how archive.is is blocked by Cloudflare DNS. I checked the DNS settings on my MacBook and router and I was indeed using Cloudflare DNS but for some reason I was able to access the "blocked" address.
So I went to the terminal, cleared the cache, and checked nslookup archive.is and it responded correctly. Then I checked a nonsense DNS server: nslookup archive.is 5.9.3.7 or something and it still responded correctly. I tried the same with different websites and got the same result. So I searched "see my DNS server" or something and found a few websites but they all showed Cloudflare. Very odd.
When I logged in with my VPN, Mullvad, and changed the DNS settings on the router and my laptop to Mullvad's and repeated the experiment it finally returned NXDOMAIN. Then I disconnected from the VPN but left Mullvad's DNS settings, repeated the experiment again with the same results - even when I was using a totally bogus DNS server it was returning the correct IP address.
That's when I installed Wireshark and, lo and behold, I could see the requests that should have been going to 1.1.1.1 or 5.9.3.7 going to 75.75.75.75. Comcast.
A call to Comcast was, as expected, a complete waste of time. First they told me it was using their DNS settings because of "their firewall" and then they told me that if I used their built-in router rather than mine + bridge mode I wouldn't have the issue at all.
Messing around in Wireshark I eventually determined the issue had something to do with one specific port that was making the requests (I can't recall how but I think because I could see Mullvad VPN was using a different port for DNS?) so I fiddled around and forced (or maybe redirected?) my router to use that port too and that finally worked in avoiding the Comcast servers. But, knowing just enough to be dangerous and not entirely sure what I was doing, I didn't keep the forced port and decided I'd have to get my own modem and use my VPN in the meantime.
Before I had gotten around to buying a new modem (this was somewhat early in the pandemic) I saw a post on HN about NextDNS and decided I'd see if I ran into the same issue. I didn't, as far as I could tell at least. When I run Wireshark now (I still use NextDNS) I don't see any contact with 75.75.75.75 or 75.75.76.76. I think this is because NextDNS uses DoH? But who knows.
Like I said, I only know enough to be dangerous so perhaps I just had something configured in an odd way that made the Comcast servers step in as a fail-safe and there's a totally innocent explanation. But based on my experience as a Comcast customer I don't really think they're deserving of the benefit of the doubt so I've definitely got a bit of a tin foil hat when it comes to them secretly messing around with my traffic through the leased modem.
Well that's vague. What are the symptoms? How would comcast even know that you changed DNS settings? It's possible to infer that from DNS queries to their servers dropping off and traffic to 1.1.1.1 or 8.8.4.4 increasing, but I doubt comcast is competent enough to build that sort of detection system.