Jump to content
Калькуляторы

Плющит DNS провайдера.

Уважаемые господа, провайдер NetByNet (Тверская область). В последнее время стало дико плющить серфинг. Остальное - в норме. Опытным путем установил, что при замене DNS, которые выдаются провайдером на любые другие (гуглоDNS и др.), серфинг становится комфортным.

Обращение в ТП провайдера (как по телефону, так и в их группе ВКонтактике, ничего не прояснило. ВКонтакте, после того, как меня заставили сделать ping, traceroute до DNS провайдера, заявили, что судя по проведенным тестам - проблем с DNS у меня нет. После такого заявления я впал в некий ступор, т.к. понятно, что по этим тестам можно сказать только одно - проблем нет на участке мой компьютер-->DNS провайдера.

Поставил на комп dnsperf, прогнал тесты:

 

Первичный DNS

 

Statistics:

 

Queries sent: 1534

Queries completed: 347 (22.62%)

Queries lost: 1187 (77.38%)

 

Response codes: NOERROR 277 (79.83%), SERVFAIL 3 (0.86%), NXDOMAIN 67 (19.31%)

Average packet size: request 38, response 151

Run time (s): 61.895467

Queries per second: 5.606226

 

Average Latency (s): 0.214608 (min 0.000660, max 2.587260)

Latency StdDev (s): 0.280386

 

Вторичный DNS

 

Statistics:

 

Queries sent: 1504

Queries completed: 312 (20.74%)

Queries lost: 1192 (79.26%)

 

Response codes: NOERROR 262 (83.97%), SERVFAIL 1 (0.32%), NXDOMAIN 49 (15.71%)

Average packet size: request 38, response 152

Run time (s): 60.150802

Queries per second: 5.186963

 

Average Latency (s): 0.215579 (min 0.000651, max 1.811782)

Latency StdDev (s): 0.265354

 

Как доказать ТП провайдера, что у них, по сути не работают DNS?

Или забить и пользовать сторонние?

Вот, кстати, результат тестирования стороннего DNS, который я сейчас использую:

Statistics:

 

Queries sent: 45312

Queries completed: 44845 (98.97%)

Queries lost: 467 (1.03%)

 

Response codes: NOERROR 37905 (84.52%), SERVFAIL 58 (0.13%), NXDOMAIN 6882 (15.35%)

Average packet size: request 38, response 85

Run time (s): 63.145164

Queries per second: 710.188986

 

Average Latency (s): 0.083189 (min 0.005170, max 3.393956)

Latency StdDev (s): 0.183148

 

разницу видно невооруженным глазом.

Share this post


Link to post
Share on other sites

Накати себе unbound и забудь навсегда о ДНС провайдера.

Share this post


Link to post
Share on other sites

действительно проще использовать днс яндекс/гугл или даже запилить свой днс-сервер, чем что-то доказывать провайдеру, тем более купленного, обычно после покупки становится не до абонентов

Share this post


Link to post
Share on other sites

Спасибо за ответы. Собственно, DNS (Bind) поднят на роутере (OpenWRT). Наверное, это - действительно лучший выход из положения, чем бодаться с провайдером. Но таки проблема есть, и если учесть, что провайдер выдает эти DNS практически ВСЕМ абонентам, то мне казалось, что в интересах провайдера решить проблему, чем не признавать ее. Хотя, может быть я и ошибаюсь. Может для них проще - потерять часть абонентов, чем что то решить.

Share this post


Link to post
Share on other sites

Накати себе unbound и забудь навсегда о ДНС провайдера.

В небольшой сети он будет ощутимо тормозить из-за малого попадания в кеш. Лучше использовать сторонний сервис, вроде гугла или яндекса. Лучший вариант - свой кеширующий днс с форвардом всех запросов на гугло / яндекс днс.

Edited by adsh

Share this post


Link to post
Share on other sites

Лучший вариант - свой кеширующий днс с форвардом всех запросов на гугло / яндекс днс.

Unbound

Share this post


Link to post
Share on other sites

надеюсь на твоем бинде рекурсия не развешена со всех сторон ?

Share this post


Link to post
Share on other sites

Накати себе unbound и забудь навсегда о ДНС провайдера.

В небольшой сети он будет ощутимо тормозить из-за малого попадания в кеш.

Не будет.

 

Лучше использовать сторонний сервис, вроде гугла или яндекса. Лучший вариант - свой кеширующий днс с форвардом всех запросов на гугло / яндекс днс.

Сторонний сервис лучше вообще никогда нигде не использовать. Он гарантирует, что днс запросы на нсы домена будут отправлены с src-ip где-то далеко от клиента и часть ресурсов интернета будет ходить медленнее из других стран, хотя могла бы быстрее и поближе к клиенту.

 

Но таки проблема есть, и если учесть, что провайдер выдает эти DNS практически ВСЕМ абонентам, то мне казалось, что в интересах провайдера решить проблему, чем не признавать ее.

А еще проблема может проявляться только у вас.

Share this post


Link to post
Share on other sites
В небольшой сети он будет ощутимо тормозить из-за малого попадания в кеш.

Фигня.

У меня дома и ещё в паре мелких офисов оно так уже пару лет, никаких тормозов не замечено.

Я не спорюс тем, что кеш провайдера ответит ощутимо быстрее (те может ответить, если знает и сам не тормозит), но на не загруженной линии полный резолв домена от корня это около секунды, даже меньше, но обычно резолв начинается не с корня, а ощутимо ближе, ибо предыдущие обращения закешированы.

Да и сами юзеры не так чтобы сильно шляются по разным доменам/сайтам, потому оно у них давно в локальных кешах на их компах сидит.

 

Лучше использовать сторонний сервис, вроде гугла или яндекса. Лучший вариант - свой кеширующий днс с форвардом всех запросов на гугло / яндекс днс.

Слить все каким то типам очень "умное" решение.

Share this post


Link to post
Share on other sites

У меня дома и ещё в паре мелких офисов оно так уже пару лет, никаких тормозов не замечено.

Это если не сравнивать. По сравнению с нормальными днс маленький свой заметно тормозит. На пустом канале. Много раз тестил. Чем больше кеш, тем он быстрее. Если железо справляется и близко к клиенту. Тестировать очень просто - включаем / отключаем форвард на публичный кеш и сравниваем.

 

Слить все каким то типам очень "умное" решение.

Тут каждый выбирает, что ему нужно - скорость или приватность. У Яндекса есть свои плюшки, вроде фильтрации зараженных сайтов или порнухи.

Edited by adsh

Share this post


Link to post
Share on other sites

Сторонний сервис лучше вообще никогда нигде не использовать. Он гарантирует, что днс запросы на нсы домена будут отправлены с src-ip где-то далеко от клиента и часть ресурсов интернета будет ходить медленнее из других стран, хотя могла бы быстрее и поближе к клиенту.

Это, если неправильно выбран кеш. Вот пример из одной конторы в Киеве (почти пустой аплинк до UA-IX 10G, исходящий роутер конторы ccc). Это - неправильный выбор (кеш находится где-то в заднице):

 

 Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. aaa                                     0.0%     3    1.9   1.8   1.7   1.9   0.0
2. bbb                                     0.0%     3    1.8   1.9   1.8   2.1   0.0
3. ccc                                     0.0%     2    0.7   0.8   0.7   0.9   0.0
4. google-gw.ix.net.ua                     0.0%     2    0.8   0.8   0.8   0.8   0.0
5. 209.85.252.123                          0.0%     2   35.4  35.4  35.4  35.5   0.0
6. 209.85.249.175                          0.0%     2   35.3  35.7  35.3  36.2   0.0
7. 72.14.233.170                           0.0%     2   35.5  35.5  35.5  35.6   0.0
8. ???
9. google-public-dns-a.google.com          0.0%     2   35.3  35.4  35.3  35.6   0.0

 

А это - правильный:

 

 Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. aaa                                     0.0%     4    1.8   1.8   1.7   1.9   0.0
2. bbb                                     0.0%     3    1.8   1.8   1.8   1.8   0.0
3. ccc                                     0.0%     3    0.7   0.8   0.7   0.9   0.0
4. yandex-10G-gw.ix.net.ua                 0.0%     3    0.9   0.9   0.8   1.0   0.0
5. family.dns.yandex.ru                    0.0%     3    0.6   0.7   0.6   0.8   0.0

 

Но даже первый вариант быстрее корпоративного днс, стоит отключить на него форвард и сравнить. Это на канале в мир в несколько GBps, лишь слегка заполненном в час пик (сейчас повальный отпускной период). Конечно могут быть глюки геолокации для отдельных доменов. Но это легко можно решить так:

 

zone "googlevideo.com" in { type forward; forward only; forwarders { корпоративный NS1; корпоративный NS2; }; };

 

И нет проблем.

 

Для тех, кто комплексует по поводу своих ощущений и хочет цифры есть чудная программа http://code.google.com/p/namebench/ - покажет скорость в цветах и красках именно для доменов, по которым лазит клиент или по набору популярных сайтов. Для тех, кому лень вникать: http://www.comss.ru/page.php?id=1691

 

Пробуйте namebench - в тормознутости вашего локального днс убедит самых ярых скептиков.

Edited by adsh

Share this post


Link to post
Share on other sites

Это, если неправильно выбран кеш.

Вы хоть поняли о чем я? В интернете популярна такая штука, как отдача разных IP адресов для разных стран на основе IP адреса, с которого был отправлен запрос в днс. В bind для этого созданы view'ы. Многие маленькие CDN этой штукой пользуются.

Соответственно для сторонних днс сервисов нельзя выбрать сервер в стране клиента, т.к. они отправляют запрос со своего IP (ну т.е. теоретически можно с каждым сервисом договариваться, чтобы указывал, откуда запрос пришел, но пока только с гуглом можно и мало кто такой херней страдает).

Потому почти все, кто пользуются такими сервисами будут получать сервер далеко от них на часть сайтов.

 

Раз уже о проблемах этого маразма начали, то дальше у этих сервисов есть ограничения на количество запросов. Никакая маленькая сеть не будет нормально работать с днс сервером, который форвардит запросы на такие сервисы, рано или поздно упрется в лимит и у кого-то какие-то сайты не будут открываться, начнутся магические глюки. На локале такие темы не раз подымались.

 

На счет ощутимо быстрее - это бред, нет смысла обсуждать. Бенчмарки - не ощущения.

 

Можно еще сказать, что эти странные централизованные гугловские и яндексовские днс сервисы ломают устойчивость и надежность всей распределенной системы днс и интернета. Они работают против интернета. Достаточно положить две компании, чтобы у очень многих людей перестал работать интернет. Не хорошо. Яндекс и гугл плохие ребята.

 

Короче, не надо юзать эти идиотские днс сервисы.

Share this post


Link to post
Share on other sites

Вы хоть поняли о чем я?

Для кого я привёл пример с форвард зоной для таких случаев? Их не так много на самом деле.

На счет ощутимо быстрее - это бред, нет смысла обсуждать. Бенчмарки - не ощущения.

Я так понял, что Ваши аргументы против закончились. Единственный конструктивный аргумент был - неправильная геолокация для отдельных сервисов. Но - см. выше и ниже.

 

Достаточно положить две компании, чтобы у очень многих людей перестал работать интернет.

О - да. Закомментировать форвард и дать rndc reload - это так сложно :). Не забывайте, что у них там стоит кластер и резервирование каналов, по этому устойчивость у них не такая, как у обычных сервисов. В нашей конторе (больше тысячи онлайн компов) куда чаше падает корпоративный днс сервер :) (не потому, что нагружен - некие админы криво правят конфиги, потом ищут ошибки, а он лежит).

 

