Pull to refresh

Comments 65

UFO just landed and posted this here
Я сравнил скорость пинга до гугловского ресолвера с тем, который я использую, и результат говорит не в пользу гугля:
amarao@home:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=42.6 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=43.1 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=60.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 42.640/48.695/60.318/8.222 ms
amarao@home:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.042 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.024 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.026 ms
^C


Свой ресолвер — самый хороший.
UFO just landed and posted this here
у любого крупного провайдера есть свой днс и пинг до него меньше, не так ли?
LOLWUT? Кеширование в ДНС не может быть лучше или хуже. Оно ровно такое, какое прописал значение TTL владелец каждого конкретного домена.
Ну что вы, у гугла в любом случае лучше :)
Поэтому когда я меняю ns сервера у домена или резко пол зоны редактирую у меня с OpenDNS и Google P-DNS апдейты появляются как надо, а человека для кого я это делал спустя 2 дня? При том, что TTL в самом крайнем случае у меня стоит 1 час, а обычно меньше.
смена ns подчиняется не твоим TTL, а TTL родительского домена.
Я в курсе, товарищ майор. Поэтому привел пример когда заменил зону, а днс многих провайдер не обновляли информацию в течении дня. Что касается смена ns серверов — почему гугл/опенднс увидели изменения как положено, а провайдерский днс почти неделю выдавал старые данные?

ИТТ краткий курс вежливости (/0):
1) предложение начинается с большой буквы;
2) с незнакомым человеком на «ты» не говорят;
3) текст читается полностью, и только потом пишется ответ.
Товарищ прапорщик, что такое «заменил зону»? Отвечать старшему по званию незамедлительно!
Товарищ, вы не видите я генерал-майор?
> Товарищ прапорщик, что такое «заменил зону»?
Это когда я беру свои 50 A и CNAME записей и меняю 30 из них. Причем если я это делаю это на mastername, то это еще плюс 2 часа к обновлению, а если делаю в Zerigo, то это происходит согласно TTL который я указал.
Это называется не «заменил зону», а «внес изменения в записи зоны», товарищ прапорщик.
Открою маленький секрет, есть еще такое понятие, как периодичность синхронизации слейв-серверов с мастерами. Путем нехитрых экспериментов ты выяснил, что у мастерхоста этот период равен 2 часам. В более продвинутых ДНС-сервисах, где думают головой и заботятся о клиентах, синхронизация между ns-серверами сервиса происходит фактически без задержек.
> Это называется не «заменил зону», а «внес изменения в записи зоны», товарищ прапорщик.

Семантика — шмантика.

> Открою маленький секрет, есть еще такое понятие, как периодичность синхронизации слейв-серверов с мастерами. Путем нехитрых экспериментов ты выяснил, что у мастерхоста этот период равен 2 часам. В более продвинутых ДНС-сервисах, где думают головой и заботятся о клиентах, синхронизация между ns-серверами сервиса происходит фактически без задержек.

Итого мы выяснили, что есть большая разница между NS серверами от васи пупкина и NS серверами от Zerigo. Таки же этими манипуляция выясняется, что резолверы провайдера работают далеко не так хорошо как резолверы OpenDNS/Google.
Ох, проблема посерьезнее… Давай, начни-ка с матчасти, что такое резолвер, что такое авторитетный сервер, что такое мастер и слейв и чем они отличаются от первичного и вторичных ns-серверов.
По итогам изучения будет экспресс-экзамен, по его итогам и продолжим общение. А пока у тебя банально проблема с терминами и пониманием процесса работы распределенной базы интернет-имен, а не с семантикой, бро.
Это у вас проблема с понимаем. Имеет 2 сценария.
Сценарий А:
Изменяю ns сервера у домена. Нормальные DNS сервера возвращают правильные данные с минимальной задержкой. Сервера от провайдера (и прочие) с задержкой (доходит до недели).
Сценарий Б:
Меняю записать в DNS, с TTL в 1 час. Нормальные сервера в течении часа начинают возвращать свежие данные. Сервера от провайдера тупят и не обновляют кэш как положено.

Если у вас проблема с чтением то тут:
«Итого мы выяснили, что есть большая разница между NS серверами от васи пупкина и NS серверами от Zerigo. Таки же этими манипуляция выясняется, что резолверы провайдера работают далеко не так хорошо как резолверы OpenDNS/Google.»

Описаны выводы из 2х разных проблем. Но у вас же шило в жопе, которое не дает вам понять о чем я говорю. Вы же видите слова рядом с одном абзаце и пытаетесь связать их без осмысления. И вот уже которое сообщение не можете их связать правильно. Я понимаю, что мой русский за 3 года стал не таким понятным, но все же…
Давай по-другому попробуем. Ты явно не хочешь изучить матчасть и достигнуть просветления, тем самым самостоятельно поняв суть твоих проблем с ДНС.
Давай сюда те домены, с которыми у тебя возникали проблемы и я тебе скажу, почему именно.
> Давай по-другому попробуем. Ты явно не хочешь изучить матчасть и достигнуть просветления, тем самым самостоятельно поняв суть твоих проблем с ДНС.

