Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-19 Пенетрантность Андрей Любимец 
11.01.2016 23:50, Oleksandr Gavenko пишет:
> 
> у меня не встречалось потерь 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 внутри и
> радоваться скоростью страничек уже всей семьей!
> 
мне кажется, что это тот случай когда более полезно установить lwresd

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-12 Пенетрантность Oleksandr Gavenko 
On 2016-01-12, Oleksandr Gavenko wrote:

> C pdnsd все правильно:
>   $ sudo pdnsd-ctl empty-cache google.com
>
>   Opening socket /var/cache/pdnsd/pdnsd.status
>   Succeeded

Хотелось бы добавить что очень даже правильно:

  bash# sudo service pdnsd stop
  [ ok ] Stopping pdnsd.

  bash# cat /etc/resolv.conf 
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 8.8.4.4
  nameserver 8.8.8.8
  search home

  bash# sudo service pdnsd start
  [ ok ] Starting pdnsd.

  bash# cat /etc/resolv.conf 
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 127.0.0.1
  search home

-- 
http://defun.work/

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-12 Пенетрантность Oleksandr Gavenko 
On 2016-01-11, Mikhail A Antonov wrote:

>> Сначала почитал про dnsmasq, но он не запоминает разрешения между
>> перезагрузками сервиса.
> Зачем сохранять ДНС-кэш на диск?
> Это тебе не вёб-прокси. Здесь дешевле переспросить, чем хранить.
> Отлаживай потом ещё всё это.

Недавно использовал ConnMan. В него встроен:

   ConnMan implements DNS resolving and caching, DHCP clients for both IPv4 and
   IPv6, link-local IPv4 address handling and tethering (IP connection sharing)
   to clients via USB, ethernet, WiFi, cellular and Bluetooth.

Когда играл с DNS именами 3 уровня - упорно не разрешались имена. Тогда и
узнал о кеширующем DNS сервере (в этой рассылке спрашивал еще).

В ConnMan нету штатной возможности сбросить кеш. Не помню помогало ли "service
... restart". Мне кажется по итогу я просто выключил сам кеш. Но в конце
отказался от ConnMan, когда отказался от WiFi.

C pdnsd все правильно:

  $ sudo pdnsd-ctl dump google.com

  Opening socket /var/cache/pdnsd/pdnsd.status
  google.com.
  01/11 22:30:21A   173.194.71.139
  01/11 22:30:21A   173.194.71.102
  01/11 22:30:21A   173.194.71.138
  01/11 22:30:21A   173.194.71.101
  01/11 22:30:21A   173.194.71.113
  01/11 22:30:21A   173.194.71.100

  Succeeded

  $ sudo pdnsd-ctl empty-cache google.com

  Opening socket /var/cache/pdnsd/pdnsd.status
  Succeeded

  $ sudo pdnsd-ctl dump google.com

  Opening socket /var/cache/pdnsd/pdnsd.status
  Could not find google.com in the cache.
  Succeeded

Вообще мне нравится идея кеширования и паралельного опроса нескольких
рекурсивных DNS. Еще бы избавится от необходимости упорядочивать приоритеты -
пусть бы компютер сам вычислял лучших из списка.

-- 
http://defun.work/

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-12 Пенетрантность Max Dmitrichenko 
12 января 2016 г., 11:02 пользователь Alexander Wiedergold
 написал:
> You Reuter IP is by DNS deny only Provider

На первой странице русского меню во французском ресторане MAXIM написано:
"Господа, мы сделаем Вам скидку в 10%, если Вы не будете пытаться
делать заказ по-французски".

Попробуйте по-русски, мне кажется у вас лучше получится )

-- 
With best regards
  Max Dmitrichenko

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Max Dmitrichenko 
> У меня TP-LINK TL-WR842DN и сейчас я прописал в настройках DHCP раздавать
> 8.8.4.4 и 8.8.8.8. Но его же можно перепрошить на OpenWRT с dnsmasq внутри и
> радоваться скоростью страничек уже всей семьей!

У меня сейчас дома стоит LinkSys E4300 прошитый DD-WRT. Я там включал
dnsmasq. Это приводило к тому, что периодически какие-то определенные
домены переставали резолвится. Шарк показывал ответ от роутера, что на
сервере DNS (то бишь на роутере) системная ошибка. Но что за ошибка
понять не удалось, в логах пусто. В результате, вернулся к DNS
провайдера пока.