По моим наблюдениям - для крупных сервисов болезни неправильной геолокации давно вылечены:

 

root@Launcher:/home/adsh>host -4 -t A vk.me 213.179.249.131
Using domain server:
Name: 213.179.249.131
Address: 213.179.249.131#53
Aliases:

vk.me has address 87.240.131.118
vk.me has address 87.240.131.117
vk.me has address 87.240.131.119
root@Launcher:/home/adsh>host -4 -t A vk.me 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

vk.me has address 87.240.131.117
vk.me has address 87.240.131.118
vk.me has address 87.240.131.119
root@Launcher:/home/adsh>host -4 -t A vk.me 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases:

vk.me has address 87.240.131.119
vk.me has address 87.240.131.118
vk.me has address 87.240.131.117

 

А это вообще забавно - днс провайдера приводит к более удалённому серверу с большей общей задержкой, чем два других:

 

root@Launcher:/home/adsh>host -4 -t A googlevideo.com 213.179.249.131
Using domain server:
Name: 213.179.249.131
Address: 213.179.249.131#53
Aliases:

googlevideo.com has address 173.194.44.20
googlevideo.com has address 173.194.44.16
googlevideo.com has address 173.194.44.17
googlevideo.com has address 173.194.44.19
googlevideo.com has address 173.194.44.18
root@Launcher:/home/adsh>host -4 -t A googlevideo.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

