ホスト名の解決には5秒かかります。

Question 1

短い答え：

回避策は、次の行を追加して、ルックアップglibcとロギングのためにソケットを強制的に再利用することです。AAAAA/etc/resolv.conf

options single-request-reopen

この問題の実際の原因は次のとおりです。

誤って設定されたファイアウォールまたはルーター（例：ここで説明するジュニパーファイアウォールの設定) はAAAADNS パケット損失を引き起こします。
DNSサーバーエラー

長い答え：

curlwgetglibcの機能に似ているか、それを使用するプログラム住所情報の取得（）、DNSレコードを並列に照会し、IPv4およびIPv6の互換性を試みます。 2つのレコードが受信されるまで結果は返されません。この動作に関連するいくつかの問題) -strace上記の内容を説明します。たとえば、IPv4を強制的に使用すると、curl -4内部的にレコードのみが照会gethostbyname()されますA。

これからtcpdump私たちは以下を見ることができます：

-> A?最初に2つのリクエストを送信します。
-> AAAA?(IPv6 アドレス要求)
<- AAAA返信する
-> A?IPv4アドレスをもう一度リクエストしてください。
<- A返信をいただきました
-> AAAA?IPv6の再リクエスト
<- AAAA返信する

A何らかの理由で返信が削除され、次のエラーメッセージが表示されます。

error sending response: host unreachable

AAAAただし、2番目のクエリが必要な理由は明確ではありません。

同じ問題が発生するかどうかを確認するには、次のタイムアウトを更新できます/etc/resolv.conf。

options timeout:3

まず、テキストファイルを作成します。カスタム時間レポートの設定:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

その後、リクエストを送信します。

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

他に2つの関連オプションがありますman resolv.conf。

単一リクエスト（glibc 2.10以降）設定デフォルトRES_SNGLKUP では _res.options、glibcはバージョン2.9以降、IPv4およびIPv6ルックアップを並列に実行します。一部のデバイス DNS サーバーはこれらのクエリを正しく処理しないため、要求がタイムアウトします。このオプションはこの動作を無効にし、glibcがIPv6およびIPv4要求を順次実行するようにします（構文解析プロセスは遅くなりますが）。

単一のリクエストを再度開く（glibc 2.9以降） リゾルバは、A および AAAA 要求に同じソケットを使用します。一部のハードウェアは1つの応答だけを誤って返します。これが発生すると、クライアントシステムは座って2番目の応答を待ちます。このオプションをオンにすると、この動作が変更され、同じポート上の2つの要求が正しく処理されない場合は、2番目の要求を送信する前にソケットを閉じて新しいソケットを開きます。

関連質問：

Answer

短い答え：

回避策は、次の行を追加して、ルックアップglibcとロギングのためにソケットを強制的に再利用することです。AAAAA/etc/resolv.conf

options single-request-reopen

この問題の実際の原因は次のとおりです。

誤って設定されたファイアウォールまたはルーター（例：ここで説明するジュニパーファイアウォールの設定) はAAAADNS パケット損失を引き起こします。
DNSサーバーエラー

長い答え：

curlwgetglibcの機能に似ているか、それを使用するプログラム住所情報の取得（）、DNSレコードを並列に照会し、IPv4およびIPv6の互換性を試みます。 2つのレコードが受信されるまで結果は返されません。この動作に関連するいくつかの問題) -strace上記の内容を説明します。たとえば、IPv4を強制的に使用すると、curl -4内部的にレコードのみが照会gethostbyname()されますA。

これからtcpdump私たちは以下を見ることができます：

-> A?最初に2つのリクエストを送信します。
-> AAAA?(IPv6 アドレス要求)
<- AAAA返信する
-> A?IPv4アドレスをもう一度リクエストしてください。
<- A返信をいただきました
-> AAAA?IPv6の再リクエスト
<- AAAA返信する

A何らかの理由で返信が削除され、次のエラーメッセージが表示されます。

error sending response: host unreachable

AAAAただし、2番目のクエリが必要な理由は明確ではありません。

同じ問題が発生するかどうかを確認するには、次のタイムアウトを更新できます/etc/resolv.conf。

options timeout:3

まず、テキストファイルを作成します。カスタム時間レポートの設定:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

その後、リクエストを送信します。

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

他に2つの関連オプションがありますman resolv.conf。

単一リクエスト（glibc 2.10以降）設定デフォルトRES_SNGLKUP では _res.options、glibcはバージョン2.9以降、IPv4およびIPv6ルックアップを並列に実行します。一部のデバイス DNS サーバーはこれらのクエリを正しく処理しないため、要求がタイムアウトします。このオプションはこの動作を無効にし、glibcがIPv6およびIPv4要求を順次実行するようにします（構文解析プロセスは遅くなりますが）。

単一のリクエストを再度開く（glibc 2.9以降） リゾルバは、A および AAAA 要求に同じソケットを使用します。一部のハードウェアは1つの応答だけを誤って返します。これが発生すると、クライアントシステムは座って2番目の応答を待ちます。このオプションをオンにすると、この動作が変更され、同じポート上の2つの要求が正しく処理されない場合は、2番目の要求を送信する前にソケットを閉じて新しいソケットを開きます。

関連質問：

Question 2

@Tombartが述べたように、IPv6解像度のタイムアウトを待つと遅延が発生します。

もう1つの可能性は、/etc/gai.confでIPv4の優先順位を指定することです。

/etc/gai.confのコメント

#   For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

変更後にgai.conf変更を適用するには、DNSリゾルバーライブラリを使用するすべてのアプリケーションを再起動する必要があります。

namedIPv6接続なしでBINDサーバーを使用している場合は、IPv6を無効にしてルートプロンプトからIPv6アドレスを取得することをお勧めします。明らかにまだAAAAアドレスを確認しようとします。

したがって、BIND構成の場合

/etc/default/bind9 で IPv4 アドレスに -4 を追加します。

OPTIONS="-4 -u bind"

そして、.NETから/etc/bind/db.rootAAAA DNSルートを持つすべての行を削除します。

Answer