curl项目中DNS解析端口显示错误的深度分析

问题背景

在curl项目中，最近发现了一个与DNS解析相关的显示问题。当curl执行DNS解析时，verbose模式下显示的端口号不正确，会显示本地端口而非远程端口。这个问题出现在8ded8e5f提交后，该提交移除了async结构体中的主机名和端口复制逻辑。

问题表现

在verbose模式下，当curl解析类似google.com这样的域名时，输出信息会显示错误的端口号0，而实际上应该显示目标端口443。具体输出如下：

* Host google.com:0 was resolved.
* IPv6: (none)
* IPv4: 142.250.176.206
*   Trying 142.250.176.206:443...

可以看到，解析阶段显示的端口号是0，而实际连接时使用的是443端口，这种不一致性会给调试带来困扰。

技术分析

问题的根源在于lib/hostasyn.c文件中，解析结果显示的端口号使用了错误的变量。在8ded8e5f提交后，代码从使用async结构体中的端口号改为使用连接结构体中的本地端口(localport)，而非远程端口(remote_port)。

这个问题与之前ares代码中的一个bug类似，当时通过使用remote_port而非localport修复了问题。然而，直接使用remote_port可能也存在隐患，因为不能保证conn->remote_port总是等于传递给Curl_resolv/Curl_resolv_timeout等函数的端口号。

潜在风险

更深入的分析发现，这个问题可能不仅限于端口显示错误。当通过中间服务器访问http://host:80/path时，curl可能会缓存错误的DNS条目：将host:80映射到中间服务器IP。这会导致后续直接访问http://host:80/path的请求失败。

解决方案讨论

针对这个问题，开发团队提出了几种可能的解决方案：

1. 恢复之前的做法，在async结构体中保留主机名和端口的副本
2. 直接使用remote_port，但需要考虑其可靠性
3. 对主机名显示也进行检查，确保data->conn->host.dispname总是等于传递给resolv的主机名

经过讨论，团队确认主机名显示是正确的，无论是直接请求还是通过中间服务器都能正确显示。因此，问题主要集中在端口号的显示上。

结论与建议

对于curl用户来说，如果发现DNS解析时显示的端口号与实际连接端口不一致，可以暂时忽略解析阶段的端口显示，关注实际连接时使用的端口。对于开发者来说，建议：

1. 在修复时确保端口号的显示与实际连接端口一致
2. 考虑中间服务器场景下的DNS缓存问题
3. 对相关代码进行更全面的测试，特别是涉及中间服务器和DNS缓存的场景

这个问题提醒我们，在修改网络库的核心功能时，需要考虑各种使用场景，特别是涉及中间服务器和DNS缓存的复杂情况。任何看似简单的修改都可能产生意想不到的副作用。