[__michaelg]

This is stupid clickbait title, and the article isn't even very precise. Yes, that whole fritz.box situation is known and bad. But the problem discussed here doesn't nearly apply to every situation. Specifically, the box's builtin resolver (which is still used by default by a lot of things) knows not to forward fritz.box requests to the outside. That is, `dig google.com.fritz.box` and everything else say NXDOMAIN when you're using the builtin DNS.

[mmcnl]

I am the author and happy to make any corrections. In Windows performing a lookup for google.com returns the address of the fritz.box domain name.

PS C:\Users\Marco> nslookup google.com

Server: UnKnown

Address: 192.168.0.200

Non-authoritative answer:

Name: google.com.fritz.box

Addresses: 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828

45.76.93.104

How is this not bad?

[tetha]

Ah, it was looking like that to me, thanks for confirming. Like, if I force dig to use some public DNS, I get the newly registered IPs but if I use my fritzbox as the DNS server, it gives me itself / NXDomains, except for hostnames configured on the local fritzbox.

That on top of the fact that my linuxes won't use the search domain unless explicitly asked for with a single-label DNS makes this a lot less scary.

[brewmarche]

Out of curiosity, what happens with a custom DNS server but still using DHCP? Will the suffix still be used?

[jmbwell]

Yeah but so many things bypass internal resolvers lately. VPNs, “private relay,” individual apps. DNS over HTTP. Local control over DNS is steadily being chipped away. The result is some apps will go out to public or vendor-controlled DNS in ways typical admin tools like ping and dig might not reveal