-- 
With best regards
  Max Dmitrichenko

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Mikhail A Antonov 
12.01.2016 00:53, Oleksandr Gavenko пишет:
> On 2016-01-11, Vasiliy P. Melnik wrote:
>
>> Было бы классно вписать кеширующему DNS громадный список публичных DNS и 
>> пусть
>> бы он сам время от времени выбирал наиболее удачные! Такое возможно?
>>
>> а зачем так изголяться то? не проще поставить бинд? пусть он ходит и 
>> резолвит, можно на своей машине даже, только не понимаю зачем этим 
>> заниматься.
>>  
> Сначала почитал про dnsmasq, но он не запоминает разрешения между
> перезагрузками сервиса.
Зачем сохранять ДНС-кэш на диск?
Это тебе не вёб-прокси. Здесь дешевле переспросить, чем хранить.
Отлаживай потом ещё всё это.


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Mikhail A Antonov 
12.01.2016 00:47, Anatoly Pugachev пишет:
> 2016-01-11 23:32 GMT+03:00 Max Dmitrichenko :
>> Вообще не далее как пару недель назад на Хабре обсуждалась
>> отвратительная работа гугловых DNS-серверов из сетей некоторых
>> провайдеров в России. Если не лень, то поищи. Может там и тайна
>> раскрыта.
> легче не пользоваться гугловыми dns, чем искать что-то на хабре.
> локальный dnsmasq (либо на/с роутере/а), с форвардерами от провайдера.
> либо полноценный bind. opendns сервера кстати тоже никто не отменял, к
> слову о гугл dns.
Тогда уж безопасный (или даже семейный) яндекс.днс.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Oleksandr Gavenko 
On 2016-01-11, Vasiliy P. Melnik wrote:

> Было бы классно вписать кеширующему DNS громадный список публичных DNS и 
> пусть
> бы он сам время от времени выбирал наиболее удачные! Такое возможно?
>
> а зачем так изголяться то? не проще поставить бинд? пусть он ходит и 
> резолвит, можно на своей машине даже, только не понимаю зачем этим заниматься.
>  

Сначала почитал про dnsmasq, но он не запоминает разрешения между
перезагрузками сервиса.

В итоге остановился на pdnsd в свяке с resolveconf. Конешно самые удачные он
не умеет выбирать, но из списка паралельно может:

  $ cat /etc/pdnsd.conf

  global {
perm_cache=20480;
min_ttl=1d;
max_ttl=4w;
neg_ttl=5m;

par_queries=3;
  ...

  server {
label="public-dns";

# OpenDNS:
ip=208.67.222.222;
# ip=208.67.220.220;
# Google Public DNS:
ip=8.8.8.8;
# ip=8.8.4.4;
# https://dns.yandex.com/advanced/
ip=77.88.8.8;
# ip=77.88.8.1
# Verizon (Level 3 Communications):
ip=4.2.2.1;
# ip=4.2.2.2;
# ip=4.2.2.3;
# ip=4.2.2.4;
# ip=4.2.2.5;
# ip=4.2.2.6;
# https://help.dyn.com/internet-guide-setup/
ip=216.146.35.35;
# ip=216.146.36.36;
# DNS Advantage:
ip=156.154.70.1;
# ip=156.154.71.1;
# Neustar DNS Advantage 
(https://www.neustar.biz/services/dns-services/free-recursive-dns):
# ip=156.154.70.1;
# ip=156.154.71.1;
# https://www.comodo.com/secure-dns/
# ip=8.26.56.26;
# ip=8.20.247.20;
# Verisign:
ip=64.6.64.6;
# ip=64.6.65.6;

purge_cache=off;
timeout=1;
proxy_only=on;
  }

  server {
  label="resolvconf";
  }

Что бы в /etc/resolv.conf было:

  nameserver 127.0.0.1

нужна запись с

  label="resolvconf";

и я эту секцию server поставил второй после списка Public DNS, иначе первые
запросы беруться с DHCP, а у меня там и так 8.8.8.8 и 8.8.4.4.

Убедится в работе pdnsd можно через:

  global { debug=on; }

и смотреть файл:

  /var/cache/pdnsd/pdnsd.debug

> Еще возник вопрос - стоит ли полагаться на роутер при разрешении имен?
>
> У меня TP-LINK TL-WR842DN и сейчас я прописал в настройках DHCP раздавать
> 8.8.4.4 и 8.8.8.8. Но его же можно перепрошить на OpenWRT с dnsmasq 
> внутри и
> радоваться скоростью страничек уже всей семьей!
>
> слабенький роутер, не куда там особо вливать опенврт

Ясно.

К тому же стремно стремно прошивать. Работает - не трожь ))


Я уже приобрел распиновку c FT2232H, от сюда:

  http://numato.com/ft2232h-breakout-module/

