![如果 DNS 回复位于下一次尝试的中间,Linux 是否会接受配置的超时之后收到的 DNS 回复?](https://linux22.com/image/716206/%E5%A6%82%E6%9E%9C%20DNS%20%E5%9B%9E%E5%A4%8D%E4%BD%8D%E4%BA%8E%E4%B8%8B%E4%B8%80%E6%AC%A1%E5%B0%9D%E8%AF%95%E7%9A%84%E4%B8%AD%E9%97%B4%EF%BC%8CLinux%20%E6%98%AF%E5%90%A6%E4%BC%9A%E6%8E%A5%E5%8F%97%E9%85%8D%E7%BD%AE%E7%9A%84%E8%B6%85%E6%97%B6%E4%B9%8B%E5%90%8E%E6%94%B6%E5%88%B0%E7%9A%84%20DNS%20%E5%9B%9E%E5%A4%8D%EF%BC%9F.png)
/etc/resolv.conf
配置为:
options timeout:1 attempts:5 rotate
nameserver A
nameserver B
两个配置的名称服务器均有 3 秒的延迟。发生以下消息交换:
- 00:00 - 查询 #1 发送给 A
- 00:01 - 查询 #2 发送给 B
- 00:02 - 查询 #3 发送给 A
- 00:03 - 查询 #4 发送给 B
- 00:03 - A 回复 #1
Linux 解析器是否会接受对查询#1 的回复,因为它仍在解析地址,或者是否会丢弃超出初始 1 秒超时的所有回复?
不幸的是人 resolf.conf并没有真正澄清这一点。
答案1
DNS 查询也基于 RTT(往返时间),就像 ICMP 一样。DNS 查询的 RTT 是之间的延迟DNS 查询发布 和答案是已收到,这意味着回复(在您的例子中 - 从 A 收到的对 #1 的回复)必须在配置的最大超时之前到达,才能被视为有效。它与 ICMP 的工作方式非常相似。
从技术上讲,RTT 是发送信号所需的时间长度加上接收该信号确认所需的时间长度。
答案2
我已经在实验室中测试了这种行为。如果在 Linux 解析器仍在解析域名时收到成功回复,即使回复延迟超过 1 秒,它也会接受成功回复。在我的实验室中,我将 DNS 服务器延迟设置为 3 秒,并且设置了 {{options timeout:1 attempts:5}},客户端仍然解析了域名。数据包捕获证明,在客户端向两个配置的 DNS 服务器发出多个查询后,才收到回复。
将默认值或 {{options timeout:5 attempts:1}} 更改为 {{options timeout:5 attempts:1}} 从而减少 DNS 服务器故障转移延迟,同时仍允许慢速 DNS 服务器在相同时间内提供答案。