仅当使用 cURL 获取数据时 DNS 解析速度较慢

Question

我在本地有域“engine02.prod.qc.offercal.com” bind9。

我不认为这是 DNS 服务器或 TTL 问题，因为基准测试几乎总是这样（我使用每种方法尝试了 2 分钟）：

curl -o /dev/null http://engine02.prod.qc.offercal.com:49157/void

        time_namelookup:  0.150
           time_connect:  0.151
     time_starttransfer:  0.152
                        ----------
             time_total:  0.152

curl -o /dev/null http://192.168.100.10:49157/void # use IP directly

                  time_namelookup:  0.000
           time_connect:  0.002
     time_starttransfer:  0.003
                        ----------
             time_total:  0.003

time dig @192.168.100.4 engine02.prod.qc.offercal.com

        real 0m0.009s
        user 0m0.004s
        sys  0m0.004s

time host engine02.prod.qc.offercal.com

        engine02.prod.qc.offercal.com has address 192.168.100.10
        real    0m0.011s
        user    0m0.006s
        sys     0m0.004s

我的resolv.conf文件：

[root@gateway01 ~]# cat /etc/resolv.conf 
nameserver 192.168.100.4

我已经被这个问题困扰了一段时间，请帮忙：D

Answer 1

我最近在构建 updown.io 时遇到了这个问题并对其进行了一些调查（感谢@Dan 的命令strace）。这是我发现的：

\n\n

健康）状况

\n\n

就我而言，curl 有时需要 65 毫秒才能解决，有时需要 <5 毫秒。\n在短时间不活动（几分钟）后似乎需要 65 毫秒，而在重复调用后则需要 <5 毫秒。听起来绝对像是缓存和 TTL 问题。\n但我的记录有 86400 秒 TTL（1 天），并且它已经缓存在我的本地解析器上，并且挖掘总是花费 1 毫秒。

\n\n

措施

\n\n

所以我尝试运行curl来strace查看时间花在哪里，这就是我发现的（为了清楚起见，删除了一些细节）：

\n\n

05:57:52.303 connect(3) = 0\n05:57:52.303 sendmmsg(3, ["1\\26\\1\\0\\0\\1\\0\\0\\0\\0\\0\\0\\22jarthon-architecte\\3"..., "\\0253\\1\\0\\0\\1\\0\\0\\0\\0\\0\\0\\22jarthon-architecte\\3"...] , 2) = 2\n05:57:52.303 poll([{fd=3, events=POLLIN}], 1, 5000) = 1\n05:57:52.303 ioctl(3, FIONREAD, [56]) = 0\n05:57:52.303 recvfrom(3, "1\\26\\201\\200\\0\\1\\0\\1\\0\\0\\0\\0\\22jarthon-architecte\\3"...) = 56\n05:57:52.304 poll([{fd=3, events=POLLIN}], 1, 4999) = 1\n05:57:52.373 ioctl(3, FIONREAD, [96]) = 0\n05:57:52.373 recvfrom(3, "\\0253\\201\\200\\0\\1\\0\\0\\0\\1\\0\\0\\22jarthon-architecte\\3"...) = 96\n05:57:52.373 close(3) = 0\n

\n\n

这是 DNS 解析部分，我们在这里可以清楚地看到，发送了 2 条消息，很快就收到了一条响应，在 69 毫秒的延迟后收到了另一条响应。我认为第二个响应可能是 IPv6 查询（AAAA），所以我在 dig 中尝试了它：

\n\n

$ dig AAAA jarthon-architecte.com\n\n;; AUTHORITY SECTION:\njarthon-architecte.com. 180 IN  SOA ns0.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2008010120 43200 3600 1209600 180\n\n;; Query time: 86 msec\n;; SERVER: ::1#53(::1)\n

\n\n

好吧，显然没有答案，但是这个 SOA 记录有 180 秒的 TTL，这看起来非常像我的curl 测试中从 5 毫秒到 65 毫秒所花费的时间。

\n\n

解释

\n\n

当没有答案时，SOA 记录由您的 DNS 服务器返回，其中包含否定 TTL（您可以看到的行上的最后一个数字 180），这是允许任何解析器缓存否定响应的时间（没有记录）。因此，这意味着当您查询 AAAA 记录时，您必须至少每 3 分钟访问一次 DNS 服务器，以确保它仍然不存在。

\n\n

使固定

\n\n

\n

1. 添加 IPv6 \xe2\x98\xba

\n

2. 如果您正在管理 DNS，最简单的解决方法是增加此值，在我的例子中，我使用 DNSMadeEasy，我可以创建具有更高 TTL 值的自定义 SOA 记录并将其分配给我的域：http: // help.dnsmadeeasy.com/management-dns/records/soa-start-authority-record/。这将使curl 在大多数情况下解析得更快，回到我们正确缓存的A 记录上的性能水平。

\n

3. 如果您是制作卷曲但不管理 DNS 的人，则可能有一些方法可以在 DNS 解析器级别上优​​化这一点，方法是在获取实际值或类似内容的同时提供过时的否定响应，但我还没有\还没调查过。

\n

4. 如果您不关心 IPv6，您也可以使用curl命令行标志禁用它-4

\n

\n