Ты мне говоришь, что не важно к какому DNS серверу я обращаюсь, он вернет мне правильную А запись, так как у записи есть TTL и сервер должен инвалидировать кэш согласно этому TTL. Я тебе говорю, что в нашем несовершенном мире все не так. Я не знаю как ты мне докажешь, то что все DNS сервера работают одинаково, если я сам фиксил bind, чтобы он забивал на TTL.

Вот примеры доменов:
sinrah.ru
sibrados.ru (вот этот в течении недели после регистрации был недоступен для тех кто использовал днс прова, просил несколько людей сделать это, в то время как те кто использует гугловские и opendns, и cox'овские dns уже могли открыть сайт)
sibrados.com
24boards.ru
avral.pro (этот сменил свою А запись только 1 раз, у меня и тех кто использует нормальный DNS сервер все открылось согласно TTL, у человека чей это сайт — был не доступен почти двое суток, при этом с телефона, используя dns оператора, открывался)
я сам фиксил bind, чтобы он забивал на TTL
Вот это единственное объяснение, почему же у некоторых провов так хреново обновляются ДНС-записи. Таких недоадминов надо выискивать и публично предавать оскоплению тупым, ржавым ножом. Один уже спалился.
у человека чей это сайт — был не доступен почти двое суток, при этом с телефона, используя dns оператора, открывался)
Это очевидный баг локального резолвера. Какая ОС была на компе клиента-то?
Хороший, годный срачик. Слежу с интересом.
Давай сюда те домены, с которыми у тебя возникали проблемы и я тебе скажу, почему именно.

Ваш оппонент предоставил пять доменов, Ваш ход.
Сорри за задержку, я сейчас в датацентре одного из заказчиков, не до хабра было.
Глянул бегло на домены, есть небольшие проблемы с некоторыми ns-серверами, не слишком критичные, например, ns-ы яндекса (dns1.yandex.ru, dns2.yandex.ru) сами не знают А-запись о самих себе и друг-дружке. Та же проблема у мажордомо. Это вносит некоторую задержку в их работу, но в целом, не должно вызывать проблем, длящихся днями.
Проблемы подобного рода желательно изучать пока они, собственно, есть, т.к. днс-хостеры могли уже исправить ошибки в настройках, которые вызывали проблемы (наиболее частая причина — слишком большое значение SOA REFRESH, из-за нее разные резолверы по миру тыкаясь на разные ns-сервера с разными версиями dns-зоны, обновляют свой кеш старыми данными). А про недавний довольно эпичный фейл яндексовых ns-ов я думаю и вовсе не стоит напоминать.
Вторая вероятная причина с «некоторыми home-провайдерами» возникает по причине, которую Zelgadis сам же указал выше — это лишенные мозга сисадмины, которые патчат свои NS-ы с целью заставить их нарушать штатную работу протокола. Эту проблему трудно вычислить и трудно что-то с ней поделать. Один из вариантов решения я также описал чуть выше.
Третья вероятная причина задержек «в дни» связана с багами в локальных резолверах, когда кеш не сбрасывается по истечении TTL. Лечится чаще всего рестартом компа/сети либо командой наподобие ipconfig /flushdns (если это винды).
Все верно, но я несколько раз сталкивался с провайдерами которые не предупреждая меняли IP DNS.
Не обязательно, у моего провайдера DNS дико тормозит, и часто пакеты вообще теряются. Поэтому пользуюсь гугловскими. И вообще, всегда можно протестировать скорость DNS с помощью namebench
Есть, но в некоторых случаях Google DNS может быть удобнее:
1. Я сменил ns у домена. В случае с Google я смогу получить доступ к сайту через 10-15 мин, в случае использования dns провайдера через 24 часа. Конечно, hosts никто не отменял, но всякое бывает.
2. Почему-то у моего провайдера собственный dns периодически падает или лагает. Думаю, такая проблема не у меня одного, в таком случае использование public DNS оправдано.
Угу и этот DNS крупного провайдера периодически падает. Гугловский DNS пока что ни разу за таким замечен небыл…
А какой смысл поднимать у себя на машине dns-сервер? Пока на ум приходит только тестирование интернет-сервисов работающих на той-же машине, выходящее за рамки /etc/hosts. Поясните пожалуйста.
если у тебя один комп — никакого смысла поднимать свой рекурсор нет смысла. Если это сеть, где много машин, то имеет смысл с целью сократить задержки резолвинга (а за счет этого и в целом немного ускорить работу с Интернет) за счет кеширования на твоем локальном сервере, до которого отклик у пользователей не 90мс, а 1мс.
Это понятно. Но в выложенном amarao логе, пингуется именно localhost, крайне маловероятно, что его рабочий компьютер по совместительству служит dns-сервером для локальной сети, да к тому-же имеет не характерное для хоста с таким функционалом hostname — home.
ну, у техногиков свои причуды, может у него dnsmasq поднят на локалхосте. Но необходимости в этом немного.
У меня этим занимается роутер…
у 96% населения этим занимается роутер.
Подавляющее большинство этих 96 даже не знают об этом))
тем лучше для них, кстати.
Роутер — кешированием?