googlevideo.com has address 173.194.113.208
googlevideo.com has address 173.194.113.212
googlevideo.com has address 173.194.113.209
googlevideo.com has address 173.194.113.210
googlevideo.com has address 173.194.113.211
root@Launcher:/home/adsh>host -4 -t A googlevideo.com 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases:

googlevideo.com has address 173.194.113.212
googlevideo.com has address 173.194.113.209
googlevideo.com has address 173.194.113.210
googlevideo.com has address 173.194.113.211
googlevideo.com has address 173.194.113.208

Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 10.50.21.14                             0.0%    10   17.2  20.3  16.5  50.1  10.5
3. 74.125.52.238                           0.0%    10   17.4  17.1  16.5  17.4   0.3
4. 72.14.233.132                           0.0%     9   31.5  31.6  31.3  31.9   0.3
5. 216.239.48.144                          0.0%     9   41.9  42.1  41.2  46.6   1.7
6. 209.85.142.14                           0.0%     9   41.0  48.1  41.0  85.9  14.9
7. 209.85.240.93                           0.0%     9   42.5  42.2  41.5  42.6   0.3
8. muc03s07-in-f20.1e100.net               0.0%     9   41.5  41.6  41.3  41.8   0.2


Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. ???
2. 10.50.21.14                             0.0%     6   17.2  16.9  16.3  17.4   0.4
3. 74.125.52.238                           0.0%     6   16.7  18.0  16.5  24.0   2.9
4. 72.14.238.162                           0.0%     6   16.9  17.1  16.7  17.7   0.4
5. 173.194.113.212                         0.0%     6   17.0  16.8  16.6  17.0   0.2

 

