Lets optimize openwrt, https-dns-proxy, chrome, windows client (2)

chrome on win10/11 client, by default, uses https or plain tcp for dns. Which I consider overkill just for my LAN,
becuse using https-dns-proxy on my openwrt box. Assuming, dns-hijack works as expected.

https or tcp are slower, causing more load, compared to udp.
However, disabling DoH and dns-tcp on my win10 chrome is bit tricky.
First, to be done in chrome itself, to set chrome://settings/security-use-secure-dns to off.
Second, in windows registry; also disabling chromes internal dns client:
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v DnsOverHttpsMode /t REG_SZ /d "off" /f
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v BuiltInDnsClientEnabled /t REG_DWORD /d 0 /f

Result: very few tcp for dns
Apr 21 03:00:00 dnsmasq[23542]: child processes for TCP requests: in use 0, highest since last SIGUSR1 2, max allowed 30.

Normally browser should rely on OS resolver which is configured via DHCP. If you have DoH set up on your router then just make sure that Chrome has DoH desabled. In case of Firefox or Apple devices you can block canary domains (use-application-dns.net, mask.icloud.com, mask-h2.icloud.com) - browsers will configure themselves to OS resolver automatically.

chrome will still use internal dns-client, which falls back to tcp-dns, unless my reg mods used. what browser should do, and whats really doing, different stories. u r invited to confirm/reject my issue with https-dns-proxy.

Can't check it. I only have Linux and BSD at my hand. But I very much doubt that Chrome enforces TCP on DNS. DNS over TCP 53 is kinda a special case added many years ago for long replies which don't fit in one MTU.

Sorry, can not do anything about your doubt. BUT you might be able to have same effect on a LINUX client, in case no proper UDP port entropy. DNS over TCP is not a special case; AFAIK there is no MUST in the RFC, to force UDP for small requests. The scenario, you mentioned, is the good, old, traditional one. But since DNS-poisoning showed up, hardening DNS by using TCP is a simple method, to improve security. you will find docs about it, when goggling “chrome dns-client” .

For the sake of experiment I've downloaded Google Chrome and captured traffic while trying to open OpenWrt Forum:

14:54:13.045684 IP (tos 0x0, ttl 64, id 47952, offset 0, flags [none], proto UDP (17), length 74)
    asus.home.arpa.45932 > router.home.arpa.domain: 4802+ [1au] Type65? forum.openwrt.org. (46)
14:54:13.183229 IP (tos 0x0, ttl 64, id 61284, offset 0, flags [DF], proto UDP (17), length 141)
    router.home.arpa.domain > asus.home.arpa.45932: 4802 0/1/1 (113)
14:54:18.199390 IP (tos 0x0, ttl 64, id 53812, offset 0, flags [none], proto UDP (17), length 81)
    asus.home.arpa.42986 > router.home.arpa.domain: 46797+ [1au] Type65? translate.googleapis.com. (53)
14:54:18.199560 IP (tos 0x0, ttl 64, id 64018, offset 0, flags [none], proto UDP (17), length 81)
    asus.home.arpa.56414 > router.home.arpa.domain: 19911+ [1au] AAAA? translate.googleapis.com. (53)
14:54:18.199697 IP (tos 0x0, ttl 64, id 19008, offset 0, flags [none], proto UDP (17), length 81)
    asus.home.arpa.37406 > router.home.arpa.domain: 38492+ [1au] A? translate.googleapis.com. (53)
14:54:18.241106 IP (tos 0x0, ttl 64, id 61365, offset 0, flags [DF], proto UDP (17), length 109)
    router.home.arpa.domain > asus.home.arpa.56414: 19911 1/0/1 translate.googleapis.com. AAAA 2a00:1450:4010:c08::5f (81)
14:54:18.241106 IP (tos 0x0, ttl 64, id 61366, offset 0, flags [DF], proto UDP (17), length 138)
    router.home.arpa.domain > asus.home.arpa.42986: 46797 0/1/1 (110)
14:54:18.241725 IP (tos 0x0, ttl 64, id 61367, offset 0, flags [DF], proto UDP (17), length 97)
    router.home.arpa.domain > asus.home.arpa.37406: 38492 1/0/1 translate.googleapis.com. A 172.253.130.95 (69)
14:54:18.411223 IP (tos 0x0, ttl 64, id 39158, offset 0, flags [none], proto UDP (17), length 88)
    asus.home.arpa.50220 > router.home.arpa.domain: 58246+ [1au] Type65? content-autofill.googleapis.com. (60)
14:54:18.413190 IP (tos 0x0, ttl 64, id 8533, offset 0, flags [none], proto UDP (17), length 88)
    asus.home.arpa.41778 > router.home.arpa.domain: 53709+ [1au] AAAA? content-autofill.googleapis.com. (60)
14:54:18.413769 IP (tos 0x0, ttl 64, id 62097, offset 0, flags [none], proto UDP (17), length 88)
    asus.home.arpa.53971 > router.home.arpa.domain: 20981+ [1au] A? content-autofill.googleapis.com. (60)
14:54:18.443386 IP (tos 0x0, ttl 64, id 61387, offset 0, flags [DF], proto UDP (17), length 145)
    router.home.arpa.domain > asus.home.arpa.50220: 58246 0/1/1 (117)
