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

8

私はbind9IPv4（Debian Jessie）で実行されているマスターDNSサーバーと2つのスレーブサーバーを使用してい/etc/bind/named.confます。

listen-on-v6 { none; };

別のサーバーから接続しようとすると、各接続に少なくとも5秒かかります（デバッグにはJosephのタイミング情報を使用しています）。

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com
            time_namelookup:  5.512
               time_connect:  5.512
            time_appconnect:  5.529
           time_pretransfer:  5.529
              time_redirect:  0.000
         time_starttransfer:  5.531
                            ----------
                 time_total:  5.531

によるとcurl、検索にはほとんどの時間がかかりますが、標準nslookupは非常に高速です。

$ time nslookup example.com > /dev/null 2>&1

real    0m0.018s
user    0m0.016s
sys     0m0.000s

curlIPv4を使用するように強制した後、それははるかに良くなります：

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

            time_namelookup:  0.004
               time_connect:  0.005
            time_appconnect:  0.020
           time_pretransfer:  0.020
              time_redirect:  0.000
         time_starttransfer:  0.022
                            ----------
                 time_total:  0.022

ホストでIPv6を無効にしました：

echo 1 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6

問題は解決しないが。straceタイムアウトの理由を確認するために実行してみました：

write(2, "*", 1*)                        = 1
write(2, " ", 1 )                        = 1
write(2, "Hostname was NOT found in DNS ca"..., 36Hostname was NOT found in DNS cache
) = 36
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 4
close(4)                                = 0
mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f220bcf8000
mprotect(0x7f220bcf8000, 4096, PROT_NONE) = 0
clone(child_stack=0x7f220c4f7fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f220c4f89d0, tls=0x7f220c4f8700, child_tidptr=0x7f220c4f89d0) = 2004
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
poll(0, 0, 4)                           = 0 (Timeout)
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
poll(0, 0, 8)                           = 0 (Timeout)
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
poll(0, 0, 16)                          = 0 (Timeout)
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
poll(0, 0, 32)                          = 0 (Timeout)
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f22102e08d0}, NULL, 8) = 0
poll(0, 0, 64)                          = 0 (Timeout)

nslookup（またはcurl -4）が同じDNSサーバーを使用しているため、ファイアウォールの問題ではないようです。何が間違っているのでしょうか？

