Why endpoint secure DNS adoption matters
We are in a world where we have security options; this is 2025, after all. And yet, we don’t bother using them. It’s like the malnourished teenager desperately in need for healthy food that keeps defaulting to the drivethru. No wonder we’re not doing as well as we could be doing! So, we think it’s time to reconsider what we’ve always done in exchange for a better tomorrow.
Last-mile DNS Encryption and how we got here
This has been a long time coming. Many critical protocols have started out as a sketch on the back of a napkin, only to be adopted for their simplicity and immediate functionality. At some point later on, the protocol is then optimized and only after it is abused, does it finally get secured. Not surprisingly, that is the story with last-mile DNS encryption as well. It is such a broad attack vector that it’s time to address this weakness.
Encrypted DNS Server support
The DNS is the ultimate client-server application environment. Naturally, the server must offer support before client endpoints could make use of it. All things considered, server-side adoption has occurred over the past few years at a decent pace to the point where most DNS server products, including public resolvers, support DoH and DoT standards.
Endpoint OS support
It goes without saying that it will take some time before we reach critical mass on endpoint DNS encryption adoption simply because the lifecycle of endpoints can be measured in months, years or even decades. The effort in this blog article is to see where we are with the largest market share of endpoint operating systems, running the latest version of iOS, Android and Windows. Here is the TL;DR:
| iOS 18.5 | Android 15 | Windows 11 (OS Build 27871) | |
|---|---|---|---|
| DDR | Verified only (no support for opportunistic discovery) | No support | More info needed |
| DNR DHCP Encrypted DNS Option | No support | No support | Yes* |
| Proprietary Upgrade | n/a | Yes** | n/a |
*This isn’t a default feature yet, but requires a registry entry, see below
**Android just attempts to use DNS-over-TLS immediately upon receiving a DHCP-assigned DNS option (6).
Testing environment and methodology
Our effort essentially is to use the latest available Operating System on our core product offering with DDR opportunistic support as well as DNR:
Setup with adam:ONE
- Dashboard → Manage Network → Advanced → Encryption → Enable internal DNS encryption
- Validate the DoH and DoT offers with a standard DDR query:
protectedendpoint: dig SVCB _dns.resolver.arpa
; <<>> DiG 9.20.6 <<>> SVCB @192.168.1.1 _dns.resolver.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44620
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa. IN SVCB
;; ANSWER SECTION:
_dns.resolver.arpa. 60 IN SVCB 1 280test-xkboiopjp0.2my.network. alpn="h2" port=443 ipv4hint=192.168.1.1 key7="/dns-query{?dns}"
_dns.resolver.arpa. 60 IN SVCB 2 280test-xkboiopjp0.2my.network. alpn="dot" port=853 ipv4hint=192.168.1.1
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Jun 18 20:03:26 EDT 2025
;; MSG SIZE rcvd: 172
- DNS setup via Kea DHCP Server with the following custom JSON configuration on this LAN segment:
{
"option-data": [
{
"name": "v4-dnr",
"data": "1, 280test-xkboiopjp0.2my.network., 192.168.1.1, alpn=h2 dohpath=/dns-query{?dns} port=443"
}
]
}
Setup and result on Windows:
Windows 11 requires an administrator cmd regedit like this, thanks to this blog article for the hints:
reg add HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters /v EnableDnr /t REG_DWORD /d 1
Upon restart, the very first query came via DoH as the server-side log shows with [DoH] for each entry that came in over DoH:
I 18/6 12:59:07.625203 40107 DNS? 192.168.1.102@49670 TCP4 www.msftconnecttest.com A | [DoH]
I 18/6 12:59:08.797999 40107 DNS? 192.168.1.102@49676 TCP4 mobile.events.data.microsoft.com A | [DoH]
I 18/6 12:59:08.801119 40107 DNS? 192.168.1.102@49676 TCP4 client.wns.windows.com A | [DoH]
I 18/6 12:59:09.909035 40107 DNS? 192.168.1.102@49676 TCP4 -keyid-46027e9f5683eff2b6745379a63b00ab0b637d10.microsoftaik.azure.net A | [DoH]
I 18/6 12:59:11.367439 40107 DNS? 192.168.1.102@49676 TCP4 login.live.com A | [DoH]
I 18/6 12:59:11.380371 40107 DNS? 192.168.1.102@56568 UDP4 config.edge.skype.com A | [DNS]
I 18/6 12:59:11.380563 40107 DNS? 192.168.1.102@60653 UDP4 config.edge.skype.com HTTPS | [DNS]
I 18/6 12:59:11.522564 40107 DNS? 192.168.1.102@49676 TCP4 officeclient.microsoft.com A | [DoH]
I 18/6 12:59:11.795422 40107 DNS? 192.168.1.102@49676 TCP4 fd.api.iris.microsoft.com A | [DoH]
I 18/6 12:59:11.819713 40107 DNS? 192.168.1.102@49676 TCP4 www.msn.com A | [DoH]
I 18/6 12:59:11.830938 40107 DNS? 192.168.1.102@49676 TCP4 odc.officeapps.live.com A | [DoH]
I 18/6 12:59:11.992085 40107 DNS? 192.168.1.102@49676 TCP4 ocsp.digicert.com A | [DoH]
I 18/6 12:59:12.044973 40107 DNS? 192.168.1.102@49676 TCP4 -keyid-46027e9f5683eff2b6745379a63b00ab0b637d10.microsoftaik.azure.net A | [DoH]
I 18/6 12:59:12.095170 40107 DNS? 192.168.1.102@49676 TCP4 arc.msn.com A | [DoH]
I 18/6 12:59:12.236387 40107 DNS? 192.168.1.102@49676 TCP4 v20.events.data.microsoft.com A | [DoH]
I 18/6 12:59:12.357970 40107 DNS? 192.168.1.102@49676 TCP4 sdx.microsoft.com A | [DoH]
I 18/6 12:59:12.361815 40107 DNS? 192.168.1.102@49676 TCP4 assets.msn.com A | [DoH]
I 18/6 12:59:12.466024 40107 DNS? 192.168.1.102@49676 TCP4 nav.smartscreen.microsoft.com A | [DoH]
I 18/6 12:59:12.721586 40107 DNS? 192.168.1.102@49676 TCP4 data-edge.smartscreen.microsoft.com A | [DoH]
I 18/6 12:59:13.499324 40107 DNS? 192.168.1.102@49676 TCP4 web.vortex.data.microsoft.com A | [DoH]
I 18/6 12:59:13.552460 40107 DNS? 192.168.1.102@49676 TCP4 oloobe.officeapps.live.com A | [DoH]
I 18/6 12:59:14.030990 40107 DNS? 192.168.1.102@49676 TCP4 cdnjs.cloudflare.com A | [DoH]
I 18/6 12:59:14.034126 40107 DNS? 192.168.1.102@49676 TCP4 content.lifecycle.office.net A | [DoH]
I 18/6 12:59:14.183873 40107 DNS? 192.168.1.102@49676 TCP4 c.pki.goog A | [DoH]
I 18/6 12:59:14.899057 40107 DNS? 192.168.1.102@49676 TCP4 browser.pipe.aria.microsoft.com A | [DoH]
I 18/6 12:59:15.060458 40107 DNS? 192.168.1.102@60416 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:15.060655 40107 DNS? 192.168.1.102@59254 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:15.068097 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:15.068793 40107 DNS? 192.168.1.102@50578 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:15.068888 40107 DNS? 192.168.1.102@50410 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:15.080342 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:15.081047 40107 DNS? 192.168.1.102@64168 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:15.081146 40107 DNS? 192.168.1.102@57723 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:15.096385 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:15.402697 40107 DNS? 192.168.1.102@61377 UDP4 searchapp.bundleassets.example A | [DNS]
I 18/6 12:59:15.402845 40107 DNS? 192.168.1.102@52294 UDP4 searchapp.bundleassets.example HTTPS | [DNS]
I 18/6 12:59:15.406621 40107 DNS? 192.168.1.102@62267 UDP4 searchapp.bundleassets.example HTTPS | [DNS]
I 18/6 12:59:15.406720 40107 DNS? 192.168.1.102@54613 UDP4 searchapp.bundleassets.example A | [DNS]
I 18/6 12:59:15.410512 40107 DNS? 192.168.1.102@49676 TCP4 searchapp.bundleassets.example A | [DoH]
I 18/6 12:59:15.935672 40107 DNS? 192.168.1.102@53280 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:15.935940 40107 DNS? 192.168.1.102@57009 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:15.953100 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:15.953972 40107 DNS? 192.168.1.102@51615 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:15.954168 40107 DNS? 192.168.1.102@56535 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:15.969144 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:16.235461 40107 DNS? 192.168.1.102@63650 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:16.235671 40107 DNS? 192.168.1.102@52874 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:16.256281 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:16.257040 40107 DNS? 192.168.1.102@51858 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:16.257160 40107 DNS? 192.168.1.102@62638 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:16.272239 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:17.186769 40107 DNS? 192.168.1.102@49676 TCP4 nf.smartscreen.microsoft.com A | [DoH]
I 18/6 12:59:18.459635 40107 DNS? 192.168.1.102@49676 TCP4 th.bing.com A | [DoH]
I 18/6 12:59:18.459869 40107 DNS? 192.168.1.102@49676 TCP4 img-s-msn-com.akamaized.net A | [DoH]
I 18/6 12:59:18.460063 40107 DNS? 192.168.1.102@49676 TCP4 assets.msn.com A | [DoH]
I 18/6 12:59:18.645218 40107 DNS? 192.168.1.102@49676 TCP4 ocsp.digicert.com A | [DoH]
I 18/6 12:59:20.938553 40107 DNS? 192.168.1.102@64062 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:20.938723 40107 DNS? 192.168.1.102@52576 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:20.952151 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:20.952799 40107 DNS? 192.168.1.102@57697 UDP4 www.bing.com A | [DNS]
I 18/6 12:59:20.952897 40107 DNS? 192.168.1.102@49593 UDP4 www.bing.com HTTPS | [DNS]
I 18/6 12:59:20.967727 40107 DNS? 192.168.1.102@49676 TCP4 www.bing.com A | [DoH]
I 18/6 12:59:21.534849 40107 DNS? 192.168.1.102@49676 TCP4 self.events.data.microsoft.com A | [DoH]
I 18/6 12:59:25.949726 40107 DNS? 192.168.1.102@55461 UDP4 www.bing.com A | [DNS]
Interesting observations of DNS queries coming from Windows when DNR is enabled
- The very first connectivity test is over DoH
- Many other queries still use legacy DNS (labeled as
[DNS]at the end of each query
Setup and result on Android:
Our Android test device is a Samsung Knox phone with the latest update including Android 15. It completely ignores the DNR option, never makes a DDR query but immediately assumes DoT availability on DHCP Option 6 as can be seen in the queries for the first number of seconds on bootup:
I 18/6 12:45:04.130833 40107 DNS? 192.168.1.104@34412 TCP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DoT]
I 18/6 12:45:04.170452 40107 DNS? 192.168.1.104@23171 UDP4 www.google.com A | [DNS]
I 18/6 12:45:04.177893 40107 DNS? 192.168.1.104@23171 UDP4 www.google.com A | [DNS]
I 18/6 12:45:04.177948 40107 DNS? 192.168.1.104@34412 TCP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DoT]
I 18/6 12:45:04.181311 40107 DNS? 192.168.1.104@45450 UDP4 yhqakv-dnsotls-ds.metric.gstatic.com AAAA | [DNS]
I 18/6 12:45:04.192875 40107 DNS? 192.168.1.104@19031 UDP4 connectivitycheck.gstatic.com A | [DNS]
I 18/6 12:45:04.200337 40107 DNS? 192.168.1.104@19031 UDP4 connectivitycheck.gstatic.com A | [DNS]
I 18/6 12:45:04.209486 40107 DNS? 192.168.1.104@1924 UDP4 www.google.com A | [DNS]
I 18/6 12:45:04.212849 40107 DNS? 192.168.1.104@1924 UDP4 www.google.com A | [DNS]
I 18/6 12:45:04.259635 40107 DNS? 192.168.1.104@62826 UDP4 time.android.com A | [DNS]
I 18/6 12:45:04.262401 40107 DNS? 192.168.1.104@62826 UDP4 time.android.com A | [DNS]
I 18/6 12:45:04.376422 40107 DNS? 192.168.1.104@11264 UDP4 north-america.pool.ntp.org A | [DNS]
I 18/6 12:45:04.385530 40107 DNS? 192.168.1.104@11264 UDP4 north-america.pool.ntp.org A | [DNS]
I 18/6 12:45:04.396185 40107 DNS? 192.168.1.104@34420 TCP4 scs-use2.bixbyllm.com A | [DoT]
I 18/6 12:45:04.411160 40107 DNS? 192.168.1.104@24572 UDP4 2.android.pool.ntp.org A | [DNS]
I 18/6 12:45:04.413913 40107 DNS? 192.168.1.104@24572 UDP4 2.android.pool.ntp.org A | [DNS]
I 18/6 12:45:04.573249 40107 DNS? 192.168.1.104@44869 UDP4 connectivitycheck.gstatic.com A | [DNS]
I 18/6 12:45:04.603191 40107 DNS? 192.168.1.104@34420 TCP4 qcc.qualcomm.com A | [DoT]
I 18/6 12:45:04.699213 40107 DNS? 192.168.1.104@34420 TCP4 mtalk.google.com A | [DoT]
I 18/6 12:45:05.892239 40107 DNS? 192.168.1.104@41745 UDP4 connectivitycheck.gstatic.com AAAA | [DNS]
I 18/6 12:45:05.892538 40107 DNS? 192.168.1.104@39507 UDP4 www.google.com AAAA | [DNS]
I 18/6 12:45:05.892656 40107 DNS? 192.168.1.104@13190 UDP4 www.google.com A | [DNS]
I 18/6 12:45:06.226486 40107 DNS? 192.168.1.104@34420 TCP4 app-measurement.com A | [DoT]
I 18/6 12:45:06.287595 40107 DNS? 192.168.1.104@34420 TCP4 www.googleapis.com A | [DoT]
I 18/6 12:45:06.797100 40107 DNS? 192.168.1.104@34420 TCP4 api.account.samsung.com A | [DoT]
I 18/6 12:45:06.813581 40107 DNS? 192.168.1.104@34420 TCP4 2.android.pool.ntp.org A | [DoT]
I 18/6 12:45:06.884893 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.int08h.com A | [DoT]
I 18/6 12:45:07.123092 40107 DNS? 192.168.1.104@34420 TCP4 scs-use2.bixbyllm.com A | [DoT]
I 18/6 12:45:07.832489 40107 DNS? 192.168.1.104@34420 TCP4 us-auth2.samsungosp.com A | [DoT]
I 18/6 12:45:08.070911 40107 DNS? 192.168.1.104@34420 TCP4 voilatile-pa.googleapis.com A | [DoT]
I 18/6 12:45:08.472463 40107 DNS? 192.168.1.104@34420 TCP4 www.samsung.com A | [DoT]
I 18/6 12:45:08.527292 40107 DNS? 192.168.1.104@34420 TCP4 play.samsungcloud.com A | [DoT]
I 18/6 12:45:08.563534 40107 DNS? 192.168.1.104@55956 UDP4 www.google.com A | [DNS]
I 18/6 12:45:08.574401 40107 DNS? 192.168.1.104@34420 TCP4 remoteprovisioning.googleapis.com A | [DoT]
I 18/6 12:45:08.628146 40107 DNS? 192.168.1.104@34420 TCP4 pinning-02.secb2b.com A | [DoT]
I 18/6 12:45:08.680158 40107 DNS? 192.168.1.104@34420 TCP4 gmscompliance-pa.googleapis.com A | [DoT]
I 18/6 12:45:08.813855 40107 DNS? 192.168.1.104@34420 TCP4 connectivitycheck.gstatic.com A | [DoT]
I 18/6 12:45:08.816766 40107 DNS? 192.168.1.104@34420 TCP4 www.tizen.org A | [DoT]
I 18/6 12:45:09.019037 40107 DNS? 192.168.1.104@34420 TCP4 vas.samsungapps.com A | [DoT]
I 18/6 12:45:09.047106 40107 DNS? 192.168.1.104@34420 TCP4 firebaseremoteconfig.googleapis.com A | [DoT]
I 18/6 12:45:09.050303 40107 DNS? 192.168.1.104@36682 UDP4 www.google.com A | [DNS]
I 18/6 12:45:09.119191 40107 DNS? 192.168.1.104@50465 UDP4 216.58.202.4.in-addr.arpa PTR | [DNS]
I 18/6 12:45:09.121136 40107 DNS? 192.168.1.104@55885 UDP4 *google.com A | [DNS]
I 18/6 12:45:09.127663 40107 DNS? 192.168.1.104@37673 UDP4 www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com A | [DNS]
I 18/6 12:45:09.130458 40107 DNS? 192.168.1.104@44701 UDP4 GOOGLE.COM A | [DNS]
I 18/6 12:45:09.130650 40107 DNS? 192.168.1.104@44705 UDP4 google.com A | [DNS]
I 18/6 12:45:09.135176 40107 DNS? 192.168.1.104@36207 UDP4 google.com A | [DNS]
I 18/6 12:45:09.137538 40107 DNS? 192.168.1.104@38163 UDP4 google.com A | [DNS]
I 18/6 12:45:09.153497 40107 DNS? 192.168.1.104@34420 TCP4 www.craigslist.org A | [DoT]
I 18/6 12:45:09.158082 40107 DNS? 192.168.1.104@56577 UDP4 google.com A | [DNS]
I 18/6 12:45:09.173495 40107 DNS? 192.168.1.104@47085 UDP4 google.com A | [DNS]
I 18/6 12:45:09.277263 40107 DNS? 192.168.1.104@37715 UDP4 google.com.onion A | [DNS]
I 18/6 12:45:09.302229 40107 DNS? 192.168.1.104@33692 UDP4 google.com NS | [DNS]
I 18/6 12:45:09.307605 40107 DNS? 192.168.1.104@49151 UDP4 google.com A | [DNS]
I 18/6 12:45:09.316919 40107 DNS? 192.168.1.104@34420 TCP4 gsl.samsunggsl.com A | [DoT]
I 18/6 12:45:09.330382 40107 DNS? 192.168.1.104@43499 UDP4 google.com CNAME | [DNS]
I 18/6 12:45:09.341423 40107 DNS? 192.168.1.104@47015 UDP4 google.com SOA | [DNS]
I 18/6 12:45:09.343975 40107 DNS? 192.168.1.104@48022 UDP4 216.58.202.4.in-addr.arpa PTR | [DNS]
I 18/6 12:45:09.353547 40107 DNS? 192.168.1.104@41133 UDP4 google.com 13 | [DNS]
I 18/6 12:45:09.402174 40107 DNS? 192.168.1.104@60555 UDP4 google.com WKS | [DNS]
I 18/6 12:45:09.515895 40107 DNS? 192.168.1.104@52889 UDP4 google.com A | [DNS]
I 18/6 12:45:09.766511 40107 DNS? 192.168.1.104@34420 TCP4 time.google.com A | [DoT]
I 18/6 12:45:09.798048 40107 DNS? 192.168.1.104@34420 TCP4 clienttracing-pa.googleapis.com A | [DoT]
I 18/6 12:45:09.798405 40107 DNS? 192.168.1.104@34420 TCP4 www.google.com A | [DoT]
I 18/6 12:45:09.806167 40107 DNS? 192.168.1.104@34420 TCP4 discover-pa.googleapis.com A | [DoT]
I 18/6 12:45:09.914599 40107 DNS? 192.168.1.104@34420 TCP4 es11.samsung-sm-ds.com A | [DoT]
I 18/6 12:45:10.090984 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.cloudflare.com A | [DoT]
I 18/6 12:45:10.402509 40107 DNS? 192.168.1.104@34420 TCP4 safebrowsing.googleapis.com A | [DoT]
I 18/6 12:45:10.416315 40107 DNS? 192.168.1.104@34420 TCP4 policy.samsungcloud.com A | [DoT]
I 18/6 12:45:10.466249 40107 DNS? 192.168.1.104@34420 TCP4 time.xtracloud.net A | [DoT]
I 18/6 12:45:10.783074 40107 DNS? 192.168.1.104@34420 TCP4 capi.samsungcloud.com A | [DoT]
I 18/6 12:45:11.148622 40107 DNS? 192.168.1.104@34420 TCP4 lpa.live.esimdiscovery.com A | [DoT]
I 18/6 12:45:11.152048 40107 DNS? 192.168.1.104@34420 TCP4 us-gslu.samsunggsl.com A | [DoT]
I 18/6 12:45:11.402690 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn3.gstatic.com A | [DoT]
I 18/6 12:45:11.407567 40107 DNS? 192.168.1.104@34420 TCP4 ssl.gstatic.com A | [DoT]
I 18/6 12:45:11.407745 40107 DNS? 192.168.1.104@34420 TCP4 www.gstatic.com A | [DoT]
I 18/6 12:45:11.407897 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn0.gstatic.com A | [DoT]
I 18/6 12:45:11.489656 40107 DNS? 192.168.1.104@34420 TCP4 clients2.google.com A | [DoT]
I 18/6 12:45:11.641547 40107 DNS? 192.168.1.104@34420 TCP4 dvs.samsungmobile.com A | [DoT]
I 18/6 12:45:11.699535 40107 DNS? 192.168.1.104@34420 TCP4 accounts.google.com A | [DoT]
I 18/6 12:45:11.886269 40107 DNS? 192.168.1.104@34420 TCP4 sdk.pushmessage.samsung.com A | [DoT]
I 18/6 12:45:12.151010 40107 DNS? 192.168.1.104@38163 UDP4 google.com A | [DNS]
I 18/6 12:45:12.358996 40107 DNS? 192.168.1.104@34420 TCP4 encrypted-tbn2.gstatic.com A | [DoT]
I 18/6 12:45:12.362051 40107 DNS? 192.168.1.104@34420 TCP4 geller-pa.googleapis.com A | [DoT]
I 18/6 12:45:12.402978 40107 DNS? 192.168.1.104@60555 UDP4 google.com WKS | [DNS]
I 18/6 12:45:12.446012 40107 DNS? 192.168.1.104@34420 TCP4 notifications-ueeshp-pa.googleapis.com A | [DoT]
I 18/6 12:45:12.688201 40107 DNS? 192.168.1.104@34420 TCP4 ers.samsungcloud.com A | [DoT]
I 18/6 12:45:12.790038 40107 DNS? 192.168.1.104@34420 TCP4 android.clients.google.com A | [DoT]
I 18/6 12:45:12.859099 40107 DNS? 192.168.1.104@34420 TCP4 notifications-pa.googleapis.com A | [DoT]
I 18/6 12:45:13.022836 40107 DNS? 192.168.1.104@34420 TCP4 play-fe.googleapis.com A | [DoT]
I 18/6 12:45:13.081098 40107 DNS? 192.168.1.104@34420 TCP4 path2.xtracloud.net A | [DoT]
I 18/6 12:45:13.279382 40107 DNS? 192.168.1.104@34420 TCP4 play.googleapis.com A | [DoT]
I 18/6 12:45:13.507234 40107 DNS? 192.168.1.104@34420 TCP4 playstoregatewayadapter-pa.googleapis.com A | [DoT]
I 18/6 12:45:13.747891 40107 DNS? 192.168.1.104@34420 TCP4 prod-lt-playstoregatewayadapter-pa.googleapis.com A | [DoT]
I 18/6 12:45:13.986409 40107 DNS? 192.168.1.104@34420 TCP4 play-lh.googleusercontent.com A | [DoT]
I 18/6 12:45:14.227720 40107 DNS? 192.168.1.104@34420 TCP4 i.ytimg.com A | [DoT]
I 18/6 12:45:14.333421 40107 DNS? 192.168.1.104@34420 TCP4 api.weather.com A | [DoT]
I 18/6 12:45:14.736183 40107 DNS? 192.168.1.104@34420 TCP4 oneclient.sfx.ms A | [DoT]
I 18/6 12:45:14.761383 40107 DNS? 192.168.1.104@34420 TCP4 dcg.microsoft.com A | [DoT]
I 18/6 12:45:14.902781 40107 DNS? 192.168.1.104@34420 TCP4 default.exp-tas.com A | [DoT]
I 18/6 12:45:15.172440 40107 DNS? 192.168.1.104@34420 TCP4 ca-odc.samsungapps.com A | [DoT]
I 18/6 12:45:15.374939 40107 DNS? 192.168.1.104@34420 TCP4 roughtime.sandbox.google.com A | [DoT]
I 18/6 12:45:15.689301 40107 DNS? 192.168.1.104@34420 TCP4 storage.googleapis.com A | [DoT]
I 18/6 12:45:15.733188 40107 DNS? 192.168.1.104@34420 TCP4 update.googleapis.com A | [DoT]
I 18/6 12:45:16.031011 40107 DNS? 192.168.1.104@34420 TCP4 m.media-amazon.com A | [DoT]
I 18/6 12:45:16.673755 40107 DNS? 192.168.1.104@34420 TCP4 mobile.events.data.microsoft.com A | [DoT]
I 18/6 12:45:16.676291 40107 DNS? 192.168.1.104@34420 TCP4 scs-config-use2.bixbyllm.com A | [DoT]
I 18/6 12:45:17.503677 40107 DNS? 192.168.1.104@34420 TCP4 in.appcenter.ms A | [DoT]
Interesting observations on Android (as least on this Samsung device):
- The very first query came in over
[DoT]but similar to Windows, there are queries that are not encrypted - An invalid query is always made on startups for
*google.com - Another invalid query is always made for
www.goooooooooooooooooooooooooooooooooooooooooooooooooooooooooogle.com(which, incidentally is not managed by MarkMonitor as many most Google TLD registrations are, and I know I’m far from the first one to observe this)
Setup and result on iOS:
iOS 18.5 on any modern phone produces the same result… not the first query but always the second query executes DDR, but ignored as it does not support the opportunistic feature:
I 18/6 12:52:42.703787 40107 DNS? 192.168.1.105@64126 UDP4 46-courier.push.apple.com A | [DNS]
I 18/6 12:52:42.714170 40107 DNS? 192.168.1.105@54042 UDP4 _dns.resolver.arpa SVCB | [DNS]
I 18/6 12:52:42.718757 40107 DNS? 192.168.1.105@54086 UDP4 280test-xkboiopjp0.2my.network HTTPS | [DNS]
I 18/6 12:52:42.719385 40107 DNS? 192.168.1.105@49239 UDP4 280test-xkboiopjp0.2my.network A | [DNS]
I 18/6 12:52:42.734130 40107 DNS? 192.168.1.105@65534 UDP4 gsp85-ssl.ls.apple.com HTTPS | [DNS]
I 18/6 12:52:42.734293 40107 DNS? 192.168.1.105@57310 UDP4 gsp85-ssl.ls.apple.com A | [DNS]
I 18/6 12:52:42.879236 40107 DNS? 192.168.1.105@57260 UDP4 configuration.ls.apple.com A | [DNS]
I 18/6 12:52:42.879607 40107 DNS? 192.168.1.105@64697 UDP4 configuration.ls.apple.com HTTPS | [DNS]
I 18/6 12:52:42.882839 40107 DNS? 192.168.1.105@56279 UDP4 gsp85-ssl.ls2-apple.com.akadns.net HTTPS | [DNS]
I 18/6 12:52:42.883351 40107 DNS? 192.168.1.105@56222 UDP4 gsp85-ssl.ls2-apple.com.akadns.net A | [DNS]
I 18/6 12:52:43.055124 40107 DNS? 192.168.1.105@52498 UDP4 mask.icloud.com HTTPS | [DNS]
I 18/6 12:52:43.055247 40107 DNS? 192.168.1.105@49906 UDP4 mask.icloud.com A | [DNS]
I 18/6 12:52:43.059336 40107 DNS? 192.168.1.105@51823 UDP4 configuration.ls.v.aaplimg.com HTTPS | [DNS]
I 18/6 12:52:43.061545 40107 DNS? 192.168.1.105@50558 UDP4 mask-h2.icloud.com HTTPS | [DNS]
I 18/6 12:52:43.061599 40107 DNS? 192.168.1.105@51986 UDP4 mask-h2.icloud.com A | [DNS]
I 18/6 12:52:43.088667 40107 DNS? 192.168.1.105@58320 UDP4 configuration.ls.v.aaplimg.com A | [DNS]
I 18/6 12:52:43.766236 40107 DNS? 192.168.1.105@51121 UDP4 gsp-ssl.ls.apple.com HTTPS | [DNS]
I 18/6 12:52:43.766335 40107 DNS? 192.168.1.105@63807 UDP4 gsp-ssl.ls.apple.com A | [DNS]
I 18/6 12:52:43.766357 40107 DNS? 192.168.1.105@60702 UDP4 _dns.resolver.arpa SVCB | [DNS]
I 18/6 12:52:45.340823 40107 DNS? 192.168.1.105@53379 UDP4 captive.apple.com HTTPS | [DNS]
I 18/6 12:52:45.341879 40107 DNS? 192.168.1.105@54459 UDP4 captive.apple.com A | [DNS]
I 18/6 12:52:47.741795 40107 DNS? 192.168.1.105@51371 UDP4 gspe1-ssl.ls.apple.com HTTPS | [DNS]
I 18/6 12:52:47.741901 40107 DNS? 192.168.1.105@51999 UDP4 gspe1-ssl.ls.apple.com A | [DNS]
I 18/6 12:52:47.973044 40107 DNS? 192.168.1.105@64647 UDP4 captive.apple.com HTTPS | [DNS]
I 18/6 12:52:47.973906 40107 DNS? 192.168.1.105@55777 UDP4 captive.apple.com A | [DNS]
I 18/6 12:52:47.973942 40107 DNS? 192.168.1.105@57512 UDP4 gateway.icloud.com HTTPS | [DNS]
I 18/6 12:52:47.975315 40107 DNS? 192.168.1.105@49851 UDP4 gateway.icloud.com A | [DNS]
Observations on iOS:
- As stated above, DDR opportunistic mode is not supported, so iOS just stays on legacy Do53, cleartext, unencrypted
What about other OS platforms?
While other OS options such as vanilla Android, Chromebooks, Linux distributions, etc, are in use, I limited the report to what is represents 95% of the market usage today. Having said that, with my very simple one-shot test with the latest Ubuntu 24.04, I noticed it does not made a DDR request at all and ignores DNR, and makes not upgrade attempt unless I first added this to /etc/systemd/resolved.conf:
DNSOverTLS=opportunistic
As for DNR, it completely ignored the DHCP offer when using the same config as what Windows accepted above.
A note about Mobile Device Management
The three giant OS platforms all have MDM-enabled option for DoH:
- Windows with Intune/ZTDNS
- Samsung via Knox
- iOS with Enterprise apps enforcing a DoH URL for all DNS
The application of the above is only sometimes practical, hence a more local network or endpoint-centric option is necessary.
Call to action
Wouldn’t it be nice if we made it easy for the MSP and sysadmins of the world to just make DNS be as secure as possible, starting with today’s heterogeneous environment and simply start by supporting DDR opportunistically when DNR or MDM-pushed options aren’t available? Keep in mind that rfc1918 is still the most common network IP deployment in SMB and SME and even Corporate networks. Furthermore in many organizations, the DHCP team is separate and distinct from the DNS team. Let’s give them both a chance and reduce the friction to adopting better security.
Edit#1 2025-06-19: DDR on Windows should be possible - will update on confirmation