14:54:18.446473 IP (tos 0x0, ttl 64, id 61388, offset 0, flags [DF], proto UDP (17), length 344)
    router.home.arpa.domain > asus.home.arpa.53971: 20981 16/0/1 content-autofill.googleapis.com. A 108.177.14.95, content-autofill.googleapis.com. A 74.125.205.95, content-autofill.googleapis.com. A 142.251.1.95, content-autofill.googleapis.com. A 64.233.162.95, content-autofill.googleapis.com. A 64.233.163.95, content-autofill.googleapis.com. A 142.250.150.95, content-autofill.googleapis.com. A 173.194.222.95, content-autofill.googleapis.com. A 172.253.130.95, content-autofill.googleapis.com. A 209.85.233.95, content-autofill.googleapis.com. A 74.125.131.95, content-autofill.googleapis.com. A 173.194.221.95, content-autofill.googleapis.com. A 64.233.161.95, content-autofill.googleapis.com. A 173.194.220.95, content-autofill.googleapis.com. A 64.233.165.95, content-autofill.googleapis.com. A 172.253.152.95, content-autofill.googleapis.com. A 64.233.164.95 (316)
14:54:18.450179 IP (tos 0x0, ttl 64, id 61389, offset 0, flags [DF], proto UDP (17), length 200)
    router.home.arpa.domain > asus.home.arpa.41778: 53709 4/0/1 content-autofill.googleapis.com. AAAA 2a00:1450:4010:c0b::5f, content-autofill.googleapis.com. AAAA 2a00:1450:4010:c0a::5f, content-autofill.googleapis.com. AAAA 2a00:1450:4010:c03::5f, content-autofill.googleapis.com. AAAA 2a00:1450:4010:c1e::5f (172)
14:54:19.910231 IP (tos 0x0, ttl 64, id 27214, offset 0, flags [none], proto UDP (17), length 84)
    asus.home.arpa.54659 > router.home.arpa.domain: 668+ [1au] Type65? safebrowsing.googleapis.com. (56)
14:54:19.910427 IP (tos 0x0, ttl 64, id 25978, offset 0, flags [none], proto UDP (17), length 84)
    asus.home.arpa.49177 > router.home.arpa.domain: 12396+ [1au] AAAA? safebrowsing.googleapis.com. (56)
14:54:19.910559 IP (tos 0x0, ttl 64, id 24742, offset 0, flags [none], proto UDP (17), length 84)
    asus.home.arpa.46524 > router.home.arpa.domain: 61629+ [1au] A? safebrowsing.googleapis.com. (56)
14:54:19.942090 IP (tos 0x0, ttl 64, id 61513, offset 0, flags [DF], proto UDP (17), length 112)
    router.home.arpa.domain > asus.home.arpa.49177: 12396 1/0/1 safebrowsing.googleapis.com. AAAA 2a00:1450:4010:c1c::5f (84)
14:54:19.944581 IP (tos 0x0, ttl 64, id 61514, offset 0, flags [DF], proto UDP (17), length 100)
    router.home.arpa.domain > asus.home.arpa.46524: 61629 1/0/1 safebrowsing.googleapis.com. A 74.125.131.95 (72)
14:54:19.945891 IP (tos 0x0, ttl 64, id 61515, offset 0, flags [DF], proto UDP (17), length 141)
    router.home.arpa.domain > asus.home.arpa.54659: 668 0/1/1 (113)

Do you see TCP requests? Or DoH? All default settings.

It is the opposite. DNS defaults to UDP port 53. And there is an RFC how to switch to TCP port 53. Do you want to see my statistics DNS UDP vs DNS TCP? It's about 1% for TCP. It has been like that for as long as I can remember. And I remember how it worked more than 25 years ago.

Try resetting your Chrome settings or just check settings. I'm just too lazy to do that. Probably they enable DoH by default in some countries.

As I wrote already, in case you have “sufficient” entropy in the UDP ports used for query, UDP will be used by chrome. This is NOT the case on a win10/11 client, for example. Did you have win10/11 as client when doing your tcpdump ?This is, what I am writing about, as I have stated explicitly. Otherwise, chrome switches the internal dns-client to use tcp.

Here is one first hint:

To make dns poisoning more difficult, I suspect. On LINUX, AFAIK, it is even a kernel par to enable real randomizing of UDP port usage. Win10/11 obviously does not do that. Yes, in my chrome install on win10, DoH is default.

DoH is enabled by default on Google Chrome version 83 or later

Addendum, from RFC9210:

It updates [RFC1123],
   Section 6.1.3.2 to clarify that all DNS resolvers and recursive
   servers MUST support and service both TCP and UDP queries and also
   updates [RFC1536] to remove the misconception that TCP is only useful
   for zone transfers.

I'm also a Chrome for Linux user.

You can easily configure whether to use DoH in the menu, as well as select the upstream servers (“OS default, Google, Cloudflare, OpenDNS, custom,” etc.).

No weird hacks required.

Also, UDP is used 99% of the time.
Yes, TCP is slightly slower, but the difference is imperceptible to humans.

And I doubt that a few DNS requests would put any load on the server.

My DNS server is an A72 quad-core with 1.8 GHz
My gateway is an A72 quad-core with 2.2 GHz

They just chuckle at DNS requests...

I modified title of this post, not to irritate happy LINUX-clients users.

You told that Linux is vulnerable - I checked it. Simple as that. Have no idea about Windows. But I'm sure you can disable in-app DNS in it too.

a) Clearly not enabled in mine. I didn't spend a second trying to configure Chrome after test installation. Probably country-dependent.
b) DoH and DNS over TCP are two DIFFERENT things.

Disable DoH, use OS resolver and you're done and optimized. OpenWrt does some DNS caching. 100 entries by default, - which is not much but enough for personal use (since most cloud hostings use very short TTL). You can easily increase it to 1000 if you have more than 64 MB of RAM.