в качестве перестраховки, но все равно в случае проблем - нужно с неделю будет
"учится" электронике.

-- 
http://defun.work/

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Anatoly Pugachev 
2016-01-11 23:32 GMT+03:00 Max Dmitrichenko :
> Вообще не далее как пару недель назад на Хабре обсуждалась
> отвратительная работа гугловых DNS-серверов из сетей некоторых
> провайдеров в России. Если не лень, то поищи. Может там и тайна
> раскрыта.

легче не пользоваться гугловыми dns, чем искать что-то на хабре.
локальный dnsmasq (либо на/с роутере/а), с форвардерами от провайдера.
либо полноценный bind. opendns сервера кстати тоже никто не отменял, к
слову о гугл dns.

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Max Dmitrichenko 
> 13  9.496493436 8.8.8.8 192.168.0.30DNS 89  Standard 
> query response 0x31d1 Server failure A cooking.defun.work OPT

Ой, что это? В ответе видим Server failure.

>
> У DNS же UDP? Т.е. потери допустимы?

Допустимы, но в нормальной ситуации не характерны.

> Т.е. все равно нет кристальной ясности т.к. с futex и UDP не знаком.

Тут не нужно быть ученным. Один поток ждёт ответа по UDP выполняя
epoll для открытого сокета. Другой поток ждет события от первого
потока о том, что прорезолвилось. Но не дожидается, слетает по
таймауту.

Вообще не далее как пару недель назад на Хабре обсуждалась
отвратительная работа гугловых DNS-серверов из сетей некоторых
провайдеров в России. Если не лень, то поищи. Может там и тайна
раскрыта.

-- 
With best regards
  Max Dmitrichenko

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Vasiliy P. Melnik 
>
> Было бы классно вписать кеширующему DNS громадный список публичных DNS и
> пусть
> бы он сам время от времени выбирал наиболее удачные! Такое возможно?
>
>
а зачем так изголяться то? не проще поставить бинд? пусть он ходит и
резолвит, можно на своей машине даже, только не понимаю зачем этим
заниматься.


> Еще возник вопрос - стоит ли полагаться на роутер при разрешении имен?
>
> У меня TP-LINK TL-WR842DN и сейчас я прописал в настройках DHCP раздавать
> 8.8.4.4 и 8.8.8.8. Но его же можно перепрошить на OpenWRT с dnsmasq внутри
> и
> радоваться скоростью страничек уже всей семьей!
>

слабенький роутер, не куда там особо вливать опенврт

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Oleksandr Gavenko 
On 2016-01-11, Max Dmitrichenko wrote:

> 2016-01-11 14:18 GMT+03:00 Oleksandr Gavenko :
>> Я заметил что у меня долго разрешаются адреса:
>>
>>   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
>>
>>   real0m5.066s
>>   user0m0.012s
>>   sys 0m0.004s
>>
>> Я не понимаю почему:
>>
>>   Query time: 48 msec
>>
>> когда:
>>
>>   real0m5.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.19 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 
  26050  0.14 set_robust_list(0x7f0a15d9c9e0, 24 
  26049  0.48 <... sendmsg resumed> ) = 47
  26050  0.06 <... set_robust_list resumed> ) = 0
  26049  0.12 futex(0x7f0a1cb190a4, FUTEX_WAIT_PRIVATE, 3, NULL 

  26050  0.06 futex(0x7f0a1cb1b07c, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1452530640, 114496000}, 
 
  26051  0.000128 <... read resumed> "\24\0\0\0\375\377\377\377", 8) = 8
  26051  0.15 epoll_ctl(5, EPOLL_CTL_ADD, 20, {EPOLLIN, {u32=20, 
u64=20}}) = 0
  26051  0.21 read(3, 0x7f0a1554ae50, 8) = -1 EAGAIN (Resource 
temporarily unavailable)
  26051  0.19 epoll_wait(5,  
  26050  4.999557 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed 
out)

Забавный ключик -r у strace. Да и -f понадобился, dig - многопоточная
программа...

