下面描述的问题我在几次实际工作中都碰到过，一直没有做一个比较明确的整理，昨天再次碰到的时候（在构建capistrano环境是用bundle 安装包的时候发现速度极其慢），查看到一个写的比较好的blog，于是想把他翻译成中文，share在这里。 版权归原博主所有。

options single-request-reopen     # 注意全部是小写字母

原因说明： RHEL5/CentOS5/Ubuntu 10.04等等linux下，dns的解析请求过程如下。

1  主机从一个随机的源端口，请求 DNS的AAAA 记录，

2  主机接受dns服务器返回AAAA记录，

3  主机从一个另一个随机的源端口，请求 DNS的A 记录，

3  主机dns 服务器返回A记录，

如果是RHEL6/CentOS6，交互过程有所不同，如图：

1 主机从一个随机的源端口，请求 DNS的A 记录，
2 主机从同一个源端口，请求 DNS的AAAA 记录，
3 主机接受dns服务器返回A记录，
4 主机接受 dns服务器返回AAAA记录，

上面3,4并没有严格的先后顺序，实际的顺序受网络环境，服务器环境的影响。

理论上讲centos6的这种工作机制，效率更高，端口复用度更高，能节省更多的资源。

但是这里也同样存在着一个问题。比如在存在防火墙等机制的网络环境中，同样源目的ip,同样源目的port，同样的第4层协议的连接会被防火墙看成是同一个会话，因此会存在返回包被丢弃现象。

如下图。

此时的整个dns解析过程如下：

1 主机从一个随机的源端口，请求 DNS的A 记录，
2 主机从同一个源端口，请求 DNS的AAAA 记录，

9  主机收到dns的AAAA记录响应；

我们看到在这个解析的序列里面，dns解析有5秒的延迟发生。所以当用linux系统安装大量远程包的时候宏观上看延迟就非常大了（linux是不缓存dns解析记录的）。

那么到底  options single-request-reopen  这个参数的作用是什么的，man 5 resolv,conf的结果如下

             single-request-reopen (since glibc 2.9)

                     The resolver uses the same socket for the A and AAAA

                     requests.  Some hardware mistakenly sends back only one

                     reply.  When that happens the client system will sit

                     and wait for the second reply.  Turning this option on

                     changes this behavior so that if two requests from the

                     same port are not handled correctly it will close the

                     socket and open a new one before sending the second

                     request

                                                                             ----andy chou 整理