DNS服务器响应和超时


17

我们的局域网遇到了令人沮丧的问题。周期性地,对我们的ISP名称服务器的DNS查询超时会导致5秒钟的延迟。即使我/etc/resolv.conf通过直接挖掘到我们的DNS服务器之一来绕过,我仍然会遇到问题。这是一个例子:

mv-m-dmouratis:~ dmourati$ time dig www.google.com @209.81.9.1 

; <<>> DiG 9.8.3-P1 <<>> www.google.com @209.81.9.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14473
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     174 IN  A   74.125.239.148
www.google.com.     174 IN  A   74.125.239.147
www.google.com.     174 IN  A   74.125.239.146
www.google.com.     174 IN  A   74.125.239.144
www.google.com.     174 IN  A   74.125.239.145

;; AUTHORITY SECTION:
google.com.     34512   IN  NS  ns2.google.com.
google.com.     34512   IN  NS  ns1.google.com.
google.com.     34512   IN  NS  ns3.google.com.
google.com.     34512   IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     212097  IN  A   216.239.34.10
ns3.google.com.     207312  IN  A   216.239.36.10
ns4.google.com.     212097  IN  A   216.239.38.10
ns1.google.com.     212096  IN  A   216.239.32.10

;; Query time: 8 msec
;; SERVER: 209.81.9.1#53(209.81.9.1)
;; WHEN: Fri Jul 26 14:44:25 2013
;; MSG SIZE  rcvd: 248


real    0m5.015s
user    0m0.004s
sys 0m0.002s

其他时间,查询会立即响应,例如不到20毫秒左右。我完成了数据包跟踪,发现了一些有趣的东西。DNS服务器正在响应,但客户端将忽略初始响应,然后发送第二个相同的查询,该查询将立即响应。

请参阅数据包跟踪。请注意查询使用相同的源端口(62076)。

问题:是什么原因导致第一个DNS查询失败?

更新

资源:

数据包跟踪:

http://www.cloudshark.org/captures/8b1c32d9d015

Dtruss(适用于Mac的strace):

https://gist.github.com/dmourati/6115180

Mountain Lion防火墙随机延迟了来自apple.stackexchange.com的DNS请求:

/apple/80678/mountain-lion-firewall-is-randomly-delaying-dns-requests

更新2

System Software Overview:

  System Version:   OS X 10.8.4 (12E55)
  Kernel Version:   Darwin 12.4.0
  Boot Volume:  Macintosh HD
  Boot Mode:    Normal
  Computer Name:    mv-m-dmouratis
  User Name:    Demetri Mouratis (dmourati)
  Secure Virtual Memory:    Enabled
  Time since boot:  43 minutes

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro10,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.7 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB

Firewall Settings:

  Mode: Limit incoming connections to specific services and applications
  Services:
  Apple Remote Desktop: Allow all connections
  Screen Sharing:   Allow all connections
  Applications:
  com.apple.java.VisualVM.launcher: Block all connections
  com.getdropbox.dropbox:   Allow all connections
  com.jetbrains.intellij.ce:    Allow all connections
  com.skype.skype:  Allow all connections
  com.yourcompany.Bitcoin-Qt:   Allow all connections
  org.m0k.transmission: Allow all connections
  org.python.python:    Allow all connections
  Firewall Logging: Yes
  Stealth Mode: No

dtruss输出看起来被截断了。我们从未见过将程序输出写入STDOUT的系统调用。
安德鲁B

您是否尝试过其他公共名称服务器,例如Google DNS。
vasco.debian 2013年

@ vasco.debian是的,行为相同。
dmourati 2013年

1
我看到的这两个请求-响应对之间的唯一区别是请求和响应之间的延迟。我也看不到网络上的任何问题。实验并检查延迟是否重要-尽管分析仪中显示了OS,但由于某些原因,操作系统可能会将某些udp软件包丢弃到应用程序中。毫无疑问,这不是网络或常规配置的问题,“挖掘”必须有效。网络堆栈调整可能有问题。检查网络的sysctl设置。就像这个rolande.wordpress.com/2010/12/30/…–
GioMac

1
您不说Mac上是否运行防火墙?
JustinP

Answers:


3

这似乎是Lion防火墙中的错误。在您的系统上启用了吗?

在此MacRumors线程(更新为Mountain Lion(10.8)之后的DNS问题)中,讨论了一种可能的解决方法:

尝试减小MTU大小。

系统偏好设置>网络> WiFi>高级>硬件>手动> MTU:自定义> 1300

为我工作。

您能否检查减小MTU的大小是否可以缓解您的问题?


更改防火墙设置使问题消除了。MTU无效。需要禁用防火墙,或“阻止所有传入连接”。
dmourati 2013年

将防火墙更改为任何一种设置都可以减少问题发生的频率,但不能完全消除问题。能够复制1/200左右。
dmourati 2013年

我认为在穿越Internet时,这种程度的丢包非常合理,尤其是在路由上拥塞的跳数时。请记住,DNS使用UDP,这不能保证数据报的传递。这正是DNS协议本身具有重试和内置超时机制的原因
。– Mels

1
顺便说一句,我知道我们不应该在这里发表“谢谢”评论,但您只是将我的声誉提高了六倍:)
Mels

0

我最近遇到了类似的问题,发现未将Cisco ASA防火墙配置为支持EDNS0,该规范允许DNS UDP数据包大于512字节。一旦我的fw管理员允许最多4096个字节,问题就解决了。这里的好信息:

http://www.petenetlive.com/KB/Article/0000312.htm


我认为这并不适用。即使具有权限和其他部分,此特定DNS查询的响应也远远低于512字节。
安德鲁B
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.