У меня есть главный bind9
DNS-сервер и 2 подчиненных сервера, работающих на IPv4 (Debian Jessie), использующих /etc/bind/named.conf
:
listen-on-v6 { none; };
Когда я пытаюсь подключиться с разных серверов, каждое соединение занимает не менее 5 секунд (я использую информацию о времени Джозефа для отладки):
$ 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)
РЕДАКТИРОВАТЬ: В журналах привязки часто появляется это сообщение:
error sending response: host unreachable
Тем не менее, на каждый запрос в конечном итоге отвечает (это займет всего 5 секунд). Все машины являются физическими серверами (это не вина NAT), более вероятно, что пакеты блокируются маршрутизатором. Вот довольно вероятный связанный вопрос: поиск DNS иногда занимает 5 секунд .
strace -tt
сделает отслеживание более информативным при отслеживании задержек.poll(0, 0, 1000) = 0 (Timeout)
. На стороне DNS-сервера я получаю частые ошибки,error sending response: host unreachable
которые выглядят так, как будто исходящий пакет заблокирован (но не дляnslookup
).Ответы:
Короткий ответ:
Обходной вынуждает
glibc
повторно использовать сокет для взгляда вверх изAAAA
иA
записей, путем добавления строки в/etc/resolv.conf
:Реальная причина этой проблемы может быть:
AAAA
пакетов DNSДлинный ответ:
Программы любят
curl
илиwget
используют функцию gtabc getaddrinfo () , которая пытается быть совместимой с IPv4 и IPv6, просматривая обе записи DNS параллельно. Он не возвращает результат, пока обе записи не будут получены (есть несколько проблем, связанных с таким поведением ) - это объясняетstrace
вышеизложенное. Когда принудительный IPv4, какcurl -4
внутри,gethostbyname()
который запрашиваетA
только запись.Из чего
tcpdump
мы видим, что:-> A?
два запроса отправляются в начале-> AAAA?
(запрашивая адрес IPv6)<- AAAA
Ответить-> A?
запросить снова IPv4-адрес<- A
получил ответ-> AAAA?
запросить IPv6 снова<- AAAA
ОтветитьОдин
A
ответ почему-то отбрасывается, вот это сообщение об ошибке:Тем не менее, мне непонятно, зачем нужен второй
AAAA
запрос.Чтобы убедиться, что у вас возникла та же проблема, вы можете обновить тайм-аут в
/etc/resolv.conf
:как описано здесь :
Есть два других связанных параметра в
man resolv.conf
:Связанные вопросы:
источник
Как говорит @Tombart, задержка связана с ожиданием тайм-аута разрешения IPv6.
Другой возможный вариант действий - дать преимущество IPv4 в /etc/gai.conf.
Из комментариев в /etc/gai.conf
После изменения
gai.conf
необходимо перезапустить любое приложение, используя библиотеку распознавателя DNS, чтобы изменения вступили в силу.Напоминаем, что если вы используете сервер BIND без подключения к IPv6, я советую отключить IPv6
named
и извлечь из корневых ссылок адреса IPv6. Очевидно, он все еще попытается разрешить адреса AAAA.Так что для конфигурации BIND,
В / etc / default / bind9 добавьте -4 для адресов IPv4:
и
/etc/bind/db.root
удалите все строки с корнями DNS AAAA.источник
У меня была похожая проблема при использовании BIND9. Чтобы это исправить, мне нужно было добавить:
вариант мой
named.conf
.( Дополнительная информация )
источник