Hickory-DNS中FQDN与非FQDN名称比较的版本差异解析

在DNS协议实现库Hickory-DNS的0.24到0.25版本升级过程中，一个重要的行为变更影响了域名名称的比较逻辑。这个变更主要涉及完全限定域名(FQDN)与非完全限定域名之间的匹配规则，对于依赖此类比较的应用程序可能产生兼容性问题。

核心变更分析

在DNS协议中，完全限定域名(FQDN)是指以点号(.)结尾的绝对域名形式（如"example.com."），而非完全限定域名则不带结尾点号（如"example.com"）。Hickory-DNS 0.25版本开始严格执行RFC标准，不再将这两种形式视为等价。

具体表现为：

• 0.24版本：允许FQDN与非FQDN名称直接匹配
• 0.25版本：要求名称格式完全一致才匹配

实际影响场景

在DNS代理/拦截类应用中，开发者通常会维护一个需要特殊处理的域名列表。当收到DNS查询时，会将查询名称与列表中的域名进行比较。在0.25版本后，如果列表存储的是非FQDN形式（如"example.com"），而查询名称是FQDN形式（如"example.com."），直接比较将返回不匹配。

最佳实践建议

1. 统一使用FQDN格式：由于DNS消息中总是使用FQDN格式，建议在应用程序内部也统一使用带点号的完全限定形式存储和比较域名。

2. 显式转换处理：在必须处理混合格式的场景下，可以：

   • 使用Name::from_str时显式添加结尾点号
   • 通过Name::is_fqdn()方法检查格式
   • 使用Name::to_lowercase()确保大小写一致

3. 版本迁移检查：升级到0.25+版本时，应全面检查所有域名比较逻辑，特别注意：

   • 静态域名列表的定义方式
   • 动态生成的域名比较
   • 缓存键的生成逻辑

技术背景延伸

这个变更反映了DNS协议实现趋向严格合规的发展方向。RFC 1034/1035明确规定：

• 解析器发出的查询名称应为FQDN
• 权威服务器应存储FQDN
• 非FQDN通常仅用于本地配置或用户输入

理解这一差异有助于开发者构建更健壮的DNS相关应用，避免因协议细节处理不当导致的边界问题。