Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
А, извините, куда, по Вашему мнению лучше всего добавить кавычки? К слову «бесплатный», «Добра», или «Канет в лету?» :)
… а «Чернозадая Обезьяна» с большой буквы, президент всё-таки ©;
Учитывая тот факт, что public dns используется по умолчанию в некоторых Android — вряд ли всё так печально. Скорее просто неполадки.
Да, тоже сменил редирект на него же, но тоже бывают накладки. К примеру, вчера пожаловались, что сайт yaplakal.com не открывается, т.к. Яндекс считает его опасным :)
Товарищ майор тоже!
Не вижу разницы для гипотетического товарища майора, пользуюсь я яндексовым днс или гугловым.
Google Public DNS с поддержкой DNS SEC и соблюдением клиентом и администраторами доменов определённых условий, не даёт шансу «товарищу майору» вмешаться в обмен с системой DNS — подменять IP адреса и т.п.
Яндекс эту технологию не поддерживает, и оставляет товарищу майору возможность обманывать пользователей.
Продвижение DNS SEC идёт с некоторым скрипом, но идёт. История примерно такая же, как с продвижением IPv6. И DNS SEC не очень любят тоталитарные гос-ва, ибо… они хотят контроль на информацией, полный тоталитарный контроль. DNS спуффинг для осуществления «оперативных действий» когда вы «под колпаком», вот это всё.
Яндекс эту технологию не поддерживает, и оставляет товарищу майору возможность обманывать пользователей.
Продвижение DNS SEC идёт с некоторым скрипом, но идёт. История примерно такая же, как с продвижением IPv6. И DNS SEC не очень любят тоталитарные гос-ва, ибо… они хотят контроль на информацией, полный тоталитарный контроль. DNS спуффинг для осуществления «оперативных действий» когда вы «под колпаком», вот это всё.
> Нету на 8.8.8.8 DNS SEC
Не хочу спорить, но [ developers.google.com/speed/public-dns/faq#dnssec ].
Для проверки запустите у себя [ nslookup www.dnssec-failed.org 8.8.8.8 ], и получите «server failed». А потом Яндекс: [ nslookup www.dnssec-failed.org 77.88.8.8 ] таки успешно разрезольвит «сломанные» адреса.
То, что свою зону гугл пока не защитил при помощи DNS SEC — его личное дело, но право других защищаться он уважает :)
С каждым годом шансов товарищу майору остаётся всё меньше и меньше. Что касается централизации самой системы DNS и связанных с этим рисков, я надеюсь, что когда-нибудь получат распространение децентрализованные системы навроде проекта NameCoin, а там кроме распределённости, используется HMAC в каждой транзакции… и до свидания, тов. майор!
Не хочу спорить, но [ developers.google.com/speed/public-dns/faq#dnssec ].
Для проверки запустите у себя [ nslookup www.dnssec-failed.org 8.8.8.8 ], и получите «server failed». А потом Яндекс: [ nslookup www.dnssec-failed.org 77.88.8.8 ] таки успешно разрезольвит «сломанные» адреса.
То, что свою зону гугл пока не защитил при помощи DNS SEC — его личное дело, но право других защищаться он уважает :)
С каждым годом шансов товарищу майору остаётся всё меньше и меньше. Что касается централизации самой системы DNS и связанных с этим рисков, я надеюсь, что когда-нибудь получат распространение децентрализованные системы навроде проекта NameCoin, а там кроме распределённости, используется HMAC в каждой транзакции… и до свидания, тов. майор!
Яндекс DNS не поддерживает DNS SEC, который есть окончательный форпост защиты от DNS спуффинга и торжество ассиметричной криптографии в области народного хозяйста :)
А не поддерживает потому, что вмешивается в нормальную работу этого хозяйства, перенаправляя на сайты-заглушки, когда установлены у клиента IP адреса «безопасного» или «семейного» DNS, сам в этом случае становясь тем самым чорным плохим MitM-агентом. Да что говорить про DNS SEC! При попытке захода на HTTPS [ yandex.ru ], получаем редирект на HTTP [ www.yandex.ru ], обламываясь с безопасным поиском, и позволяя всей цепочке от последней мили до Яндексовского магистрала снифать поисковые запросы. Я в жисть не поверю, что у Яндекса перенапрягутся серверы от «этого вашего HTTPS», про причины своей паранойи я однажды написал тут: [ bugtraq.ru/forum/full/2014/networking/167558.html ]. Кому лень ходить — там теория заговора, кровавая гэбня и вот это всё :)
А вот «Корпорация Добра», поддерживает как DNS SEC в своём Public DNS, так и защищённый поиск — причём в поиске принудительный HTTPS. IPv6 тоже во всех сервисах, включая YouTube, представьте — мировой видеохостинг работает по HTTPS + IPv6 и не кашляет! :)
В общем, Google не только на словах говорит нам, что заботится о безопасности и приватности своих пользователей, но показывает это делом, и рискует нести затраты в этом направлении.
В отличие от.
А не поддерживает потому, что вмешивается в нормальную работу этого хозяйства, перенаправляя на сайты-заглушки, когда установлены у клиента IP адреса «безопасного» или «семейного» DNS, сам в этом случае становясь тем самым чорным плохим MitM-агентом. Да что говорить про DNS SEC! При попытке захода на HTTPS [ yandex.ru ], получаем редирект на HTTP [ www.yandex.ru ], обламываясь с безопасным поиском, и позволяя всей цепочке от последней мили до Яндексовского магистрала снифать поисковые запросы. Я в жисть не поверю, что у Яндекса перенапрягутся серверы от «этого вашего HTTPS», про причины своей паранойи я однажды написал тут: [ bugtraq.ru/forum/full/2014/networking/167558.html ]. Кому лень ходить — там теория заговора, кровавая гэбня и вот это всё :)
А вот «Корпорация Добра», поддерживает как DNS SEC в своём Public DNS, так и защищённый поиск — причём в поиске принудительный HTTPS. IPv6 тоже во всех сервисах, включая YouTube, представьте — мировой видеохостинг работает по HTTPS + IPv6 и не кашляет! :)
В общем, Google не только на словах говорит нам, что заботится о безопасности и приватности своих пользователей, но показывает это делом, и рискует нести затраты в этом направлении.
В отличие от.
Да уж, у Яндекса и почтой пользоваться стремно, т.к. нет двойной аутентификации
Яндекс исправился, есть безопасный HTTPs https://www.yandex.ru, поменяйте свои закладки/шорткаты (принудительный редирект на HTTPs не включен), хватит провайдерам и магистралам снифать ВАШ поисковый трафф, это достаточно интимная штука.
Также все службы Яндекса доступны по IPv6.
Всем добра! :)
Также все службы Яндекса доступны по IPv6.
Всем добра! :)
Всегда на таких серверах настраиваю свой DNS-сервер, так как уже не один раз DNS-сервера провайдера падали.
Свой сервер, само собой, но вопрос в том, куда направлен редирект с этого сервера…
Так он по цепочке сам запрашивает, начиная с корневых серверов. Не быстро, не «православно», но зато надёжно.
А зачем настраивать forwarder, если на сервере есть ipv4? Для ipv6-only они пока ещё нужны, а так…
apt-get install bind9
sed 'd/nameserver .*/' /etc/resolv.conf
echo «nameserver 127.0.0.1» >> /etc/resolv.conf
И вот у вас полностью автономный резолвер, который ни от кого не зависит.
apt-get install bind9
sed 'd/nameserver .*/' /etc/resolv.conf
echo «nameserver 127.0.0.1» >> /etc/resolv.conf
И вот у вас полностью автономный резолвер, который ни от кого не зависит.
Да, можно и так, но сильно проседает время отклика. Немного спасает, конечно, кэш, но в целом, полутысяча юзеров за этим сервером ощутимо почувствуют замедление Интернета, что негативно скажется на Вашей же карме :)
Время отклика чего?
Бинды локальные ставят как раз для того, чтобы резолвить всё быстрее =)
Но да, кеш как бэ нужно наполнять чем-то.
Бинды локальные ставят как раз для того, чтобы резолвить всё быстрее =)
Но да, кеш как бэ нужно наполнять чем-то.
Время отклика до неизвестных пока данному серверу доменов.
Первый запрос будет таким же по времени как запрос 8.8.8.8 например. Все последующие — быстрее, насколько я помню
Однозначно нет! Если не указывать редирект, то сервер, на запрос неизвестного ему домена, попытается запросить его у корневых серверов, но корневые сервера сами не отдадут ip-адрес домена, а только лишь адреса ns-серверов, которым делегирован запрашиваемый домен. И только после этого ответа, ваш сервер уже обратится к авторитетным серверам за ip-адресом. Вот и посчитайте время первого отклика…
Всё зависит от того, что за зона, где нс-ки домена, где нс-ки зоны (и да, вы в своём описании пропустили нс-ки зоны).
Например, вот (мимо кеша):
inkvizitor68sl@malygos:~$ time host qs.biz
…
real 0m0.190s
А вот домен в быстром tld в амазоне на route53:
inkvizitor68sl@malygos:~$ time host app.nirvanahq.com
…
real 0m0.068s
Так что не всё так просто. Считать нужно.
По опыту могу сказать, что пиковое — это 600 мс для домена в «медленной» tld (вот новые, например — все медленные почти, ибо нс-ки только в США) + с нс-ками в только США.
Обидно, но не бог весть как много, если вы такие домены тысячами в минуту не резолвите.
Например, вот (мимо кеша):
inkvizitor68sl@malygos:~$ time host qs.biz
…
real 0m0.190s
А вот домен в быстром tld в амазоне на route53:
inkvizitor68sl@malygos:~$ time host app.nirvanahq.com
…
real 0m0.068s
Так что не всё так просто. Считать нужно.
По опыту могу сказать, что пиковое — это 600 мс для домена в «медленной» tld (вот новые, например — все медленные почти, ибо нс-ки только в США) + с нс-ками в только США.
Обидно, но не бог весть как много, если вы такие домены тысячами в минуту не резолвите.
А, ну и с китаем беда, ибо RTT до NS в китае легко зашкаливает за 4 сотни мс даже в ДЦ, не говоря уж о домонетах.
А для чего?
На типовом веб-сервере таких запросов — копейки. Обычно там можно погреть весь кеш сотней-других запросов.
Если вы про роутер для хомячков — нууу… Да, будет тратить лишние 300-600 мс на резолв мимо кеша.
На типовом веб-сервере таких запросов — копейки. Обычно там можно погреть весь кеш сотней-других запросов.
Если вы про роутер для хомячков — нууу… Да, будет тратить лишние 300-600 мс на резолв мимо кеша.
И есть опция prefetch, тогда он будет автоматически обновлять свой кеш.
Ни к чему. Он самостоятельно обновляет ресурсную запись если её запросят когда ttl почти «протух» и осталось меньше 10% от оригинального. Т.е. если эти домены спросят один раз — unbound отрезолвит их один раз.
hs01:~/temp/sources$ grep -nB2 PREFETCH_TTL_CALC ./unbound-1.4.22/util/data/msgreply.h
55-/** calculate the prefetch TTL as 90% of original. Calculation
56- * without numerical overflow (uin32_t) */
57:#define PREFETCH_TTL_CALC(ttl) ((ttl) - (ttl)/10)
Если верить ./unbound-1.4.22/daemon/worker.c и другим немаловажным *.c и *.h, то, вкрадце, работает это так:
- RR.TTL — время жизни ресурсной записи (RR, Resource Record) в секундах, получаем от авторитетных серверов вместе с самой RR.
- ttl — время «протухания» RR в кеше. Именно время, в unix timestamp. ttl = now() + RR.TTL
- prefetch_ttl — время когда уже пора заново идти к авторитетным NS-серверам за правдой, но простой ttl ещё не протух. prefetch_ttl = now() + (RR.TTL — RR.TTL/10)
От клиента пришёл запрос конкретной RR:
- если RR не было в кеше — отрезолвили (сходили к авторитетному серверу), посчитали для неё сразу prefetch_ttl и ttl, да положили в кеш.
- если была в кеше, то (worker.c, строка 935) проверили не протух ли prefetch_ttl: не протух — просто ответили, а если да — отвечаем и обновляем кеш с обновлением prefetch_ttl и ttl (вот она нагрузка +10%).
Если запросов конкретной RR не приходило — она из кеша удаляется по наступлении ttl и всё хорошо, к авторитетным серверам не ходим, память/проц/трафик не жрём.
Совсем плохо будет если туннелировать трафик в днс пакетах через такой рекурсер.
Что же будет плохого? Для туннеля как раз генерируются уникальные имена с маленьким временем жизни (тыц). И эти имена совсем не популярны среди остальных пользователей рекурсора чтобы создавать дополнительную нагрузку.
Если нужен локальный рекурсивный резолвер, то вот уж что точно не подходит, так это Bind. Имею счастье поддерживать распределённый DNS-сервис, обслуживающий на текущий момент 1647 зон. Даже на таких смешных объёмах Bind падает с завидной регулярностью (решается проблема только попытками перезапуска по крону с достаточной частотой). Для кэширующих валидирующих рекурсоров могу посоветовать посмотреть на unbound, а для авторитативных — NSD и Knot DNS.
обычно на домашнем компе ставлю первичный днс — провайдера
вторичный — гугловый
так было написано в какойто рекомендации провайдера
мол днс провайдера ближе и быстрее
гугловый на случай отказа проавйдерского
есть ли какие либо недостатки в таком решении?
вторичный — гугловый
так было написано в какойто рекомендации провайдера
мол днс провайдера ближе и быстрее
гугловый на случай отказа проавйдерского
есть ли какие либо недостатки в таком решении?
Если делегировать домен, то до гугловских ДНСов обычно быстрее «доходит», чем до провайдеровских.
Для домашнего использования лучше и не придумаешь. Но, советую протестировать время отклика от всех известных Вам DNS, чтобы выбрать с наиболее меньшими задержками.
Ну не знаю.
Сижу на Йоте, последнее время жутко долго стали открываться странички, хотя файлы качались с нормальной скоростью, да и пинг совсем небольшой.
В итоге поставил первичным DNS от Гугла, страницы стали открываться значительно быстрее, можно сказать мгновенно, по сравнению с тем, что было.
Так что всегда надо тестировать, что быстрее.
Сижу на Йоте, последнее время жутко долго стали открываться странички, хотя файлы качались с нормальной скоростью, да и пинг совсем небольшой.
В итоге поставил первичным DNS от Гугла, страницы стали открываться значительно быстрее, можно сказать мгновенно, по сравнению с тем, что было.
Так что всегда надо тестировать, что быстрее.
Это если нет проблем у локального провайдера — что не такая уж редкость.
В целом, всё так и должно быть. Есть еще утилита Namebench, ею можно найти самые быстрые DNS-ки среди предложенных вами и близко расположенных по версии самой программы.
есть ли какие либо недостатки в таком решении?
Роскомнадзор и прочая…
У нас у провайдера для упрощения работы фильтроев его DNS отдают для заблоченных ресурсов свой IP. Если подменить DNS то там уже блокировка филтьром (по IP)… Некоторые провайдеры и другие подобные каверзы делают. Однако если у провайдера есть локальные ресурсы на каком-то своем домене, который не резолвится извне, то при установке других DNS они будут недоступны.
PS: У меня сейчас:
Сервер 1: 77.88.8.8
Сервер 2: 8.8.4.4
Сервер 3: 77.88.8.1
Статью плюсанул, но сам ни с чем подобным не сталкивался.
Пользуюсь Google DNS дома, ни разу ничего подобного не случалось. А вот обратные ситуации, когда DNS-ответ кэшируется на компе и перестает соответствовать актуальному ответу Google DNS, происходят редко, но регулярно.
Пользуюсь Google DNS дома, ни разу ничего подобного не случалось. А вот обратные ситуации, когда DNS-ответ кэшируется на компе и перестает соответствовать актуальному ответу Google DNS, происходят редко, но регулярно.
Если попробовать проверить ваш домен различными DNS службами, можно заметить, что некоторые из них не могут соединиться с nsX.nameself.com для получения информации о домене. Может, не будем прямо сразу винить гугл? Попробуйте www.menandmice.com/ например. Для других доменов инфу отдает, для вашего нет.
Спасибо за мнение. В статье не написал, но когда проблема обнаружилась, я создал тикет в техподдержке регистратора, они ответили, что с их стороны все правила соблюдены и фильтрации запросов с выборочных name-служб у них не практикуется :) И повлиять на ситуацию они ничем не могут.
Да и дело-то собственно, даже не в этом. Если бы не мегапопулярность именно публичных серверов Гугля, проблему никто бы и не заметил. И я уже указывал, что проблема открылась не только с нашим доменом и не только с этим регистратором, а именно по причине, что сервера гугля не могут отресолвить часть доменных имен.
Да и дело-то собственно, даже не в этом. Если бы не мегапопулярность именно публичных серверов Гугля, проблему никто бы и не заметил. И я уже указывал, что проблема открылась не только с нашим доменом и не только с этим регистратором, а именно по причине, что сервера гугля не могут отресолвить часть доменных имен.
Да и дело-то собственно, даже не в этом
Как же не в этом? Вы публично на весь интернет крикнули и том, что сервис X медленно загибается. Это просто так сложилось, что гугл настолько велик, что ему, по сути, плевать, что написано на Хабре. А была бы компания поменьше — вы этой статьей могли бы серьезно повредить ее бизнесу. Был бы скандал.
Если уж вы пишете обвинительную статью, извольте хотя бы расследование произвести, а не просто воздух сотрясать…
а именно по причине, что сервера гугля не могут отресолвить часть доменных имен.
Не только серверы Гугла, как выяснилось, верно?
Как же не в этом? Вы публично на весь интернет крикнули и том, что сервис X медленно загибается. Это просто так сложилось, что гугл настолько велик, что ему, по сути, плевать, что написано на Хабре. А была бы компания поменьше — вы этой статьей могли бы серьезно повредить ее бизнесу. Был бы скандал.
Ну, от скандалов, подобные корпорации только выигрывают. Я же, своим постом нес цель привлечения внимания ко все возрастающей проблеме (ведь не только моя организация от этого страдает) в первую очередь, самого Гугла, потому как поддержки данного мегапопулярного сервиса у них нет.
Иногда замечал что DNS от Google глючит, обычно все решается заменой на OpenDNS.
А я порекомендую www.censurfridns.dk/ и www.ccc.de/censorship/dns-howto
Хабраэффект или они уже загнулись? :)
А теперь сравните время отклика от предлагаемых Вами серверов:
И от тех же публичных серверов Яндекса и Гугла:
$ time host 89.233.43.71
71.43.233.89.in-addr.arpa domain name pointer ns1.censurfridns.dk.
real 0m0.340s
user 0m0.012s
sys 0m0.000s
$ time host 213.73.89.122
122.89.73.213.in-addr.arpa domain name pointer www.ccc.de.
real 0m1.859s
user 0m0.012s
sys 0m0.000s
И от тех же публичных серверов Яндекса и Гугла:
$ time host 77.88.8.8
8.8.88.77.in-addr.arpa domain name pointer dns.yandex.ru.
real 0m0.063s
user 0m0.004s
sys 0m0.004s
$ time host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com.
real 0m0.073s
user 0m0.012s
sys 0m0.000s
valdikss@valaptop ~ % time host 213.73.89.122
122.89.73.213.in-addr.arpa domain name pointer www.ccc.de.
host 213.73.89.122 0.01s user 0.01s system 33% cpu 0.040 total
valdikss@valaptop ~ % time host 89.233.43.71
71.43.233.89.in-addr.arpa domain name pointer ns1.censurfridns.dk.
host 89.233.43.71 0.01s user 0.00s system 19% cpu 0.034 total
valdikss@valaptop ~ % time host 77.88.8.8
8.8.88.77.in-addr.arpa domain name pointer dns.yandex.ru.
host 77.88.8.8 0.01s user 0.00s system 9% cpu 0.104 total
valdikss@valaptop ~ % time host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com.
host 8.8.8.8 0.01s user 0.00s system 21% cpu 0.062 total
Это не время отклика ОТ предлагаемых серверов, это время ресолва PTR записей о них вашим дефолтным DNS.
Правильно так:
Правильно так:
$ time host ufsin45.ru 89.233.43.71
;; connection timed out; no servers could be reached
host ufsin45.ru 89.233.43.71 0.00s user 0.00s system 0% cpu 10.009 total
$ time host ufsin45.ru 213.73.89.122
;; connection timed out; no servers could be reached
host ufsin45.ru 213.73.89.122 0.00s user 0.01s system 0% cpu 10.015 total
$ time host ufsin45.ru 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases:
ufsin45.ru has address 85.249.4.35
ufsin45.ru mail is handled by 10 mail.ufsin45.ru.
host ufsin45.ru 77.88.8.8 0.00s user 0.00s system 6% cpu 0.145 total
$ time host ufsin45.ru 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
Host ufsin45.ru not found: 3(NXDOMAIN)
host ufsin45.ru 8.8.8.8 0.00s user 0.00s system 5% cpu 0.157 total
У меня как-то не резолвился гуглом pop.mtu-net.ru
Остальными DNS-серверами резолвился, NS-ы пахали.
Решил, что это разовый случай или косяки админов МГТС-а, прописал в HOSTS
Остальными DNS-серверами резолвился, NS-ы пахали.
Решил, что это разовый случай или косяки админов МГТС-а, прописал в HOSTS
И, судя по увеличивающимся запросам на форумах по продуктам Google, эта проблема набирает обороты и, возможно, скоро еще один бесплатный сервис Корпорации Добра канет в лету…
По ссылке, что Вы привели — 6 топиков.
2 из которых от 2012 года, 2 — 2011 года и еще 2 этого года один из которых проблема локальная о недоступности самих ДНС, второй-же скорее относится к Google Apps, нежели чем к ДНС.
Итого: где вы увидели «увеличивающиеся запросы на форумах по продуктам Google»?
Чуть ли не в половине стран провайдеры фильтруют/модифицируют трафик, включая ДНС запросы. Ничего удивительного, что, всё чаще, ДНС серверы не могут достучаться друг до друга. Со временем будет только хуже.
Я ставлю 8.8.8.8 вторым провайдерский НС, а если есть возможность и третий: 208.67.222.222
Никто не запостил, а надо:
А в гугл ли дело?
Я не сисадмин, но разве так должно быть? Ваш NS вроде должен отдавать мне ответ.
set type=ns
> ufsin45.ru
Сервер: resolver1.opendns.com
Address: 208.67.222.222
Не заслуживающий доверия ответ:
ufsin45.ru nameserver = ns2.nameself.com
ufsin45.ru nameserver = ns1.nameself.com
> server ns1.nameself.com
Сервер по умолчнию: ns1.nameself.com
Addresses: 2001:1bb0:e000:15::7
81.176.95.18
195.64.155.90
> set type=a
> ufsin45.ru
Сервер: ns1.nameself.com
Addresses: 2001:1bb0:e000:15::7
81.176.95.18
195.64.155.90
*** ns1.nameself.com не удалось найти ufsin45.ru: No response from server
Я не сисадмин, но разве так должно быть? Ваш NS вроде должен отдавать мне ответ.
Конечно не должно так быть! Спасибо, вот это я смогу уже предъявить регистратору. Еще бы указали Ваше примерное местоположение, потому что из всех мест, которые мне доступны (не только свой регион), ns-ки nameself.com отвечают исправно и бодро
Москва, домашний интернет «Билайн»
А выше FractalizeR не то же самое сказал, на что вы ответили, что дело не в этом?
Неоднократно были проблемы с клиентскими доменами на nsX.nameself.com, бывает что на первый запрос они не отвечают. Методика исследования была следующая:
— взял список доменов с statonline.ru/domains?tld=ru&dns=ns1.nameself.com
— по очереди начал спрашивать об этих доменах nsX.nameself.com
Проблема в игнорировании запросов чаще всего встречалась на недавно зарегистрированных доменах, но и на старых тоже иногда проявлялась. Складывается впечатление, что малозапрашиваемые домены вытесняются из кеша, а «холодный» поиск зоны слишком затягивается.
Исследование проводил 2 года назад, через неделю после исследования nsX.nameself.com исправились, но, видать, проблема до сих пор актуальна.
— взял список доменов с statonline.ru/domains?tld=ru&dns=ns1.nameself.com
— по очереди начал спрашивать об этих доменах nsX.nameself.com
Проблема в игнорировании запросов чаще всего встречалась на недавно зарегистрированных доменах, но и на старых тоже иногда проявлялась. Складывается впечатление, что малозапрашиваемые домены вытесняются из кеша, а «холодный» поиск зоны слишком затягивается.
Исследование проводил 2 года назад, через неделю после исследования nsX.nameself.com исправились, но, видать, проблема до сих пор актуальна.
Есть несколько десятков доменов от webnames (нски nameself.com). От Google Webmaster Tools стабильно и очень регулярно приходят письма, что не может отрезолвить какой-то немалый процент запросов при обходе поисковыми ботами сайтов.
Т.е. с nameself.com и Google беда постоянная и не только с вашим доменом.
Т.е. с nameself.com и Google беда постоянная и не только с вашим доменом.
Да, но почему так выборочно? т.е. часть доменов для части DNS-серверов ресолвятся, а часть фейлится… Очень непонятная ситуация.
За последнюю неделю на Google webmasters несколько раз получил сообщения такого рода:
Видать проблема в их ДНС
робот Googlebot не может получить доступ к вашему сайту
Число ошибок за последние 24 ч. при попытке робота Googlebot получить информацию DNS для вашего сайта: 30426. Общая доля ошибок при запросах DNS для вашего сайта составляет 58.2%.
Видать проблема в их ДНС
Новые санкции? :)
Гуглу можно жаловаться тут:
https://groups.google.com/forum/#!forum/public-dns-discuss
code.google.com/a/google.com/p/public-dns/issues/list
И они даже отвечают
Тут есть ссылки и советы: developers.google.com/speed/public-dns/groups
У них ещё есть сервис для сброса кеша для отдельных записей: developers.google.com/speed/public-dns/cache
https://groups.google.com/forum/#!forum/public-dns-discuss
code.google.com/a/google.com/p/public-dns/issues/list
И они даже отвечают
Тут есть ссылки и советы: developers.google.com/speed/public-dns/groups
У них ещё есть сервис для сброса кеша для отдельных записей: developers.google.com/speed/public-dns/cache
Давайте администраторы сами решат какая полиси у них допустима, а какая нет. Есть масса случаев, когда на восьмёрках всё отлично и не надо возиться со своим ресолвером.
А почему хомячки ходят на ресурсы, не предусмотренные их трудовым регламентом с использованием вычислительных ресурсов работодателя? Ходят — пусть терпят политику.
Аналогично с корпоративной почтой. Работодатель имеет полное право на перлюстрацию любой входящей/исходящей почты на доменах организации.
Аналогично с корпоративной почтой. Работодатель имеет полное право на перлюстрацию любой входящей/исходящей почты на доменах организации.
А провайдер, по Вашему, не третье лицо?
Здесь же какой то гугль/опенднс/яндекс/хрен с горы, который нам ничего не должен, не обещалВообще-то обещал. А если вы считаете что его обещаниям верить нельзя, то с какого перепугу вы решили, что вашему провайдеру можно верить? Притом, что он зачастую ваш трафик отдаёт-таки третьему лицу не глядя?
То есть я ещё могу понять людей, у которых уровень паранойи зашкаливает и которые напрямую никуда не ходят, но бездумно доверять провайдеру и не доверять при этом Гуглу попросту глупо: Гугл, может, и передаст кому информацию если на него сильно надавят, но уж по крайней мере он это сделает сознательно, а информация от вашего провайдера будет доступна всем кому не лень просто потому, что там толком некому заниматься защитой ваших данных.
Потом он падает и клиенты сосут лапу без интернета.
У моего провайдера — да, регулярно. Потом это задолбало и я прописал у себя Google DNS.
Запрашивая ресурс по URL через публичные каналы связи, Вы, конечно, не шлете инфу:
— всем DNS по мере реселвинга
— исходящий запрос на ресурс через свой канал (у вас же PI и Вы сам себе голова?) или через своего провайдера (ой, а как с полиси быть?)
— хостеру, где лежит сайт (если хостер зачем-то мониторит канал)
— самому сайту, у которого вполне могут быть включены логи
— всем счетчикам на запрошенной странице, если Вы их не повырезали политикой у всех своих юзеров
— всех яндекс-барам и прочим закладкам, тьфу, удобным-для-юзера-фенечкам, что так стараются встать на машину (полиси-полиси, где ты!)
— яндекс-браузеру или гугл-хрому, которые, ой-ой, могут и отстучаться «на базу», что делает юзер в онлайне.
Но хорошо, пусть Вы в рамки своей полиси не влезли хоть чем-то (что, уверен, на 99.9999% правда), но что Вы вообще пытаетесь скрыть?
— всем DNS по мере реселвинга
— исходящий запрос на ресурс через свой канал (у вас же PI и Вы сам себе голова?) или через своего провайдера (ой, а как с полиси быть?)
— хостеру, где лежит сайт (если хостер зачем-то мониторит канал)
— самому сайту, у которого вполне могут быть включены логи
— всем счетчикам на запрошенной странице, если Вы их не повырезали политикой у всех своих юзеров
— всех яндекс-барам и прочим закладкам, тьфу, удобным-для-юзера-фенечкам, что так стараются встать на машину (полиси-полиси, где ты!)
— яндекс-браузеру или гугл-хрому, которые, ой-ой, могут и отстучаться «на базу», что делает юзер в онлайне.
Но хорошо, пусть Вы в рамки своей полиси не влезли хоть чем-то (что, уверен, на 99.9999% правда), но что Вы вообще пытаетесь скрыть?
Все, что Вы написали — отлично. Только как вы полиси на компанию натягиваете так, что и сайты у Вас все через TLS стали открываться, и хостеры их (всех сайтов) в вашем же городе поселились, и браузер стал только мозиллой?
Нет, в последнее я еще верю. Как варю и в том, что в DNS своем локальном (который рекурсор + немного «своих» записей) можно указать metrika.yandex.ru -> на адрес вашего локального веб-сервера, отдающего на любой запрос (хоть по TLS, хоть без) пустой ответ с кодом 200 и с сертификатом, которые все ваши местные мозиллы считают валидным. Даже верю, что Вы можете тогда договориться и протянуть кабель от своего офиса до той площадке, где в вашем городе стоят все сервера всех сайтов…
Как вариант, вы всей компанией можете ходить на один единственный сайт, и именно по TLS, а все остальное качественно блокировать- тогда политику проще сделать и разлить по машинам, факт.
Но все же — по воробьям ли пушка? Ну будут гуглы/яндексы знать из анализа DNS-запросов, что из города N приходит в сутки 1000 запросов на site.ru и 500 запросов на site.com — чем это Вам лично повредит? А если не «из города N», а «с адреса, которые ресолвится как gw.company.ru», это как-то меняет дело?
Паранойя — это неплохо. Как там была шутка, «то, что у меня паранойя, совсем не значит, что за мной никто не наблюдает»? Но все же в чем цимес не воспользоваться надежными DNS-ами, которые на порядок надежнее любого вашего сервера работают (ничего личного, просто там кластер посерьезнее)?
Нет, в последнее я еще верю. Как варю и в том, что в DNS своем локальном (который рекурсор + немного «своих» записей) можно указать metrika.yandex.ru -> на адрес вашего локального веб-сервера, отдающего на любой запрос (хоть по TLS, хоть без) пустой ответ с кодом 200 и с сертификатом, которые все ваши местные мозиллы считают валидным. Даже верю, что Вы можете тогда договориться и протянуть кабель от своего офиса до той площадке, где в вашем городе стоят все сервера всех сайтов…
Как вариант, вы всей компанией можете ходить на один единственный сайт, и именно по TLS, а все остальное качественно блокировать- тогда политику проще сделать и разлить по машинам, факт.
Но все же — по воробьям ли пушка? Ну будут гуглы/яндексы знать из анализа DNS-запросов, что из города N приходит в сутки 1000 запросов на site.ru и 500 запросов на site.com — чем это Вам лично повредит? А если не «из города N», а «с адреса, которые ресолвится как gw.company.ru», это как-то меняет дело?
Паранойя — это неплохо. Как там была шутка, «то, что у меня паранойя, совсем не значит, что за мной никто не наблюдает»? Но все же в чем цимес не воспользоваться надежными DNS-ами, которые на порядок надежнее любого вашего сервера работают (ничего личного, просто там кластер посерьезнее)?
Вы так много материтесь, что, несомненно, мыслите широко. Рукоплещу. Съел бы шляпу, только не ношу, простите.
Теперь о деле.
>… прописали 8.8.8.8… факт обмена письмами станет известен держателю днс сервера путём простейшего анализа.
Нет. Анализ покажет, что в ваших запросах, точнее, в DNS-запросах с вашего IP (часть из которых мог лететь с вашего IP на 8.8.8.8, часть — не к ним) присутствуют разные запросы и про имена domain.ru, mx.domain.ru. То же и про geekporn.nu — запрос совсем не значит, что Вы или я туда пошли.
Я вот для проверки коннективности могу написать ping yandex.ru — это не значит, что в этот момент (если локальный кеш пуст) иду на сайт яндекса браузером. Ровно так же попытка ресолвить playboy.com лично для меня значит, что я тестирую фильтрацию сайтов, а не являюсь завзятым поклонником этого сайта.
Знаете, Вы вот дышите, и выдыхаете в «общий» воздух. А ведь злой сосед может взять пробу воздуха, и понять, какой сорт пива (вина, чая, кофе) Вы пили, а в исторической перспективе — какой любите пить, и как часто ваш кот ест ту же еду, что и Вы сами. Т.е. сделать он это может, но — зачем?
P.S. С таким раскладом Вы себя в анальном рабстве у соседа не будете чувствовать? )
P.P.S. Сам сижу за unbound, который ту же фильтрацию позволяет делать, да еще много чего творить, но… Считаю, что для очень многих случаев 77.88.8.8 — отличное решение, просто потому, что анализ этот гроша для многих не стоит (точнее, стоит, но люди и так рассказывают о себе направо и налево), зато ваш рекурсор обслуживаете только вы (т.е. вероятность аптайма не 100%), и рекурсор яндекса все же понадежнее будет.
Теперь о деле.
>… прописали 8.8.8.8… факт обмена письмами станет известен держателю днс сервера путём простейшего анализа.
Нет. Анализ покажет, что в ваших запросах, точнее, в DNS-запросах с вашего IP (часть из которых мог лететь с вашего IP на 8.8.8.8, часть — не к ним) присутствуют разные запросы и про имена domain.ru, mx.domain.ru. То же и про geekporn.nu — запрос совсем не значит, что Вы или я туда пошли.
Я вот для проверки коннективности могу написать ping yandex.ru — это не значит, что в этот момент (если локальный кеш пуст) иду на сайт яндекса браузером. Ровно так же попытка ресолвить playboy.com лично для меня значит, что я тестирую фильтрацию сайтов, а не являюсь завзятым поклонником этого сайта.
Знаете, Вы вот дышите, и выдыхаете в «общий» воздух. А ведь злой сосед может взять пробу воздуха, и понять, какой сорт пива (вина, чая, кофе) Вы пили, а в исторической перспективе — какой любите пить, и как часто ваш кот ест ту же еду, что и Вы сами. Т.е. сделать он это может, но — зачем?
P.S. С таким раскладом Вы себя в анальном рабстве у соседа не будете чувствовать? )
P.P.S. Сам сижу за unbound, который ту же фильтрацию позволяет делать, да еще много чего творить, но… Считаю, что для очень многих случаев 77.88.8.8 — отличное решение, просто потому, что анализ этот гроша для многих не стоит (точнее, стоит, но люди и так рассказывают о себе направо и налево), зато ваш рекурсор обслуживаете только вы (т.е. вероятность аптайма не 100%), и рекурсор яндекса все же понадежнее будет.
У меня с Кипра он отресолвился, с OVH (Франция, собственный ресолвер) — нет.
А в чём он(c.dns.ripn.net.) виновник?
Такого узла в трэйсе нет
Такого узла в трэйсе нет
dig
# dig -t NS ufsin45.ru @8.8.8.8 +trace
; <<>> DiG 9.10.0-P2 <<>> -t NS ufsin45.ru @8.8.8.8 +trace
;; global options: +cmd
. 8481 IN NS h.root-servers.net.
. 8481 IN NS m.root-servers.net.
. 8481 IN NS b.root-servers.net.
. 8481 IN NS e.root-servers.net.
. 8481 IN NS f.root-servers.net.
. 8481 IN NS k.root-servers.net.
. 8481 IN NS l.root-servers.net.
. 8481 IN NS c.root-servers.net.
. 8481 IN NS i.root-servers.net.
. 8481 IN NS a.root-servers.net.
. 8481 IN NS g.root-servers.net.
. 8481 IN NS d.root-servers.net.
. 8481 IN NS j.root-servers.net.
. 8481 IN RRSIG NS 8 0 518400 20140923080000 20140916070000 8230. YN5/hkvFbV3QYm+vbTK78z3ywfUbQjfwmx4War88gfchyxE/GdY9ZwHf PduztMsvIc+RDOswlpQvdb4ZJ62+kbya/nFuY+ydrLREd3jqlr0ENRCZ kwGt4AZ058HccexOiP2EnCIiFBgIsfX2diGO2hJWgWPSPCRjudEkvNaJ cpc=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 262 ms
ru. 172800 IN NS f.dns.ripn.net.
ru. 172800 IN NS d.dns.ripn.net.
ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS b.dns.ripn.net.
ru. 172800 IN NS a.dns.ripn.net.
ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru. 86400 IN RRSIG DS 8 1 86400 20140923080000 20140916070000 8230. SvrUGQY+rnY285vSiCx2cqpXA2bUhlirORiCW/vOqrZXkh66eNNmoTu2 8SAVLQNZtBwShZTAMZDx6it/BWFlNDawBH0SDuiBM/xjRpiNhiMReali MTMHQZFGqarEea5VSUTVy5NvIl21D59A1Noh73UbCLp5YnUW3jYHmyYV QNw=
;; Received 558 bytes from 192.5.5.241#53(f.root-servers.net) in 133 ms
ufsin45.ru. 345600 IN NS ns1.nameself.com.
ufsin45.ru. 345600 IN NS ns2.nameself.com.
ufsin45.ru. 345600 IN DS 51586 8 1 E15D816549C093423C97AC2AEA8BA67B189C5C2B
ufsin45.ru. 345600 IN RRSIG DS 8 2 345600 20141008143205 20140824142457 43590 ru. VWoK1Th+eBOouL2EpGxYAAom7r+9Rg20BJAZdM08GPl7Uo/LeZPRSUv0 poq4ya68ABOcvV76DtiWeMAk2WDZME9pXJMSIMPXR2P5FoGwZbaPx5Ap 0QC0RFfaJGCPwTTg9/3AnLo9x5E4rlROJmdJbE8kvTdol7Bj0MAhNbJS hZU=
;; Received 285 bytes from 193.232.156.17#53(f.dns.ripn.net) in 308 ms
ufsin45.ru. 28800 IN NS ns1.nameself.com.
ufsin45.ru. 28800 IN NS ns2.nameself.com.
ufsin45.ru. 28800 IN RRSIG NS 8 2 28800 20140502113343 20140402113343 64269 ufsin45.ru. nVVrLtD7qxuWSNnlJGJNWh+BCVlkEiAe4afPLBpa/xQEsvbTKEj43C/C 3BYTIehjpz1P4fYO4LS7MLj3WCLw3La414ix6bMEUO8gktu9WJew+9lG 90Wqfu9OYiT59R+icwOplaGA6pM9C9Y2tA44AgefcfEonDF+WLjbileF uyY=
;; Received 865 bytes from 77.221.159.237#53(ns2.nameself.com) in 60 ms
; <<>> DiG 9.10.0-P2 <<>> -t NS ufsin45.ru @8.8.8.8 +trace
;; global options: +cmd
. 8481 IN NS h.root-servers.net.
. 8481 IN NS m.root-servers.net.
. 8481 IN NS b.root-servers.net.
. 8481 IN NS e.root-servers.net.
. 8481 IN NS f.root-servers.net.
. 8481 IN NS k.root-servers.net.
. 8481 IN NS l.root-servers.net.
. 8481 IN NS c.root-servers.net.
. 8481 IN NS i.root-servers.net.
. 8481 IN NS a.root-servers.net.
. 8481 IN NS g.root-servers.net.
. 8481 IN NS d.root-servers.net.
. 8481 IN NS j.root-servers.net.
. 8481 IN RRSIG NS 8 0 518400 20140923080000 20140916070000 8230. YN5/hkvFbV3QYm+vbTK78z3ywfUbQjfwmx4War88gfchyxE/GdY9ZwHf PduztMsvIc+RDOswlpQvdb4ZJ62+kbya/nFuY+ydrLREd3jqlr0ENRCZ kwGt4AZ058HccexOiP2EnCIiFBgIsfX2diGO2hJWgWPSPCRjudEkvNaJ cpc=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 262 ms
ru. 172800 IN NS f.dns.ripn.net.
ru. 172800 IN NS d.dns.ripn.net.
ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS b.dns.ripn.net.
ru. 172800 IN NS a.dns.ripn.net.
ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru. 86400 IN RRSIG DS 8 1 86400 20140923080000 20140916070000 8230. SvrUGQY+rnY285vSiCx2cqpXA2bUhlirORiCW/vOqrZXkh66eNNmoTu2 8SAVLQNZtBwShZTAMZDx6it/BWFlNDawBH0SDuiBM/xjRpiNhiMReali MTMHQZFGqarEea5VSUTVy5NvIl21D59A1Noh73UbCLp5YnUW3jYHmyYV QNw=
;; Received 558 bytes from 192.5.5.241#53(f.root-servers.net) in 133 ms
ufsin45.ru. 345600 IN NS ns1.nameself.com.
ufsin45.ru. 345600 IN NS ns2.nameself.com.
ufsin45.ru. 345600 IN DS 51586 8 1 E15D816549C093423C97AC2AEA8BA67B189C5C2B
ufsin45.ru. 345600 IN RRSIG DS 8 2 345600 20141008143205 20140824142457 43590 ru. VWoK1Th+eBOouL2EpGxYAAom7r+9Rg20BJAZdM08GPl7Uo/LeZPRSUv0 poq4ya68ABOcvV76DtiWeMAk2WDZME9pXJMSIMPXR2P5FoGwZbaPx5Ap 0QC0RFfaJGCPwTTg9/3AnLo9x5E4rlROJmdJbE8kvTdol7Bj0MAhNbJS hZU=
;; Received 285 bytes from 193.232.156.17#53(f.dns.ripn.net) in 308 ms
ufsin45.ru. 28800 IN NS ns1.nameself.com.
ufsin45.ru. 28800 IN NS ns2.nameself.com.
ufsin45.ru. 28800 IN RRSIG NS 8 2 28800 20140502113343 20140402113343 64269 ufsin45.ru. nVVrLtD7qxuWSNnlJGJNWh+BCVlkEiAe4afPLBpa/xQEsvbTKEj43C/C 3BYTIehjpz1P4fYO4LS7MLj3WCLw3La414ix6bMEUO8gktu9WJew+9lG 90Wqfu9OYiT59R+icwOplaGA6pM9C9Y2tA44AgefcfEonDF+WLjbileF uyY=
;; Received 865 bytes from 77.221.159.237#53(ns2.nameself.com) in 60 ms
А не находили ли Вы сервисов, которые могли бы отресолвить заданный домен через DNS разных стран и построить хотя бы примерную карту неработоспособности сервиса?
Спасибо!
Из 21 сервера, не смогли отресолвить только 4. Два в Америке (один из них, как раз Гугл), один в Канаде и один в Бразилии.
Осталось найти причину и исправить /sarcasm :)
Из 21 сервера, не смогли отресолвить только 4. Два в Америке (один из них, как раз Гугл), один в Канаде и один в Бразилии.
Осталось найти причину и исправить /sarcasm :)
В свое время была отличная статья:
habrahabr.ru/post/159013/
Пользуюсь этой штуковиной. Очень доволен.
Суть в том, что можно настроить в единый кэш ответов от 8.8.8.8, и от провайдерских DNS, и от яндексовых DNS и т.д.
habrahabr.ru/post/159013/
Пользуюсь этой штуковиной. Очень доволен.
Суть в том, что можно настроить в единый кэш ответов от 8.8.8.8, и от провайдерских DNS, и от яндексовых DNS и т.д.
Не уверен, что это поможет в данном конкретном случае. Что если Гугл вернет ответ о несуществующем домене первым?
Цитата из статьи:
Именно включение параллельного опроса и дает нам основное преимущество в скорости, т.к. при нахождении результата в кеше любого из провайдеров мы получаем результат очень быстро, и не ждем полного и медленного разресолвивания если у первого провайдера нет ответа в кэше.
Ну так в том-то и дело, что от гугла будет ответ в кеше. Ответ NXDOMAIN.
PDNSD — опросит все DNS, какие у него есть в конфиге.
Опросит одновременно.
И если хотя бы один неймсервер ответит положительно о домене, то именно его он и закеширует у себя.
Если все DNS зоны скажут, что мол мы не знаем такой домен, то там есть для этого вот такая опция в конфиге:
Все это можно увидеть своими глазами.
Как это происходит.
Достаточно набрать:
Опросит одновременно.
И если хотя бы один неймсервер ответит положительно о домене, то именно его он и закеширует у себя.
Если все DNS зоны скажут, что мол мы не знаем такой домен, то там есть для этого вот такая опция в конфиге:
neg_ttl=1m; //Время кеширования отрицательных ответов (т.е. если домен не найден)
Все это можно увидеть своими глазами.
Как это происходит.
Достаточно набрать:
ngrep -W byline -d lo host 127.0.0.1 and port 53
вот беру карту рут серверов root-servers.org/ смотрю какие ближе к дому, проверяю и ставлю их вторым яндекс
Может быть оно и правильно, что сайт УФСИН не резолвится :)
Чисто с технической точки зрения — если есть, должно работать, ну а моральную каждый сам выбирает для себя. Хотя, если честно, собственно сам сайт умер уже года два как, когда сделали единый портал fsin.su. Сейчас A-запись домена ufsin45.ru содержит адрес именно центрального ресурса. Все дело в почте. Вот ее функциональность терять не хочется.
Хмм, похоже у ребят из nameself.com руки кривы чуть менее, чем полностью. Например, их серверы, обслуживающие ваш домен, не отвечают по TCP. Вопреки расхожему мнению протокол DNS использует TCP не только для трансфера зоны между master и slave серверами.
Давно уже везде использую dns.yandex.ru: надежность есть (у них как-то доступ из России побыстрее, чем до 8.8.8.8/8.8.4.4), варианты фильтрации есть («просто», «без гадких», «для детей»), кушать не просит.
Мне как-то проще 77.88.8.1/77.88.8.8 вписать. От них еще один плюс, кстати — когда надо пинговать доступность внешнего хоста из скрипта, пинг на 8.8.8.8 иногда, а прерывается (видно, точно далеко), причем маршрут идет за рубеж, и пинг на 8.8.8.8 не означает доступность российских ресурсов. А вот на 77.88.8.8 пинг идет по России, и не дает ложных сбоев — красота!
Спасибо Яндексу, в общем
Мне как-то проще 77.88.8.1/77.88.8.8 вписать. От них еще один плюс, кстати — когда надо пинговать доступность внешнего хоста из скрипта, пинг на 8.8.8.8 иногда, а прерывается (видно, точно далеко), причем маршрут идет за рубеж, и пинг на 8.8.8.8 не означает доступность российских ресурсов. А вот на 77.88.8.8 пинг идет по России, и не дает ложных сбоев — красота!
Спасибо Яндексу, в общем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Public DNS не ресолвит некоторые домены