DNSルックアップに5秒かかることがある

Debian Wheezyを実行しているVMで、リゾルバーがすぐに応答しても、ホスト名の検索が完了するまでに数秒かかることがあります。奇妙なことに、による検索getaddrinfo()は影響を受けますが、影響gethostbyname()はありません。

Googleのリゾルバーに切り替えて、ローカルのリゾルバーが壊れている可能性を排除したので、/etc/resolv.conf次のようになります。

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

私にnsswitch.confは次の行があります：

hosts: files dns

と私/etc/hostsは珍しいものは何も含まれていません。

私が試した場合telnet webserver 80、名前解決を取得する前に数秒間ハングします。ltrace出力ハングであること[1]を示すgetaddrinfo()コール：

getaddrinfo("ifconfig.me", "telnet", { AI_CANONNAME, 0, SOCK_STREAM, 0, 0, NULL, '\000', NULL }, 0x7fffb4ffc160) = 0 <5.020621>

ただし、tcpdumpネームサーバーがすぐに応答し、telnetブロックを解除したのは2番目の応答のみであったことが明らかになりました。返信は同じように見えます：

05:52:58.609731 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:52:58.609786 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:52:58.612188 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)

[...five second pause...]

05:53:03.613811 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:53:03.616424 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)
05:53:03.616547 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:53:03.618907 IP 8.8.4.4.53 > 192.168.1.75.43017: 26090 0/1/0 (76)

ホストファイアウォールのログを確認しましたが、ポート53で何もブロックされていません。

最初のDNS応答が無視される原因は何ですか？

[1] 構造体のltrace.conf内部が見えるように、2行追加しましたaddrinfo。

最初のDNS応答は無視されません。getaddrinfo()最初のAAAAクエリ（ID：26090）に対する応答を受け取るまで戻りませんでした。したがって、ここでの実際の問題は、Aクエリ（ID：54755）の応答を受信して​​いるのに、マシンがAAAAクエリへの応答をすぐに受信していない理由です。

違いの一つgetaddrinfo()とは、gethostbyname()旧サポートIPv4とIPv6の両方、後者はIPv4のみをサポートしながら、ということです。お電話の際はそうgetaddrinfo()でai_family（0に設定AF_UNSPEC）、それは応答を取得（またはタイムアウトに当たる）まで、それがために戻りません両方の AとAAAA提供ドメイン名を照会します。gethostbyname()Aレコードのみを照会します。

問題の原因をリモートで特定することは困難です。特に、一部のtcpdump出力を削除した場合はそうです。何かが、VMとGoogleパブリックDNSリゾルバー間のDNSトラフィックを選択的にフィルタリング/ドロップしている可能性があります。KVM Debian Wheezy VMを使用して問題の再現を試みましたが、telnet ifconfig.meほとんどすぐにTrying <IP_address_here>...行が出力されました（つまり、その時点ですでに名前が解決されています）。

これは、VMwareインフラストラクチャの前にあるジュニパーファイアウォールのルールセットが過度に制限されていることが原因でした。

会話の両側を確認できるようにテストリゾルバーを作成しました。Kempniuの優れた回答で特定された欠落パケットは、実際に途中でドロップされました。その回答で述べたように、getaddrinfo()アドレスファミリが指定されていない場合、サポートされるすべてのファミリに関連する回答が返されるまで待機します（または、私の場合はタイムアウトします）。

ネットワークを運営している私の同僚は、

Juniperファイアウォールのデフォルトの動作では、そのセッションに一致するDNS応答が受信されるとすぐに、DNS関連のセッションが閉じられます。

したがって、ファイアウォールはIPv4応答を確認し、VMのクエリに応答したことを指摘し、そのポートの受信パスを閉じました。したがって、次のIPv6応答パケットはドロップされました。なぜ両方のパケットが2回目に通過したのかはわかりませんが、ファイアウォールでこの機能を無効にすると問題が解決しました。

これはジュニパーKBからの関連する抜粋です。

DNS応答パケットがドロップされるシナリオは次のとおりです。

1. 最初のDNSクエリパケットがファイアウォールに到達し、許可ポリシーが構成されている場合、DNSトラフィックのセッションが作成されます。デフォルトのタイムアウトは60秒です。
2. セッションが閉じる直前に、新しいDNSクエリが送信され、既存のセッションと一致するため（送信元と宛先のポート/ IPペアは常に同じであるため）、ファイアウォールによって転送されます。セッションタイムアウトは、新しく到着したパケットに従って更新されないことに注意してください。
3. 作成されたDNSセッションは、タイムアウトがどれだけ残っていても、最初のDNSクエリ応答（応答）がデバイスに到達すると期限切れになります。
4. DNS応答がファイアウォールを通過すると、セッションは期限切れになります。
5. セッションが存在しないため、後続のすべてのDNS応答はファイアウォールによってドロップされます。

この回答に賛成することを考えている場合は、ケンプニウの回答にも賛成してください。それがなくても、VMの構成に関する問題を見つけようとするのに苦労しています。