搜索域与补全查询
当访问一个不含末尾点的短名字时，客户端会先把它与搜索域列表逐项拼接，形成完整域名后依次查询，全部失败才向用户报错。抓包中的形态很直观：同一个短名会在很短时间内出现多个带不同后缀的查询，每一次都占掉一次往返。因此搜索域配置过多会明显拖慢短名解析，而直接使用带末尾点的完整域名可以跳过补全过程。
基本信息
| 适用平台 | Linux、Windows、macOS 客户端；容器内受解析配置影响 |
|---|---|
| 观察点 | 同一短名对应多个带后缀的查询 |
| 关键差异 | 带末尾点表示绝对域名不补全，不带点可能触发搜索域拼接 |
| 配置来源 | 客户端的解析配置文件中的搜索域列表 |
典型使用场景
- 内网短名访问慢，确认是否为多次补全查询所致
- 容器环境解析异常，核对搜索域配置是否与其他环境冲突
- 区分「域名真的不存在」与「补全尝试都失败」两类失败
- 梳理内外网查询边界，避免内网短名被送到外部解析器
- 对比使用完整域名与短名的解析耗时差异
- 为容器编排中的解析配置优化提供依据
观察要点
观察要点
# db → db.corp.example（命中或 NXDOMAIN）
# 若继续尝试其他后缀则再发一次查询
dns.qry.name contains "corp.example" # 看补全后的名字
dns.flags.rcode == 3 # 补全失败的常见结果
# 以完整域名（带末尾点）请求可减少补全次数
# 容器内搜索域过多时短名解析会明显变慢观察项逐项读法
| 观察项 | 含义 | 异常信号 |
|---|---|---|
| 同类查询多次出现 | 搜索域逐项补全 | 后缀数量越多等待越长 |
| 补全后失败 | 该后缀下无记录 | 需确认是否走错了搜索域 |
| 查询发往外部解析器 | 内外查询边界不清 | 内网短名可能泄漏到外部 |
| 带末尾点的查询 | 绝对域名不补全 | 属正确用法，可作为优化手段 |
末尾点很关键：带点表示绝对域名、不做补全，不带点则可能触发搜索域拼接，两次解析走的路径可能完全不同。
容器环境里搜索域配置过长会显著拖慢短名解析，这是容器化后常见的解析性能问题来源之一。