DNS的报文格式。其中，事务 ID、标志、问题计数、回答资源记录数、权威名称服务器计数、附加资源记录数这6个字段是DNS的报文首部，共12个字节。整个DNS报文格式主要分为3部分内容，即基础结构部分、问题部分、资源记录部分。

事务ID：DNS 报文的 ID 标识。对于请求报文和其对应的应答报文，该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。

标志Flags：DNS 报文中的标志字段。

问题计数：DNS 查询请求的数目。

回答资源记录数：DNS 响应的数目。

权威名称服务器计数：权威名称服务器的数目。

附加资源记录数：额外的记录数目（权威名称服务器对应 IP 地址的数目）。

同时根据现有抓包信息：

解析异常时间点，ipv4和ipv6 dns请求报文的事务ID一致，且先回复了ipv6的结果，同时状态为“拒绝”即reply code为5。

所以此处怀疑事务ID冲突是导致解析异常的直接原因，怀疑底层存在事务ID初始化非原子性的情况。

后续验证及代码分析

为排除应用层代码逻辑的影响,编写对应测试程序调用InteAddress.getAllByName()解析存储端域名，经过4天测试复现问题。

对应复现的抓包信息：

关于DNS报文头部的初始化逻辑在底层glibc的reslov相关基础库中。初始化代码如下：

对比glibc-2.17和glibc-2.28版本此处算法及初始化逻辑并无变化。随后追溯2.17及之后相关小版本的补丁，确认Redhat7.9中遇到相关并行DNS请求ID冲突的问题，导致解析超时或失败的情况，详见https://bugzilla.redhat.com/show_bug.cgi?id=2065058。

    该补丁修复并不是针对并行初始化ID时原子锁缺失的场景，而是增加相关逻辑处理ID重复且可能有效的DNS响应报文。

相关补丁代码如下：

分析结论

并行DNS请求时可能存在事务ID一致的情况，原始glibc相关函数(res_send）只会处理第一个响应报文，忽略第二个报文，可能导致真实的解析结果丢失，最终解析超时或者失败。

高版本glibc-2.17-326通过增加相关逻辑处理同ID的第二个响应报文，修复该问题。

升级方案

中标麒麟操作系统v7.6当前最新版本为glibc-2.17-326.el7.ns7.02,该版本除修复了dns解析相关问题，同时优化解决timezone以及GB18030字符集的问题，所有补丁和红帽7系列对齐，经过严格测试后入库，升级不会影响当前系统稳定性。

具体升级方案：

rpm -Uvh glibc*.rpm nscd*.rpm

升级完成后需重启系统。

以下为测试环境升级结果：