Поймите - у них оно работает не так тупо, как Вы думаете. Учитывается и геолокация, откуда пришёл запрос. Эти сервисы так же работают над ошибками.

Edited by adsh

Share this post


Link to post
Share on other sites
Это если не сравнивать. По сравнению с нормальными днс маленький свой заметно тормозит. На пустом канале. Много раз тестил. Чем больше кеш, тем он быстрее. Если железо справляется и близко к клиенту. Тестировать очень просто - включаем / отключаем форвард на публичный кеш и сравниваем.

Ощутимо - это когда заметно.

 

Тут каждый выбирает, что ему нужно - скорость или приватность. У Яндекса есть свои плюшки, вроде фильтрации зараженных сайтов или порнухи.

Левые днс большинство прописывает потому что:

- не знает провайдерских

- провайдерские глючат/тормозят дико, в основном это когда время ответа больше пары секунд и частые таймауты

- провайдерские отдают всякую фигню из за плясок с фильтрацией по списку.

 

Лично для меня банально удобнее вообще не думать о настройке днс под конкретного провайдера, не надеятся что у провайдера днс будет адекватен, не парится что гугль/яндекс узнает лишнего.

Вот ни разу скорость меня не парила, ни разу!

Вот посмотрел, гугль отвечает за 15 мс, локальный кеш/резолвер за 60 мс, полный резолв от корня 200 мс.

У меня бразуер дольше рендерит чем резолв от корня идёт, так что считаю проблему скорости высосаной из пальца.

Share this post


Link to post
Share on other sites

Еще есть специализированная утилита для тестирования ДНС - namebench.

Share this post


Link to post
Share on other sites

А вообще, друзья. Тот же Google DNS резольвер передает сетку клиента выщестоящему ДНСУ. И если там не муть класса "Bind", то гео локация отработает корректно. Про Яндекс - не в курсе.

 

Но про то, что эти ребята снижают доступность и надежность Сети - полностью согласен.

Share this post


Link to post
Share on other sites

Пруфы:

 

In addition, Google Public DNS engineers have proposed a technical solution called EDNS Client Subnet. This proposal allows resolvers to pass in part of the client's IP address (the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver. To date, we have deployed an implementation of the proposal for many large CDNs (including Akamai) and Google properties. The majority of geo-sensitive domain names are already covered.

 

https://developers.google.com/speed/public-dns/faq

Share this post


Link to post
Share on other sites

Ощутимо - это когда заметно.

