Re: Как обьяснить долгую задержку при разрешении имени?
On 2016-01-11, Max Dmitrichenko wrote:
> 2016-01-11 14:18 GMT+03:00 Oleksandr Gavenko <gavenkoa@gmail.com>:
>> Я заметил что у меня долго разрешаются адреса:
>>
>> bash# time dig @8.8.8.8 +stats tips.defun.work
>>
>> ;; Query time: 48 msec
>> ;; SERVER: 8.8.8.8#53(8.8.8.8)
>> ;; WHEN: Mon Jan 11 13:03:45 EET 2016
>> ;; MSG SIZE rcvd: 44
>>
>> real 0m5.066s
>> user 0m0.012s
>> sys 0m0.004s
>>
>> Я не понимаю почему:
>>
>> Query time: 48 msec
>>
>> когда:
>>
>> real 0m5.066s
> Я бы начал с tcpdump/dumpcap по 53 порту.
>
Проблема с dig встречается периодично.
В Wireshark задал фильтр на capture:
port 53
Отловил случай. Вмессте с тем запускал:
strace -f -o dig2.log -r dig @8.8.8.8 +noall +stats A cooking.defun.work
Тут уже есть обьяснение проблемы:
26049 0.000019 sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"7E\1 \0\1\0\0\0\0\0\1\7cooking\5defun\4work\0"..., 47}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...>
26050 0.000014 set_robust_list(0x7f0a15d9c9e0, 24 <unfinished ...>
26049 0.000048 <... sendmsg resumed> ) = 47
26050 0.000006 <... set_robust_list resumed> ) = 0
26049 0.000012 futex(0x7f0a1cb190a4, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
26050 0.000006 futex(0x7f0a1cb1b07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1452530640, 114496000}, ffffffff <unfinished ...>
26051 0.000128 <... read resumed> "\24\0\0\0\375\377\377\377", 8) = 8
26051 0.000015 epoll_ctl(5, EPOLL_CTL_ADD, 20, {EPOLLIN, {u32=20, u64=20}}) = 0
26051 0.000021 read(3, 0x7f0a1554ae50, 8) = -1 EAGAIN (Resource temporarily unavailable)
26051 0.000019 epoll_wait(5, <unfinished ...>
26050 4.999557 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
Забавный ключик -r у strace. Да и -f понадобился, dig - многопоточная
программа...
Потом чуть поже видно что была повторная отправка сообщения:
26049 0.000031 sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"7E\1 \0\1\0\0\0\0\0\1\7cooking\5defun\4work\0"..., 47}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...>
26050 0.000090 <... futex resumed> ) = 0
26050 0.000142 futex(0x7f0a1cb1b07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5, {1452530645, 115300000}, ffffffff <unfinished ...>
26049 0.000041 <... sendmsg resumed> ) = 47
26049 0.000114 futex(0x7f0a1cb190a4, FUTEX_WAIT_PRIVATE, 5, NULL <unfinished ...>
26051 0.052787 <... epoll_wait resumed> {{EPOLLIN, {u32=20, u64=20}}}, 64, -1) = 1
26051 0.000089 futex(0x7f0a1cb190a4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f0a1cb190a0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
26049 0.000109 <... futex resumed> ) = 0
26051 0.000069 epoll_ctl(5, EPOLL_CTL_DEL, 20, 7f0a1554ae50 <unfinished ...>
26049 0.000017 futex(0x7f0a1cb19028, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
26051 0.000110 <... epoll_ctl resumed> ) = 0
26049 0.000016 <... futex resumed> ) = 0
26051 0.000068 epoll_wait(5, <unfinished ...>
26049 0.000021 recvmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"7E\201\202\0\1\0\0\0\0\0\1\7cooking\5defun\4work\0"..., 65535}], msg_controllen=32, [{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}], msg_flags=0}, 0) = 47
Соответствующие данные из Wireshark:
11 4.448130957 192.168.0.30 8.8.8.8 DNS 89 Standard query 0x31d1 A cooking.defun.work OPT
12 9.449151368 192.168.0.30 8.8.8.8 DNS 89 Standard query 0x31d1 A cooking.defun.work OPT
13 9.496493436 8.8.8.8 192.168.0.30 DNS 89 Standard query response 0x31d1 Server failure A cooking.defun.work OPT
14 9.497518147 8.8.8.8 192.168.0.30 DNS 105 Standard query response 0x31d1 A cooking.defun.work A 185.86.76.123 OPT
13 и 14 это ответ к 12, т.е. 11 - осталось неотвеченным.
У DNS же UDP? Т.е. потери допустимы?
Т.е. все равно нет кристальной ясности т.к. с futex и UDP не знаком. Но
коственно делаю предположение что сервер 8.8.8.8 находится далеко от меня, с
неудачным роутингом.
Удалось воспроизвести поблему с https://help.dyn.com/internet-guide-setup/
dig @216.146.35.35 +nocmd +noall +stats cooking.defun.work
На первый запрос нету ответа, только на второй показал Wireshark...
В мануале dig(1):
QUERY OPTIONS
dig provides a number of query options which affect the way in which
lookups are made and the results displayed. Some of these set or reset
flag bits in the query header, some determine which sections of the
answer get printed, and others determine the timeout and retry
strategies.
Т.е. таймаут и повторные попытки это нормальное явление у DNS запросов!
Далее:
+time=T
Sets the timeout for a query to T seconds. The default timeout is 5
seconds. An attempt to set T to less than 1 will result in a query
timeout of 1 second being applied.
Вообще все сходится!
У меня щас мысли - сменить используемый recursive NS. С Verizon'вскими:
4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6
у меня не встречалось потерь UDP пакетов.
И установить dnsmasq или что то из:
$ aptitude search '?tag(protocol::dns) ?tag(network::server)'
p dnsmasq - Small caching DNS proxy and DHCP/TFTP server
Было бы классно вписать кеширующему DNS громадный список публичных DNS и пусть
бы он сам время от времени выбирал наиболее удачные! Такое возможно?
Еще возник вопрос - стоит ли полагаться на роутер при разрешении имен?
У меня TP-LINK TL-WR842DN и сейчас я прописал в настройках DHCP раздавать
8.8.4.4 и 8.8.8.8. Но его же можно перепрошить на OpenWRT с dnsmasq внутри и
радоваться скоростью страничек уже всей семьей!
--
http://defun.work/
Reply to: