Aggregator

A vulnerability was found in Mozilla Thunderbird up to 115.6. It has been rated as problematic. This issue affects some unknown processing of the component Devtool Extension Handler. The manipulation leads to improper privilege management. The identification of this vulnerability is CVE-2024-0751. The attack can only be initiated within the local network. There is no exploit available. It is recommended to upgrade the affected component.

A vulnerability classified as problematic has been found in Mozilla Firefox up to 115.6. Affected is an unknown function of the component HSTS Handler. The manipulation leads to information disclosure. This vulnerability is traded as CVE-2024-0753. It is possible to launch the attack remotely. There is no exploit available. It is recommended to upgrade the affected component.

A vulnerability classified as problematic was found in Mozilla Thunderbird up to 115.6. Affected by this vulnerability is an unknown functionality of the component HSTS Handler. The manipulation leads to information disclosure. This vulnerability is known as CVE-2024-0753. The attack can be launched remotely. There is no exploit available. It is recommended to upgrade the affected component.

A vulnerability has been found in Mozilla Thunderbird and classified as problematic. Affected by this vulnerability is an unknown functionality of the component Popup Notification Handler. The manipulation leads to clickjacking. This vulnerability is known as CVE-2024-0750. The attack can be launched remotely. There is no exploit available. It is recommended to upgrade the affected component.

一、漏洞概述

注:本文仅以安全研究为目的,分享对该漏洞的挖掘过程,文中涉及的所有漏洞均已报送给国家单位,请勿用做非法用途。

通达OA是国内常用的智能办公系统，为各行业不同规模的众多用户提供信息化管理能力，包括流程审批、行政办公、日常事务、数据统计分析、即时通讯、移动办公等，帮助广大用户降低沟通和管理成本，提升生产和决策效率。

其组件定时任务服务OfficeTask开放udp端口2397，未授权接收数据，并根据数据中的命令控制字符串，执行指定任务。导致存在未授权任意php文件执行、SQL注入漏洞。

二、影响范围

最新版通达OA 13.2（更新时间2025-02-14 13:39）

三、漏洞分析

使用的版本为官网最新版，通达OA（V13版）13.2。下载地址：

• 
  

https://www.tongda2000.com/download/p2024.php

安装好后，将创建通达定时任务服务Office_Task，并开机自启动。

通达定时任务服务OfficeTask.exe在0.0.0.0地址开放UDP端口2397，可以被外部直接访问。

OfficeTask.exe从2397端口接收到数据后，根据数据中的命令控制字符串，执行指定任务。命令控制字符串与命令参数以空格分隔，任务包括执行php文件，更新、备份数据库等。

四、前台RCE漏洞

其中命令字符串EXEC_HTTP_TASK_0表示执行指定php文件，命令参数为：php文件名和路径，可控。命令格式为：EXEC_HTTP_TASK_0  \..\poc.php。

最终将创建php.exe进程，将需要执行的php文件拼接上通达OA默认安装路径C:\MYOA\webroot\，一同作为参数传递给php.exe进程执行。具体执行的命令，还会保存到默认目录下的C:\MYOA\logs\Office_Task.log日志文件中。

由于是调用php.exe程序来执行，并不能像日志中看到的那样直接闭合双引号来实现任意命令执行，只能通过执行恶意的php脚本文件来RCE。

php.exe命令执行时通过-f参数传递待执行的php文件，但是这里并不限制文件后缀必须为php。所以可以通过下面的方式分成两步来达到RCE效果。

命令执行成功之后会在网站根目录生成一句话木马，文件路径为webshell /logon.php。

对于旧版本（V12.9及以前的版本）的通达OA需要把EXEC_HTTP_TASK_0替换为EXEC_HTTP_TASK。

五、前台SQL注入漏洞

其中FILE_SORT_UPD_3命令字符串将执行SQL语句update更新数据库表FILE_SORT的内容。

SQL语句中的SORT_ID值和更新的内容可控，未做任何过滤，存在SQL注入漏洞。

