Is my isp playing games with dns?

Hardware Hub Networking
1

over the last little while ive been trying different dns hosts.
1111, 4444, 8888 and so on.

i settled eventually on 8888/4444 as spotify doesnt like 1111.
and all was fine for a few weeks.
then i started getting dns lookup error. to the point it was almost every page and the pages that did load took and age.
i switched to 1111 and thought, oh solved it.
but no a few weeks later the problem started again.
i went back to 8888/4444 and hey presto no problems.
till again dns just bawked a few months later.
i tried 1111 same still dns erroring.
then i remembered the previous time i reset, that i allowed windows to get dns automatically from the isp.
i flicked it over, applied it and then in under 30 seconds switched to 8888/4444 and the alt dns is working fine again.

4 months later (today) it happened again. this time i just allowed the auto dns and swapped it back.
dns problem solved.
it seems my isp is willing to allow me to use alt dns providers but wants me to use there’s at least 1s every few months. even if its just a quick dial home…
this kinda feels like a violation of privacy.

anyways this is just a heads up for anyone having dns issues while using alt dns providers.
it could be your isp :frowning:

1 Like
2

Well, it is their network… they get to own all the data you provide them…

At least they only hijack the DNS, and don’t inject ads/banners.
Well, I’ve not heard of it over here.

DNS hijacking is totally done.
And packet inspection.

1 Like
3

Very possible, try DNS over HTTPS or TLS if you can. All DNS goes over 853 instead of 53, and is much harder to play with

4 Likes
4

That sounds like a very strange coincidence to me. The mechanisms and time scales that you’re talking about here don’t make any sense from an ISP perspective. I’d be guessing that this is some issue inside your network, or on your windows client.

The next time you see this behaviour I’d suggest some more rigorous testing. Some ideas below:

  • Test using a dns tool directly - dig or nslookup pointing directly at the dns server
  • Test both UDP/53 and TCP/53 - dig can do this with “dig +tls”
  • Run your own DNS server (IP whitelisted), and test DNS requests to that. Use a tcpdump on both your gateway and the server to see what scenario you land in.
    • Request getting dropped.
    • Reply getting dropped.
    • Forged disconnect to client.
    • Forged reply to client.
  • Do some testing with MTR to get (a very approximate) idea of where it may be getting blocked:
    • mtr --tcp -P 53
    • mtr --udp -P 53
5 Likes
5

DNS over HTTPS =

or Pi-Hole

and

and

cloudflare dns and/or quad9…

1 Like