Потом чуть поже видно что была повторная отправка сообщения:

  26049  0.31 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 
  26050  0.90 <... futex resumed> ) = 0
  26050  0.000142 futex(0x7f0a1cb1b07c, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5, {1452530645, 11530}, 
 
  26049  0.41 <... sendmsg resumed> ) = 47
  26049  0.000114 futex(0x7f0a1cb190a4, FUTEX_WAIT_PRIVATE, 5, NULL 

  26051  0.052787 <... epoll_wait resumed> {{EPOLLIN, {u32=20, u64=20}}}, 
64, -1) = 1
  26051  0.89 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.69 epoll_ctl(5, EPOLL_CTL_DEL, 20, 7f0a1554ae50 
  26049  0.17 futex(0x7f0a1cb19028, FUTEX_WAKE_PRIVATE, 1 
  26051  0.000110 <... epoll_ctl resumed> ) = 0
  26049  0.16 <... futex resumed> ) = 0
  26051  0.68 epoll_wait(5,  
  26049  0.21 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.308.8.8.8 DNS 89  Standard query 
0x31d1 A cooking.defun.work OPT
12  9.449151368 192.168.0.308.8.8.8 DNS 89  Standard query 
0x31d1 A cooking.defun.work OPT
13  9.496493436 8.8.8.8 192.168.0.30DNS 89  Standard query 
response 0x31d1 Server failure A cooking.defun.work OPT
14  9.497518147 8.8.8.8 192.168.0.30DNS 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.

Вообще все сходится!


У меня щас мысли

Re: Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Max Dmitrichenko 
Я бы начал с tcpdump/dumpcap по 53 порту.

2016-01-11 14:18 GMT+03:00 Oleksandr Gavenko :
> Я заметил что у меня долго разрешаются адреса:
>
>   bash# time dig @8.8.8.8 +stats tips.defun.work
>
>   ; <<>> DiG 9.9.5-12-Debian <<>> @8.8.8.8 +stats tips.defun.work
>   ; (1 server found)
>   ;; global options: +cmd
>   ;; Got answer:
>   ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8328
>   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>   ;; OPT PSEUDOSECTION:
>   ; EDNS: version: 0, flags:; udp: 512
>   ;; QUESTION SECTION:
>   ;tips.defun.work.   IN  A
>
>   ;; 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
>
>   real0m5.066s
>   user0m0.012s
>   sys 0m0.004s
>
>
> Я не понимаю почему:
>
>   Query time: 48 msec
>
> когда:
>
>   real0m5.066s
>
> Сходная ситуация - когда впервые открываю страницу в браузере (где еще не
> был, доменные имена произвольные).
>
> Вот взял с головы:
>
>   bash# time dig @8.8.8.8 +trace emacs.com.ua
>
>   ...
>   ;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 674 ms
>
>   ...
>   ;; Received 634 bytes from 192.58.128.30#53(j.root-servers.net) in 370 ms
>
>   ...
>   ;; Received 2456 bytes from 194.0.1.9#53(cd1.ns.ua) in 253 ms
>
>   ...
>   ;; Received 105 bytes from 74.123.224.37#53(ba1.ns.ua) in 206 ms
>
>   real0m4.524s
>   user0m0.024s
>   sys 0m0.004s
>
> сумма всех Received ... значительно меньше real.
>
> dig не учитывает время на connect()? Только на read()/write()?
>
> Люди добиваются маленьких пинов к серверам, а тут разрешение DNS все портит -
> задержки по 5 сек.
>
> --
> http://defun.work/
>



-- 
With best regards
  Max Dmitrichenko

Как обьяснить долгую задержку при разрешении имени?

2016-01-11 Пенетрантность Oleksandr Gavenko 
Я заметил что у меня долго разрешаются адреса:

  bash# time dig @8.8.8.8 +stats tips.defun.work

  ; <<>> DiG 9.9.5-12-Debian <<>> @8.8.8.8 +stats tips.defun.work
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8328
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 512
  ;; QUESTION SECTION:
  ;tips.defun.work.   IN  A

  ;; 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

  real0m5.066s
  user0m0.012s
  sys 0m0.004s


Я не понимаю почему:

  Query time: 48 msec

когда:

  real0m5.066s

Сходная ситуация - когда впервые открываю страницу в браузере (где еще не
был, доменные имена произвольные).

Вот взял с головы:

  bash# time dig @8.8.8.8 +trace emacs.com.ua

  ...
  ;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 674 ms

  ...
  ;; Received 634 bytes from 192.58.128.30#53(j.root-servers.net) in 370 ms

  ...
  ;; Received 2456 bytes from 194.0.1.9#53(cd1.ns.ua) in 253 ms

  ...
  ;; Received 105 bytes from 74.123.224.37#53(ba1.ns.ua) in 206 ms

  real0m4.524s
  user0m0.024s
  sys 0m0.004s

сумма всех Received ... значительно меньше real.

dig не учитывает время на connect()? Только на read()/write()?

Люди добиваются маленьких пинов к серверам, а тут разрешение DNS все портит -
задержки по 5 сек.

-- 
http://defun.work/