比如执行如下FILE_SORT_UPD_3命令：

再查看file_sort表，其中sort_id=1的SORT_NAME数据修改为2，这表明SQL注入已经成功。

通过上面的分析可以看出此漏洞属于update类型的SQL注入漏洞，只能进行盲注，并且不支持多语句。为了更好的利用此漏洞，作者直接给出可以利用此漏洞通过bool盲注获取数据库中管理员用户密码的exp脚本。

对于旧版本（V12.9及以前的版本）的通达OA需要把FILE_SORT_UPD_3替换为FILE_SORT_UPD。

六、参考链接

https://www.ddpoc.com/DVB-2025-8979.html
https://www.ddpoc.com/DVB-2025-8971.html

原文链接

HackerNews 编译，转载请注明出处： 多个凭证数据集曝光了史上最大规模的数据泄露事件之一，总计暴露了惊人的160亿条登录凭证。这些数据很可能源自各种信息窃取程序。 不必要地汇总敏感信息可能与主动窃取数据同样危险。例如，Cybernews研究团队发现了多个超大规模数据集，其中存储了数十亿条登录凭证。从社交媒体、企业平台到VPN和开发者门户，无一幸免。 自今年年初以来，我们的团队一直在密切监控网络活动。截至目前，他们已发现30个被暴露的数据集，每个数据集包含的记录从数千万条到超过35亿条不等。总体而言，研究人员揭露了难以想象的160亿条记录。 除一个数据集外，其他所有被暴露的数据集此前均未报告：今年5月下旬，《连线》杂志曾报道一名安全研究人员发现了一个包含1.84亿条记录的“神秘数据库”。但该数据库的规模在本团队发现的列表中勉强挤进前二十名。最令人担忧的是，研究人员声称每隔几周就会出现新的大规模数据集，这表明信息窃取恶意软件的传播程度远超想象。 研究人员表示：“这不仅仅是一次泄露——它是大规模利用的蓝图。超过160亿条登录记录的暴露，使网络犯罪分子现在能够以前所未有的规模获取个人凭证，这些凭证可用于账户接管、身份盗窃和高度针对性的网络钓鱼攻击。”他们补充道：“尤其令人担忧的是这些数据集的结构和时效性——它们并非回收利用的旧泄露数据。这是新鲜的、可直接用于攻击的大规模情报。” 唯一的一线希望是，所有这些数据集都只是短暂暴露：时间刚好足够研究人员发现它们，但不足以查明是谁在控制这些海量数据。大多数数据集是通过未采取安全措施的Elasticsearch实例或对象存储实例暂时可访问的。 数十亿条暴露的记录包含什么？ 研究人员称，泄露数据集中的大部分数据是窃取程序恶意软件（stealer malware）的详细信息、凭证填充（credential stuffing）数据集和重新打包的泄露数据的混合体。 无法有效比较不同数据集之间的数据，但可以肯定存在重复记录。换句话说，无法确切得知实际有多少人或账户被暴露。 然而，团队设法收集到的信息显示，大部分信息遵循清晰的结构：首先是URL，然后是登录详情和密码。大多数现代信息窃取程序——即窃取敏感信息的恶意软件——正是以这种方式收集数据。 泄露数据集中的信息几乎为任何能想到的在线服务敞开了大门，从苹果、Facebook和Google，到GitHub、Telegram以及各种政府服务。当160亿条记录摆在面前时，很难遗漏任何东西。 据研究人员称，如此规模的凭证泄露为钓鱼攻击、账户接管、勒索软件入侵和商业邮件诈骗（BEC）攻击提供了燃料。该团队表示：“新旧窃取程序日志的混合——通常包含令牌（tokens）、cookie和元数据——使得这些数据对缺乏多因素认证（MFA）或凭证管理措施的组织尤其危险。” 哪些数据集暴露了数十亿条凭证？ 团队发现的数据集差异很大。例如，最小的数据集以恶意软件命名，包含超过1600万条记录。而最大的一个数据集很可能与葡萄牙语人群相关，包含超过35亿条记录。平均而言，一个暴露凭证的数据集包含5.5亿条记录。 有些数据集命名泛泛，如“logins”（登录）、“credentials”（凭证）等类似术语，导致团队难以深入了解其内容。然而，另一些数据集的名称则暗示了它们关联的服务。 例如，一个包含超过4.55亿条记录的数据集，其名称表明其源于俄罗斯联邦。另一个包含超过6000万条记录的数据集则以Telegram命名，这是一个基于云的即时通讯平台。 该团队强调：“新旧窃取程序日志的混合——通常包含令牌、cookie和元数据——使得这些数据对缺乏多因素认证或凭证管理措施的组织尤其危险。” 虽然命名并非推断数据来源的最佳方式，但似乎部分信息与云服务、商业导向数据甚至加密文件有关。一些数据集的名称很可能指向用于收集数据的某种恶意软件。 目前尚不清楚谁拥有这些泄露的数据。虽然可能是安全研究人员为检查和监控数据泄露而汇编的数据集，但几乎可以肯定其中一些泄露的数据集归网络犯罪分子所有。网络犯罪分子钟爱大规模数据集，因为聚合的数据集能帮助他们扩大各种攻击的规模，例如身份盗窃、钓鱼诈骗和未经授权的访问。 即使成功率不足百分之一，也可能为攻击者打开通向数百万个人的大门，这些人可能被诱骗泄露更敏感的信息，例如金融账户。令人担忧的是，由于不清楚谁拥有这些暴露的数据集，用户能采取的防护措施影响甚微。 然而，基本的网络安全防护至关重要。强大且频繁更换的密码可能是账户安全与信息被盗之间的分水岭。用户还应检查其系统是否存在信息窃取程序，以避免数据落入攻击者之手。       消息来源： cybernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文  