これtcpdumpはホストからのものですtcpdump -vvv -s 0 -l -n port 53：

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:14:52.542526 IP (tos 0x0, ttl 64, id 35839, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.1.59163 > 192.168.1.2.53: [bad udp cksum 0xf9f3 -> 0x96c7!] 39535+ A? example.com. (35)
20:14:52.542540 IP (tos 0x0, ttl 64, id 35840, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.1.59163 > 192.168.1.2.53: [bad udp cksum 0xf9f3 -> 0x6289!] 45997+ AAAA? example.com. (35)
20:14:52.543281 IP (tos 0x0, ttl 61, id 63674, offset 0, flags [none], proto UDP (17), length 158)
    192.168.1.2.53 > 192.168.1.1.59163: [udp sum ok] 45997* q: AAAA? example.com. 1/1/0 example.com. [1h] CNAME s01.example.com. ns: example.com. [10m] SOA ns01.example.com. ns51.domaincontrol.com. 2016062008 28800 7200 1209600 600 (130)
20:14:57.547439 IP (tos 0x0, ttl 64, id 36868, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.1.59163 > 192.168.1.2.53: [bad udp cksum 0xf9f3 -> 0x96c7!] 39535+ A? example.com. (35)
20:14:57.548188 IP (tos 0x0, ttl 61, id 64567, offset 0, flags [none], proto UDP (17), length 184)
    192.168.1.2.53 > 192.168.1.1.59163: [udp sum ok] 39535* q: A? example.com. 2/2/2 example.com. [1h] CNAME s01.example.com., s01.example.com. [1h] A 136.243.154.168 ns: example.com. [30m] NS ns01.example.com., example.com. [30m] NS ns02.example.com. ar: ns01.example.com. [1h] A 136.243.154.168, ns02.example.com. [1h] A 192.168.1.2 (156)
20:14:57.548250 IP (tos 0x0, ttl 64, id 36869, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.1.59163 > 192.168.1.2.53: [bad udp cksum 0xf9f3 -> 0x6289!] 45997+ AAAA? example.com. (35)
20:14:57.548934 IP (tos 0x0, ttl 61, id 64568, offset 0, flags [none], proto UDP (17), length 158)
    192.168.1.2.53 > 192.168.1.1.59163: [udp sum ok] 45997* q: AAAA? example.com. 1/1/0 example.com. [1h] CNAME s01.example.com. ns: example.com. [10m] SOA ns01.example.com. ns51.domaincontrol.com. 2016062008 28800 7200 1209600 600 (130)

編集： バインドログに頻繁にこのメッセージが表示されます：

error sending response: host unreachable

ただし、各クエリは最終的に応答されます（5秒しかかかりません）。すべてのマシンは物理サーバーであり（NATの障害ではありません）、パケットがルーターによってブロックされている可能性が高くなります。よくある関連質問を次に示します。DNSルックアップには5秒かかることがあります。

debian  dns  ipv6  bind  nslookup 
— トンバート
ソース
1
strace -tt遅延を追跡するときに、トレースがより有益になります。
— JigglyNaga
おかげで、この場合はあまり役に立ちません。タイムアウトを増やして同じ接続を再試行しているときに、見た目が止まっているようpoll(0, 0, 1000) = 0 (Timeout)です。DNSサーバー側でerror sending response: host unreachable、発信パケットがブロックされているように見える（ただし、ではないnslookup）エラーが頻繁に発生しています。
— トゥームバート2016年
このルックスsimilar- philippecloutier.com/...
— ジェフ・シャラー

回答:

9

簡潔な答え：

回避策はglibc、AAAAとA行を検索するためにソケットを再利用することを強制すること/etc/resolv.confです：

options single-request-reopen

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

長い答え：

glibcの関数getaddrinfo（）のようなプログラムを使用するcurlか、またはgetaddrinfo（）をwget使用して、両方のDNSレコードを並行して検索することにより、IPv4とIPv6の両方との互換性を試みます。両方のレコードが受信されるまで結果は返されません（そのような動作に関連するいくつかの問題があります）-これはstrace上記の説明です。curl -4内部的gethostbyname()にAレコードのみを照会するように、IPv4が強制される場合。

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

  • -> A? 最初に2つのリクエストが送信されます
  • -> AAAA? （IPv6アドレスの要求）
  • <- AAAA 応答
  • -> A? IPv4アドレスを再度要求する
  • <- A 返事をもらった
  • -> AAAA? もう一度IPv6を要求する
  • <- AAAA 応答

Aなんらかの理由で1つの応答がドロップされます。それがこのエラーメッセージです。

error sending response: host unreachable

しかし、なぜ2番目のAAAAクエリが必要なのかは不明です。

同じ問題が発生していることを確認するには、タイムアウトを/etc/resolv.conf次のように更新します。

options timeout:3

以下のようにここで説明します：

$ 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要求を順番に実行させます（解決プロセスの速度低下を犠牲にします）。

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

関連する問題：

— トンバート
ソース
@RuiFRibeiro電圧だけに基づいて、ユーザーは他の回答がより役立つと感じたようです。犯罪は意味しません。
— トムバート
4

@Tombartが言うように、遅延はIPv6解決タイムアウトの待機が原因です。

別の可能な行動方針は、/ 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リゾルバーライブラリを使用してアプリを再起動する必要があります。

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

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

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

OPTIONS="-4 -u bind"

で/etc/bind/db.root、AAAA DNSルートを持つすべての行を削除します。

— ルイ・F・リベイロ
ソース
2

BIND9の使用中に同様の問題が発生しました。これを修正するには、追加する必要がありました：

filter-aaaa-on-v4 yes;

私へのオプションnamed.conf。

（詳細）

— Xtavras
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.