Почти наверняка не кеширует, а (прозрачно) перенаправляет DNS провайдера (или в CDN того же Гугла, если именно они указаны в настройках).
Вы когда нить заглядывали во внутренности роутера? Не скажу за все, но на большинстве стоит Linux. И крутится dnsmasq. Кеширующий DNS сервер. Или нет?

Да, конечно, он данные выдёргивает с провайдерского DNS. Но кеширует их у себя, нет?
Очень очень сильно от ресурсов зависит.

На многих домашних железках памяти кот наплакал, так что и лишнего софта там нет, и память кешем стараются не забивать. И порой мало того что не кешируют, так просто NAT настраивают на проброс DNS-запросов из внутренней сети во внешнюю, а иногда и того проще, в DCHP ответах отдают сразу внешний(е) DNS-сервер(а), а не «себя». Я, конечно, не говорю о dd-wrt и подобном ПО, я про прошивки по-умолчанию.

Ибо, в принципе, для «дома» разницы в том, запомнит ли роутер, чему равен www.google.com, особой нет, ибо (почти) каждый клиент ответ этот закеширует еще и у себя.

Впрочем, кому какие роутеры попадались )
Мы проводили тестирование открытых резолверов на предмет какой шустрее при разрешении кэшированного имени и некэшированного. Результат — самый быстрый резолвер тот, который ближе. Безотносительно размера кэша.
надо тестировать не пинг, а скорость ответа ДНС сервера.
У гугла есть специальная программка для теста этого.
Вобщем гугл рулит. Раньше меня бесили ДНС провайдера, они периодически переставали работать без каких либо причин и я иногда дописывал ОпенДНС вторым. Теперь я везде ставлю 8.8.8.8 в качестве основного, а резервный оставляю провайдерский. И все просто работает.
Тестируем:

time dig yahoo.co.jp +short
124.83.187.140
203.216.243.240

real 0m0.072s
user 0m0.004s
sys 0m0.000s

time dig ebay.co.jp +short @8.8.8.8
222.73.220.178

real 0m0.348s
user 0m0.008s
sys 0m0.004s
Вам показали локальный DNS-рекурсор, а провайдеры… такие провайдеры, у них может падать.
По вашей ссылке указано, что гугл тоже поддерживает данное расширение протокола DNS, а в статье, что нет. Так как на самом деле?
Конечно поддерживает, если он же и предложил. Сорри, нечётко выразился в тексте.
То бишь когда гугля с опенднс с их драфтом (http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01) вполне заслуженно послали к черту и закидали какашками, они решили сделать это в своей маленькой уютной экосистеме. Ну что ж, вполне логично.
Ух ты, я и не знал адресов IPv6 DNS серверов Гугля. Спасибо, отлично.
Нашим бы разрекламированным регистраторам и провайдерам хостинга (не будем показывать пальцем) такую надежность и устойчивость к нагрузкам!

P.S. «более эффективно направлять пользователей на ближайшие CDN конечной точки» — запутанно как-то. «на ближайшие к пользователю узлы CDN», может как-то так?
А ещё это самый удобный адрес для проверки сети, ping 8.8.8.8. Можно спорить, быстрее ли набирается, чем ya.ru.
очевидное преимущество 8.8.8.8 перед ya.ru — можно тестить коннективити еще до того, как настроил ДНС в сети или на хосте.
и не увидеть проблемы с днс.
Во многих случаях резолвер на хосте и вовсе не нужен. Речь про те случаи, когда ты сам в курсе, что еще не настроил ДНС (либо в нем нет необходимости), разве не очевидно?
Есть ещё удобней: ping 4.8
;)
В 2009 году, я нарадоваться не мог на 8.8.8.8
Буквально месяц назад отказался от него почти полностью.
За последние пол года — регулярные пропадания из доступа,
прыгающие пинги от приемлемых до совершенно невразумительных.

Это anycast, тут ничего удивительного — он связывает Вас с ближайшим к Вам сервером, но не факт, что от Вас и до этого сервера вообще-то есть устойчивая нормальная связь. Ну и растут ребята, это тоже надо понимать.
Когда уже гугл сделает днс-хостинг, жду не дождусь.
UFO just landed and posted this here
Им бы еще
1) Адрес более запоминающийся
2) Несколько датацентров по стране с выбором ближайшего

А так — вообще молодцы, через них хоть как-то можно зафильтровать левые сайты.
Хороший сервис, конечно. Но не резолвит retracker.local ;) Поэтому дома только dns провайдера
можно отредактировать hosts файл, добавив туда запись retracker.local и соответствующий ip адрес ретркера.
как ему его ресолвить? он же у всех разный.
Для дома, когда не меняете постоянно провайдера, данный способ подойдет.
Узнать адрес ретрекера провайдера просто:

nslookup retracker.local *ip DNS провайдера*

или

dig retracker.local +short @*ip DNS провайдера*
Добавьте его в исключения на OpenDNS, и вторым dns-сервером пропишите у себя провайдерский.
Правда получится только если у вас внешний адрес постоянный, и если его уже никто не зарегистровал.
Писать им не пробовали, мол? ))
Sign up to leave a comment.

Articles