Много лет назад я попробовал поставить себе яндексовский днс и удивился - броузер стал заметно меньше тупить, чем через нс провайдера. Когда идёт резолв десятка-другого доменов блоков и баннеров на странице, затык может составлять единицы секунд. Потом начал экспериментировать - получил подтверждение ещё и в цифрах.

 

Еще есть специализированная утилита для тестирования ДНС - namebench.

А Вы пост #11 читали, или только "по диагонали"?

 

Тот же Google DNS резольвер передает сетку клиента выщестоящему ДНСУ. И если там не муть класса "Bind", то гео локация отработает корректно.

Получается что-то типа tproxy, только для DNS. Спасибо за ссылку на FAQ. Основной аргумент противников улетучился.

 

Но про то, что эти ребята снижают доступность и надежность Сети - полностью согласен.

Формально - да. Но за несколько лет прецедентов не было. За то были проблемы с провайдерскими и корпоративными. Т. е. - шашечки или ехать...

Edited by adsh

Share this post


Link to post
Share on other sites

А вообще, друзья. Тот же Google DNS резольвер передает сетку клиента выщестоящему ДНСУ.

Не передает ничего. Надо договариваться, чтобы передавал, о чем я еще в самом начале говорил.

 

Много лет назад я попробовал поставить себе яндексовский днс и удивился - броузер стал заметно меньше тупить, чем через нс провайдера. Когда идёт резолв десятка-другого доменов блоков и баннеров на странице, затык может составлять единицы секунд. Потом начал экспериментировать - получил подтверждение ещё и в цифрах.

Много лет назад и неправда.

Браузеры разные домены резолвят параллельно.

Share this post


Link to post
Share on other sites

Не передает ничего. Надо договариваться, чтобы передавал, о чем я еще в самом начале говорил.

Ай, как некрасиво. Да - нужно иметь мужество, чтобы признать, что писали глупости.

 

Браузеры разные домены резолвят параллельно.

И да и нет. Зависит от того, как рендерится страница. Чтобы начать резолвить, нужно сначала прочитать ссылку, в которой указан домен. А ссылки напиханы по разным элементам и блокам. Да ещё часто подгружаются они не напрямую, а через ява скрипты, которые тоже тянутся с других доменов. Пока это всё не подгружено и не прочитано, ни о каком резолвинге не может быть и речи. По этому резолвинг идёт скорее последовательно, чем параллельно.

Edited by adsh

Share this post


Link to post
Share on other sites

Не передает ничего. Надо договариваться, чтобы передавал, о чем я еще в самом начале говорил.

Ай, как некрасиво. Да - нужно иметь мужество, чтобы признать, что писали глупости.

Пруф на мои глупости или попрошу оставлять свой полет фантазий себе.

Share this post


Link to post
Share on other sites

Пруф на мои глупости

Соответственно для сторонних днс сервисов нельзя выбрать сервер в стране клиента, т.к. они отправляют запрос со своего IP (ну т.е. теоретически можно с каждым сервисом договариваться, чтобы указывал, откуда запрос пришел, но пока только с гуглом можно и мало кто такой херней страдает).

Потому почти все, кто пользуются такими сервисами будут получать сервер далеко от них на часть сайтов.

Тогда как на самом деле вот так. Запрос отправляется не со своего "айпи", а с сети клиента. Договариваться не нужно - они это сами делают. Кроме того я приводил примеры резолвинга через Яндекс и Гугл для своей сети. Пример хоть и частный, но подтверждает то, что резолвинг идёт с адреса клиента. Т. е. - Яндекс нечто подобное тоже у себя накрутил.

Edited by adsh

Share this post


Link to post
Share on other sites

Тогда как на самом деле вот так. Запрос отправляется не со своего "айпи", а с сети клиента. Договариваться не нужно - они это сами делают.

Ох эти упоротые админы.

 

Запрос отправляется со своего IP и точка. Гугл придумал экстэншн, который дополнительно в запрос добавляет инфу о клиенте (/32 это или /24 - не важно). Включить эту хрень никакой днс сервер сам не может, ее может включить только гугл у себя на серверах и только для тех, кто в днс серверах эту хрень реализовал. И чтобы он это сделал ему надо писать по почте и выпрашивать. Как общение с гуглом происходит все знают.

 

Короче, не знаете о чем говорите, не суйтесь.

Share this post


Link to post
Share on other sites

Да, edns дофига кто не поддерживает. И, полагаю, от него не жарко, ни холодно в среднем по больнице.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this