我刚刚在要安装在数据中心的服务器上安装了 CentOs 6.3,但无法使名称解析/curl 正常工作。
我知道这是因为它尝试使用 ipv6,因为ping google.com
可以工作,curl -4 google.com
可以工作,但不能curl google.com
。
我从接口中删除了 ipv6 地址,但没有任何改变。
这非常成问题,因为yum
目前大多数系统工具(例如)都无法进行名称解析。Firefox 等浏览器之所以能正常工作,是因为它们可能使用其他工具来进行名称解析,而不是 所使用的工具curl
。
我设法通过完全禁用 ipv6 来解决工作站上的问题,具体方法如下这个/ 中的硬编码名称解析/etc/hosts
。但由于我在这里配置的是稍后将安装在远程数据中心的服务器,因此我不想搞砸,了解正在发生的事情并正确修复它。此外,我将在更多服务器上面临同样的问题,因此我非常感谢你帮助我理解这个问题以及如何解决它。
如果需要的话,我很乐意提供更多信息来帮助了解正在发生的事情。
当前网络配置是一个小型企业网络,有一个 DNS 服务器(我们称之为A)很久以前配置过。
dig google.com
并且dig -4 google.com
都被拒绝了ADNS。但这对于我工作的工作站也是如此curl
(是的,它们都使用相同的ADNS 服务器)。事实上,这个故障服务器和我的工作站在 中都有多个名称服务器/etc/resolv.conf
,而第二个名称服务器对它们两个都运行良好,所以如果我删除A从我的resolv.conf
一切工作正常!
问候,
奥利维尔
答案1
我通过以下诊断过程解决了这个问题,该过程可以应用于处理名称解析问题和 ipv6
- 在出现此问题的机器上和同一网络上另一台没有此问题的机器上
dig google.com
进行测试。dig -4 google.com
- 如果四个命令(每台机器两个)失败,则意味着其中的第一个名称服务器
/etc/resolv.conf
未配置为 ipv6。将其删除并重新测试。
一个 cal 还可以用于digg @nameserver google.com
测试其他最终名称服务器,而/etc/resolv.conf
无需更改此文件。
答案2
我必须对此进行故障排除,似乎在 Centos 6.x 版(例如 5.8 及更早版本)之前,glibc DNS 解析器的默认行为是这样的。客户端向 DNS 服务器询问 IPv6 地址(AAAA 记录),而 DNS 服务器只有 IPv4 记录,它说 - 我没有它(NX)。然后客户端又重新请求了 5 次,得到了相同的答案,直到说 - 嘿服务器,给我 IPv4 地址。然后服务器提供了 A 记录,客户端很满意。在我的网络中,整个过程在 300 毫秒内完成,因此最终用户几乎察觉不到。
这在 Centos 6.x 中发生了变化,其中两个查询是并行进行的 - 同时查询 IPv6 和 IPv4 记录。如果您的 DNS 服务器对 IPv6 地址响应 NX(我没有),客户端将完全忽略对 A(IPv4)地址的有效响应,因为它晚了几分之一秒才到达。因此它再次查询 DNS 服务器(同时执行 IPv6 和 IPv4 查询)并最终陷入相同的情况。因此,在最终放弃之后,它开始通过在搜索中添加 DNS 搜索后缀来执行这些查询。
Centos 6.7 中已修复此问题,客户端等待第二个 IPv4 响应并欣然接受,这在我的网络中大约需要 15 毫秒。这可能是相关的 Redhat 票证 -https://bugzilla.redhat.com/show_bug.cgi?id=845218(如果对 AF_UNSPEC 的两个响应之一失败,则不会失败):
rpm -q --changelog glibc | sed -n '0,/2.12-1.132/p' | grep AF_UNSPEC
- Do not fail if one of the two responses to AF_UNSPEC fails (#845218).
现在,此票受到限制,因此这里是可能的上游补丁: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=16b293a7a6f65d8ff348a603d19e8fd4372fa3a9
有关详细信息,以下是受影响的服务器列表:
- Centos 5.8 - 正常运行(glibc-2.5-81)。正在执行 6 个 IPv6 查询,然后回退到 IPv4,最终成功
- Centos 6.0-不工作(glibc glibc-2.12-1.7.el6.x86_64)
- Centos 6.1 至 6.4 — 无法正常工作
- Centos 6.5-无法运行(版本 glibc-2.12-1.132.el6.x86_64)
- Centos 6.6 - 已修复(版本 glibc-2.12-1.149.el6.x86_64)
- Centos 6.7 - 已修复(版本 glibc-2.12-1.166.el6.x86_64)
- Centos 7.0 - 无法正常工作(glibc-2.17-55.el7)- 同时执行 IPv4 和 IPv6 查询,有效的 IPv4 响应首先出现,等待 NX 的 IPv6 响应并失败名称解析
- Centos 7.1 - 已修复(glibc-2.17-78.el7)- 同时执行 IPv4 和 IPv6 查询,首先收到有效的 IPv4 响应,然后收到 NX 的 IPv6 响应,名称解析成功转为 IPv4
SUSE Linux 比较:
- SLES 11.3 — 工作(仅进行 IPv4 查找)—(glibc-2.11.3-17.54.1)
- SLES 12.1-不工作(glibc-2.19-31.9.x86_64)
- SLES 12.2 - 正在运行(glibc-2.22-49.16.x86_64.rpm)。同时执行 IPv4 和 IPv6 查询,首先使用 NX 接收 IPv6 响应,但等待后续 IPv4 并使用该 IPv4。
- SLES 12.3 — [将于 2017 年 9 月发布](?glibc-2.22-51.6.x86_64.rpm?)
这inet4only/etc/resolv.conf 的选项从未实现,https://bugzilla.redhat.com/show_bug.cgi?id=1027452