Yesterday I was running a DNS packet capture on
vr1 to look at something else, and noticed that Kiosk Pi (
192.168.1.100) seems to be generating quite a lot of DNS noise, looking up seemingly random strings under
.home
xrwbuzpvdieklvp.home
pwahmqcdwrise.home
zgyesfuw.home
lltaffmzm
The list changes over time. Aside from the being extremely unlikely names, it almost looks like it's trying to enumerate the zone
.home so I'm a bit worried/concerned as to what on there is doing this.
The steps I originally followed to build the Kiosk Pi can be found here -
https://www.bentasker.co.uk/documentation/linux/687-building-a-raspberry-pi-based-music-kiosk
Activity
2020-04-08 09:24:56
2020-04-08 13:59:22
ben@milleniumfalcon:~$ tshark -q -r kiosk-pi-dns-queries.pcap.gz -Y "dns" -T fields -e dns.qry.name | sort | uniq -c 6 htxjnwhttdbngzf.home 6 lltaffmzm 6 mjamlxqrre.home 6 pwahmqcdwrise 6 pwahmqcdwrise.home 6 vbsqraigywoouk 6 wsqmxgkzgnrto.home 6 xludgzupz 6 xrwbuzpvdieklvp 6 xrwbuzpvdieklvp.home 6 zgyesfuw 6 zgyesfuw.homeAll being queried against the LAN DNS server (i.e. the DNS server configured at OS level).
It's obviously querying the random string (say
2020-04-08 14:02:23
That's a very chrome heavy selection. We only really care about the IPv4 set for now though as the source was `192.168.1.100`. Looks like it is, almost certainly, Chrome then.
2020-04-08 14:03:44
There's also a quote in there from the chrome source code
There's a copy of the source here - https://chromium.googlesource.com/chromium/src/+/lkgr/chrome/browser/intranet_redirect_detector.cc#42
It does seem to imply that it only happens when Chrome is started or the box gets a new IP, but I seem to be seeing it more regularly than that. It's not even aligned with DHCP lease renewals, just seems to be constant
2020-04-08 14:04:49
It's not a massive demand on the DNS server, but I'd still prefer to turn it off if at all possible
There appears to be a pref for it though - https://source.chromium.org/chromium/chromium/src/+/master:chrome/common/pref_names.cc;drc=7bf6998a6433c26266180353473b5153ffab0517;l=1744?originalUrl=https:%2F%2Fcs.chromium.org%2F
// Boolean specifying that the intranet redirect detector should be enabled. // Defaults to true. const char kDNSInterceptionChecksEnabled[] = "browser.dns_interception_checks_enabled";2020-04-08 14:05:43
Search for references to it
No switch then
2020-04-08 14:07:56
Added the following at the beginning of the JSON
As it's a kiosk, rebooting's the easiest way to get the changes live
Checking port 53 usage
And running a capture on the DNS server to confirm
root@VR1:~# tcpdump -i any -v port 53 and host 192.168.1.100 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 12:44:40.806406 IP (tos 0x0, ttl 64, id 36311, offset 0, flags [DF], proto UDP (17), length 70) kioskpi1-wifi.60553 > vr1.domain: 18946+ A? subsonicser.bentasker.co.uk. (42) 12:44:40.806486 IP (tos 0x0, ttl 64, id 36312, offset 0, flags [DF], proto UDP (17), length 70) kioskpi1-wifi.60553 > vr1.domain: 20482+ AAAA? subsonicser.bentasker.co.uk. (42) 12:44:40.806644 IP (tos 0x0, ttl 64, id 2418, offset 0, flags [none], proto UDP (17), length 86) vr1.domain > kioskpi1-wifi.60553: 18946* 1/0/0 subsonicser.bentasker.co.uk. A 192.168.1.5 (58) 12:44:40.806747 IP (tos 0x0, ttl 64, id 2419, offset 0, flags [none], proto UDP (17), length 70) vr1.domain > kioskpi1-wifi.60553: 20482* 0/0/0 (42) ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernelPerfect.
2020-04-08 14:11:04
2020-04-08 14:13:30
2020-04-08 14:15:06
2020-04-08 14:15:06
2020-04-08 14:15:21
2020-04-08 14:15:28
2020-04-08 14:15:37
2020-04-08 14:16:09
2020-04-08 14:16:14
2020-04-08 14:16:14
2020-04-08 14:16:17
2020-05-02 09:29:47
The idea that it's only at network change is demonstrably false - one of the laptops has Chrome open and it's hitting DNS with these names every 15 seconds or so.
2020-09-07 11:58:59
The feature apparently now contributes to half the load on the root DNS servers (or, at the very least, on Verisign's), generating about 60 billion junk queries a day. There's also a write-up on the APNIC blog here: https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/
There's a Chromium bug open to disable the Intranet Redirect Detector by default - https://bugs.chromium.org/p/chromium/issues/detail?id=1090985 - and to have enterprises enable it (if they need it) using GPO.
<grumble>
This really is just another problem with the flawed idea that the Omnibox should be a one-stop shop. It's that combined with behaviour like this that causes privacy leaks (for example https://bugs.chromium.org/p/chromium/issues/detail?id=479620)
</grumble>