Miami, June 18, 2025, CyberNewswire — Halo Security today announced that its attack surface management solution has been named a 2025 MSP Today Product of the Year Award winner by TMC, a leading global media company recognized for building communities … (more…)

The post News alert: Halo Security’s attack surface management platform wins MSP Today’s top award first appeared on The Last Watchdog.

The post News alert: Halo Security’s attack surface management platform wins MSP Today’s top award appeared first on Security Boulevard.

HackerNews 编译，转载请注明出处： 根据Barracuda与哥伦比亚大学、芝加哥大学研究人员合作进行的一项研究，目前有超过半数（51%）的恶意和垃圾邮件是使用AI工具生成的。 该研究团队分析了Barracuda在2022年2月至2025年4月期间检测到的垃圾邮件数据集。他们使用训练有素的检测器，自动识别恶意或未经请求的电子邮件是否由AI生成。 该过程发现，从2022年11月到2024年初，由AI生成的垃圾邮件比例呈稳步上升趋势。2022年11月，全球首个公开可用的大型语言模型（LLM）ChatGPT正式发布。 2024年3月，AI生成的诈骗邮件比例出现大幅激增。此后该比例出现波动，最终在2025年4月达到峰值51%。 哥伦比亚大学电气工程与计算机科学副教授阿萨夫·西顿（Asaf Cidon）在接受采访时表示，目前尚无法确定这一突然激增的明确原因。他解释道：“很难确切知道原因，但这可能由多种因素导致：例如，攻击者使用了新发布的AI模型，或者攻击者发送的垃圾邮件类型发生了变化，从而提高了AI生成邮件的比例。” 研究人员还观察到，在商业邮件诈骗（BEC）中，AI生成内容的使用比例增长要缓慢得多，在2025年4月仅占所有尝试的14%。这很可能是因为此类攻击（即冒充组织中特定高管要求电汇或金融交易）的精准性要求较高，而AI目前在这方面的效果可能还不够理想。 然而，西顿预计，随着AI技术的进步，它在BEC诈骗尝试中的使用比例将会上升。“特别是考虑到近期非常有效且廉价的语音克隆模型兴起，我们认为攻击者会将深度伪造语音融入BEC攻击中，以便更好地冒充特定人物，例如CEO。”他说道。 研究人员发现，攻击者使用AI主要有两个原因：规避邮件检测系统，以及让恶意信息对收件人显得更可信。 分析显示，与人工撰写的邮件相比，AI生成的邮件通常行文更正式、语法错误更少、语言复杂度更高。这使得它们更有可能绕过检测，并且在收件人看来显得更专业。研究人员在6月18日发布的报告中指出：“当攻击者的母语与其目标不同时，这点尤其有帮助。在Barracuda的数据集中，大多数收件人位于广泛使用英语的国家。” 研究人员还观察到攻击者使用AI测试不同的措辞变体，以找出哪些能更有效地绕过防御。他们表示，这个过程类似于传统营销中的A/B测试。 研究发现，在传达紧迫感方面，LLM生成的邮件与人工生成的邮件并无显著差异。紧迫感是网络钓鱼攻击中的常见策略，旨在迫使收件人快速做出情绪化反应。这表明，AI主要用于提高邮件的渗透率和可信度，而非促成策略的改变。       消息来源： infosecurity-magazine； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 网络安全研究人员发现了一场新的多阶段恶意软件活动，专门针对《我的世界》（Minecraft）玩家。该活动使用基于Java的恶意软件，并利用名为“Stargazers Ghost Network”的分发即服务（DaaS）平台进行传播。 Check Point公司的研究人员雅罗米尔·霍雷伊希（Jaromír Hořejší）和安东尼斯·特雷福斯（Antonis Terefos）在一份报告中指出：“这些攻击活动导致了一个针对《我的世界》玩家的多阶段攻击链。恶意软件假冒了名为Oringo和Taunahi的工具，这些是‘脚本和宏工具’（即作弊工具）。第一和第二阶段的恶意程序均使用Java开发，并且只能在目标主机上安装了《我的世界》运行环境时才能执行。” 攻击的最终目的是诱骗玩家从GitHub下载《我的世界》模组（mod），进而投放具有全面数据窃取能力的.NET信息窃取程序。该网络安全公司于2025年3月首次检测到此活动。 该活动的显著特点是利用了名为“Stargazers Ghost Network”的非法服务平台。该网络利用数千个GitHub帐户建立被污染的代码仓库（repository），这些仓库伪装成破解软件和游戏作弊工具。 特雷福斯表示，他们已标记了“大约500个GitHub仓库，包括被复刻（fork）或复制的仓库”，并补充说“我们还观察到大约70个帐户产生了700个点赞（star）”。 这些伪装成《我的世界》模组的恶意仓库，是感染这款热门视频游戏用户的渠道。它们会投放一个Java加载器（例如“Oringo-1.8.9.jar”），截至报告发布时，该加载器仍未被任何防病毒引擎检测到。 这些Java存档（JAR）文件实施了简单的反虚拟机（anti-VM）和反分析技术以规避检测。其主要目的是下载并运行另一个JAR文件，这是一个第二阶段窃取程序，当受害者启动游戏时，它会获取并执行一个.NET窃取程序作为最终有效载荷。 第二阶段组件是从一个IP地址（“147.45.79.104”）获取的，该地址以Base64编码格式存储在Pastebin上。这本质上将Pastebin工具变成了一个“死投解析器”（dead drop resolver）。 研究人员解释说：“若要将模组添加到《我的世界》游戏中，用户必须将恶意JAR文件复制到《我的世界》的模组文件夹（mods folder）中。启动游戏后，《我的世界》进程将加载该文件夹中的所有模组，包括恶意模组，该模组随后会下载并执行第二阶段程序。” 除了下载.NET窃取程序，第二阶段窃取程序还能窃取Discord和《我的世界》的令牌（token）以及Telegram相关数据。另一方面，.NET窃取程序则能够从各种网络浏览器中窃取凭证，并收集文件、加密货币钱包信息以及其他应用程序（如Steam和FileZilla）的数据。 它还可以截取屏幕截图，并收集有关正在运行的进程、系统的外部IP地址和剪贴板内容的信息。最终，捕获的信息会被打包，并通过Discord的Webhook传输回攻击者。 研究人员怀疑该活动是一个俄语威胁行为者的手笔，因为发现了多个俄语编写的文件残留，并且攻击者的代码提交时间戳显示为UTC+3时区。据估计，可能有超过1,500台设备成为该计划的受害者。 研究人员总结道：“此案例凸显了流行的游戏社区如何被利用为恶意软件分发的有效载体，强调了下载第三方内容时保持谨慎的重要性。Stargazers Ghost Network一直在积极分发这种恶意软件，目标是那些寻求模组来增强游戏体验的《我的世界》玩家。看似无害的下载，实则是基于Java的加载器，它们会部署另外两个窃取程序，能够窃取凭证和其他敏感数据。” KimJongRAT窃取程序新变种现身 与此同时，Palo Alto Networks公司Unit 42团队详细介绍了名为KimJongRAT的信息窃取程序的两个新变种。该恶意软件很可能与BabyShark和Stolen Pencil背后的朝鲜威胁行为者有关联。KimJongRAT早在2013年5月就已被检测到，在BabyShark攻击中作为次级载荷投放。 安全研究员多米尼克·赖歇尔（Dominik Reichel）表示：“一个新变种使用可移植可执行（PE）文件，另一个则使用PowerShell脚本实现。PE和PowerShell变种都是通过点击Windows快捷方式（LNK）文件触发的，该文件会从攻击者控制的内容分发网络（CDN）账户下载一个投放器（dropper）文件。” PE变种的投放器会部署一个加载器（loader）、一个诱饵PDF文件和一个文本文件；而PowerShell变种的投放器则部署一个诱饵PDF文件和一个ZIP压缩包。加载器接着会下载辅助载荷，包括KimJongRAT的窃取程序组件。 PowerShell变种投放器提供的ZIP压缩包中包含嵌入了基于PowerShell的KimJongRAT窃取程序和键盘记录器组件的脚本。 这两个新变种都能够收集并传输受害者信息、符合特定扩展名的文件以及浏览器数据（如凭证和加密货币钱包扩展的详细信息）。PE变种的KimJongRAT还被设计用于窃取FTP和电子邮件客户端信息。 Unit 42团队指出：“KimJongRAT的持续开发和部署，以及其不断变化的技术（例如使用合法的CDN服务器来伪装其分发），表明其构成明确且持续的威胁。这种适应性不仅展示了此类恶意软件带来的持久威胁，也突显了其开发者更新和扩展其功能的决心。”       消息来源： thehackernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

