私はbind9
を使用して、IPv4(Debian Jessie)で実行されているマスター/etc/bind/named.conf
DNSサーバーと2つのスレーブサーバーを持っています。
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
curl
にIPv4の使用を強制した後、はるかに良くなります:
$ 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)
EDIT:バインドログで、次のメッセージが頻繁に表示されます。
error sending response: Host unreachable
ただし、各クエリは最終的に回答されます(5秒しかかかりません)。すべてのマシンは物理サーバーであり(NATの障害ではありません)、パケットがルーターによってブロックされている可能性が高くなります。関連する可能性の高い質問は次のとおりです: DNS検索には5秒かかることがあります 。
短い答え:
回避策は、_/etc/resolv.conf
_に行を追加することにより、glibc
がAAAA
およびA
レコードを検索するためにソケットを再利用するように強制することです:
_options single-request-reopen
_
この問題の実際の原因は次のとおりです。
AAAA
DNSパケットがドロップされます長い答え:
curl
やwget
のようなプログラムは、glibcの関数 getaddrinfo() を使用します。これは、両方のDNSレコードを並行して検索することにより、IPv4とIPv6の両方との互換性を試みます。両方のレコードが受信されるまで結果は返されません( そのような動作に関連するいくつかの問題があります )-これは上記のstrace
の説明です。 _curl -4
_内部的にgethostbyname()
のようにIPv4が強制される場合、A
レコードのみを照会します。
tcpdump
から、次のことがわかります。
-> A?
_最初に2つのリクエストが送信されます-> AAAA?
_(IPv6アドレスを要求)<- AAAA
_返信-> A?
_ IPv4アドレスを再度要求する<- A
_返信を受け取りました-> AAAA?
_ IPv6を再度要求<- AAAA
_返信何らかの理由で1つのA
応答がドロップされます。これは次のエラーメッセージです。
_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
_
_man resolv.conf
_には、他に2つの関連オプションがあります。
single-request(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番目の要求を送信する前にソケットを閉じて新しいソケットを開きます。
関連する問題:
@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サーバーを使用している場合は、named
でIPv6を無効にし、ルートヒントからIPv6アドレスを取得することをお勧めします。明らかにそれはまだAAAAアドレスを解決しようとします。
したがって、BIND構成の場合、
/ etc/default/bind9で、IPv4アドレスに-4を追加します。
OPTIONS="-4 -u bind"
と/etc/bind/db.root
、AAAA DNSルートを持つすべての行を削除します。