AI教父辛顿在2023年离开谷歌后，从AI乐观派转变为风险派，在最新播客访谈中深度阐述了对AI威胁的担忧。他认为AI发展已无法叫停，估计超级智能出现的概率在10%-20%之间，可能在10-20年内实现。辛顿详细分析了AI带来的两大类风险：人类滥用AI（网络攻击激增1200%、生物武器门槛降低、选举操纵、回音室效应加剧）和AI自主威胁（自主杀伤武器、大规模失业危机）。他指出数字智能在信息共享、学习效率和不朽性方面具有根本优势，当前AI系统可能已具备主观体验和情感。辛顿强调最大挑战是确保AI永远不想伤害人类，而非阻止其获得相关能力。他呼吁政府强制企业投入更多资源进行AI安全研究，并对自己毕生工作可能带来的潜在灾难性后果表达了深刻反思，认为监管总是滞后于技术发展，人类需要重新定义在AI时代的存在价值。

HackerNews 编译，转载请注明出处： 伊朗政府限制国内互联网访问，声称此举旨在阻止以色列开展秘密网络行动。此前以色列对伊朗发动前所未有攻击，加剧地区地缘政治紧张局势。 伊朗政府发言人法蒂梅·莫哈杰拉尼及网络警察部队FATA表示，网络降速是为“维护网络稳定性”，措施系“临时性、针对性且受控的网络防御行动”。网络监测机构NetBlocks数据显示，当地时间下午5：30左右出现“网络流量显著下降”。 此次断网发生在军事冲突升级背景下。自上周五起，以色列与伊朗持续进行导弹互袭，网络安全专家警告该冲突已蔓延至网络空间。伊朗政府已禁止官员使用手机等通信设备，并限制公众互联网访问，部分地区出现固话通信中断。伊朗国家电视台还呼吁民众卸载即时通讯软件WhatsApp，未提供任何证据地宣称该应用被以色列用于监控用户。WhatsApp母公司Meta否认指控，声明绝不追踪用户或向政府提供批量数据。 网络攻防呈现双向对抗特征： 亲以黑客精准打击：亲以色列组织“掠食麻雀”（Predatory Sparrow）本周宣称对伊朗赛帕银行（Bank Sepah）发动网络攻击，致其网站及ATM系统瘫痪。该组织公开声明指控该银行“规避国际制裁，挪用伊朗民众资金资助恐怖主义代理势力、弹道导弹计划及核武项目”，并称行动得到“勇敢伊朗人协助”，强调“服务于独裁者恐怖主义幻想的机构终将如此下场”。6月18日，该组织再度攻击伊朗最大加密货币交易所Nobitex，造成价值9000万美元数字资产被盗并永久锁定。区块链分析确认黑客通过特殊技术将资金转入嵌有反伊斯兰革命卫队信息的特定地址，实现彻底销毁。 伊朗网军全面反击：特拉维夫网络安全公司Radware监测发现，伊朗关联威胁组织在Telegram频道活跃度激增。包括“神秘孟加拉队”、“阿拉伯幽灵”在内的组织已威胁约旦、沙特等邻国，警告支持以色列将招致基础设施网络打击。其中“阿拉伯幽灵”宣称成功入侵以色列公共紧急警报系统，意图制造社会恐慌。 网络冲突持续升级之际，美国国务院宣布悬赏通缉使用IOCONTROL恶意软件攻击美以关键基础设施的伊朗黑客组织“Cyber Av3ngers”，指控其受雇于伊朗伊斯兰革命卫队网络电子司令部。 【事件最新进展】 6月18日，Nobitex交易所发布安全警报称，检测到“部分报告基础设施和热钱包遭未授权访问”后已暂停所有访问权限，承诺全额赔偿用户损失。区块链调查机构ZachXBT追踪发现，约8170万美元数字资产通过波场链（Tron）、以太坊虚拟机链（EVM）和比特币链（BTC）被盗，攻击者使用含反伊斯兰革命卫队辱骂信息的特定地址“TKFuckiRGCTerroristsNoBiTEXy2r7mNX”转移资金。       消息来源： thehackernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

好久没写文章了，开始今年的第一篇，顺便吐槽下，公众号这个排版真难用啊，话不多说，正文开始，今天主要来聊聊Co

Why endpoint secure DNS adoption matters

In a world where we have security options (this is 2025, after all), and yet we don’t bother accessing them, it’s like having vegetables and protein at the buffet but all we eat is the desert. No wonder we’re not doing as well as we could be doing! So, we think it’s time to check on our buffet of healthy options available when it comes to DNS encryption.

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 No support 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 - we want our cake and eat it too

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.

1 post - 1 participant

Read full topic

The post Endpoint adoption of Encrypted DNS appeared first on Security Boulevard.

pydantic-ai 通过将结构化输出巧妙地抽象为一种强制性的工具调用，并深度整合 Pydantic 的模式生成与验证能力，实现了一套极为可靠的 LLM 输出约束机制...