Любая ошибка в публикации DNS записей или даже кратковременная неработоспособность этого сервиса может привести к весьма печальным результатам, например потери трафика от пользователей. С другой стороны DNS исключительно хорошо масштабируется и толерантен к сбоям единичных серверов.
DNS важен, профессионалы это понимают. И несмотря на это ошибки в управлении им встречаются даже у самых больших компаний. И не замечаются ими, пока не приводят к существенным проблемам.
Например, список DNS ошибок у не требующей представления компании Вконтакте:
У регистратора vk.com указан следующий список авторитативных серверов домена:
- ns1.vkontakte.ru
- ns2.vkontakte.ru
- ns3.vkontakte.ru
- ns4.vkontakte.ruНа самих авторитативных серверах Вконтакте указан следующий список:
- ns1.vkontakte.ru
- ns2.vkontakte.ru
- ns4.vkontakte.ruОн отличается от списка у регистратора!
Более того сервер
ns2.vkontakte.ru [93.186.224.100] не отвечает на запросы, по крайней мере уже несколько дней.Ошибка Skype и Microsoft:
В ответах на запросы к cloudapp.net не возвращается Authority Section.
В частности в ответе на тип запроса “
AAAA” к skypeecs-prod-euw-0-b.cloudapp.net. Из за этого негативный ответ на такой запрос нельзя кешировать, так как непонятно насколько по времени это можно сделать, если строго соблюдать RFC.Ошибка Twitter и Dyn:
В ответах на запросы к platform.twitter.com при типе запросов
NS сервера Dyn, обслуживающие Twitter отвечают что такой записи не существует. При этом на любой другой тип запросов к этому же имени они отвечают записью CNAME.Соответственно, если у нас уже закеширован этот ответ на тип запроса
NS то, если строго соблюдать стандарты RFC, мы не можем закешировать CNAME в ответе к этому же имени для других типов запросов. Собственно в этом случае поведение кеширующего рекурсивного сервера не детерминировано по стандартам и отдано на откуп собственной логике программиста.Ошибок у перечисленных компаний больше чем описано в данной статье, но из за нежелания перегружать статью я позволил себе их не публиковать.
Все опубликованные ошибки были актуальны на 7 Мая 2016. В тот момент когда вы будете читать эту статью их может уже не быть.
Комментарии (29)
swood
08.05.2016 00:01+4Спасибо за репорт. Исправили ns2.vkontakte.ru.
firehunt
08.05.2016 00:38Пользуясь случаем хочу спросить, в чем логика отличия списка NS серверов, которые прописаны у регистратора и опубликованы в зоне com для домена vk.com, от списка NS серверов в зоне vk.com?
Та же история, с вариациями на тему отсутствующих в списке NS записей, прослеживается для доменов vkontakte.ru и vkadre.ru.
Во всех перечисленных доменов у регистраторов присутствует 4 записи, а на авторитативных серверах Вконтакте присутствуют только три записи.
zedalert
08.05.2016 15:41+6Несколько дней назад не резовлилось имя сайта одной популярной во всём мире пиццерии (а кушать то хотелось), провайдер, гугл и яндекс клялись, что такого сайта не существует. Пришлось сделать запрос к DNS серверу регистратора, после запроса whois, и на время добавить в hosts.
? \ _ (?) _ / ?
imrunner
08.05.2016 21:59+1«из за нежелания перегружать статью я позволил себе их не публиковать»
Ну, можно было бы немного и перегрузить :) Статья на один экран всего.firehunt
08.05.2016 22:09+1Ну, можно было бы немного и перегрузить :) Статья на один экран всего.
Морально готовлюсь опубликовать в этом году статью прото как работаюткеширующие DNS сервисы у нескольких российских классических телекомов, ISP и/или сотовых компаний. Вот там будет больше одной страницы :)
saboteur_kiev
10.05.2016 02:35Недавно обнаружил, что public google dns, который 8.8.8.8, ведет себя не так, как общепринято.
Например, если я добавил новую зону в свой домен, и впервые пытаюсь ее пингануть, то любой провайдер немедленно обращается к NS и получает ответ с айпишником, который мне и возвращает. Google же этого не делает, в результате приходится ждать сутки.
Причем несколько лет назад, все было в порядке.firehunt
10.05.2016 07:08Боюсь дело тут не в Google Public DNS.
Могу порекомендовать проверить по списку:
1) Убедится в том, что новая запись действительно публикуется на всех авторитативных серверах домена, после того как ее внесли. Возможно, что сервера остаются рассинхронизированы по какой то причине. Проверить можно просто, указав команде nslookup или dig (в зависимости от OS) тип запроса soa, проверяемый домен и сервер и убедится в том, что серийный номер зоны одинаков. После этого проверить конкретную запись таким же способом;
2) Убедится, что нетCNAMEзаписи с большим временем жизни TTL, которая «перекрывает» новую запись.
firehunt
10.05.2016 07:11И еще одна проверка-вопрос: а серийный номер зоны Вы не забываете увеличивать?
saboteur_kiev
10.05.2016 18:041. Конечно проверяю, nslookup с непосредственно обслуживающего NS-а, и DNS моего домашнего провайдера, реагирует мгновенно.
2. Нет конечно. Обнаружив такую проблему, я специально поигрался, создавая новые A записи и проверяя как реагирует на это регистратор, домашний провайдер и гугл.
3. Серийный номер автоматически увеличивает панель управления при любом изменении.firehunt
10.05.2016 19:36Ok, Google :) Я думаю, что дело все же здесь нечисто и руки чешутся посмотреть в чем же дело.
И поэтому предлагаю аттракцион невиданной щедрости: сделайте новую запись и опубликуйте здесь полное имя, fqdn. А я скажу в чем точно дело, что именно происходит с точки зрения внешнего наблюдателя.saboteur_kiev
13.05.2016 19:43Я не так часто читаю Хабр, чтобы прямо тут делать интерактивный тест… У вас нет своего домена под рукой на поиграться? Бываю онлайн поздно вечером, скайп — как хабраник.
firehunt
14.05.2016 08:17По Вашим словам проблема с Вашим единичным доменом и ждете Вы сутки, чтобы Google Public DNS увидел новые записи в Вашем домене.
Для меня очень странно выступать их адвокатом, но с другими доменами массовых проблем не наблюдается, в том числе и с теми, которыми я управляю.
Соотвественно раз на произвольных доменах проверка Вашего утверждения дает другие результаты, а опубликовать название домена и сделать в нем запись Вы не можете, то будем считать, что Google Public DNS ведет себя корректно, пока не доказано обратное. Ну или что это сильно специальный случай.saboteur_kiev
16.05.2016 11:53Ок, у меня домены вроде на трех разных регистраторах, поиграюсь со всеми, проверю, может действительно проблема у конкретного регистратора. Просто я точно помню, что пару лет назад такой проблемы не было именно на этом домене.
vitalvas
10.05.2016 12:33google public dns последние 2 года совершенно неадекватно себя ведет с новыми записями или апдейтами.
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…firehunt
10.05.2016 13:50google public dns последние 2 года совершенно неадекватно себя ведет с новыми записями или апдейтами.
Было бы интересно получить более подробную информацию. По моим тестам, с внесением новых записей на нескольких доменах — их опрос через 8.8.8.8 отрабатывает вполне себе благополучно.
Бывали случаи, что на некоторые AS-ки переставал работать резолвинг на несколько недель.
В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них? В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Есть подозрения, что они парсят данные из страниц, и потом пробуют его проверить. Если это подтвердится — то все будет логично — они кешируют зону из статусом NXDOMAIN…
Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.vitalvas
10.05.2016 14:16-1> В смысле Google Public DNS не видел в этих AS'ках авторитативных серверов или не обслуживал запросы пользователей из них?
Не обслуживал запросы. Отваливалось по таймауту.
> В любом случае налицо нерасторопность администраторов этих AS, не могу поверить что «Корпорация Добра» решала вопросы сетевой связанности после обращения к ней в поддержку так долго.
Это было нарушения со стороны монтерев процесса настройки сети. Были поймание на горячем и наказаные. Потом бегали и исправляли…
«Корпорация Добра» совершенно не отвечает на noc@… и другие… Единственный вариант добиться контакта — отправить в блекхол их важные адреса и передача их аплинкам…
> Вполне себе реалистичный сценарий, особенно если последняя цифра в SOA записи, так называемая «Minimum TTL» или «The negative result TTL» установлено в относительно большое значение.
Возможно… Но другие сервера работают без таких приколов…
fronik
10.05.2016 08:29+1Я любил использовать сервера времени от Google — time1.google.com, time2-4
Перейдя на IPv6 резко разлюбил.
IPv6 адреса серверов времени Google не отвечают, ни пинг ни служба времени.
Уже два года.
https://mebsd.com/ipv6-ping-and-traceroute
Ping$ ping6 -c 10 -s 56 time1.google.com PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:32::f --- time1.google.com ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss $ ping6 -c 10 -s 56 time2.google.com PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:34::f --- time2.google.com ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss $ ping6 -c 10 -s 56 time3.google.com PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:36::f --- time3.google.com ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss $ ping6 -c 10 -s 56 time4.google.com PING6(104=40+8+56 bytes) 2001:4d48:1337:5afe::2 --> 2001:4860:4802:38::f --- time4.google.com ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss
stychos
10.05.2016 21:21У них и в браузере если открыть страницу не по имени, а по v6-адресу, будет page not found. Странное отношение от тех, кто одними из первых начали массово внедрять всякие IPv6-day и прочие мероприятия.
TimsTims
> ошибки были актуальны на 7 Мая 2016
Спасибо, что указали дату. А то бывает иногда читаешь статью лохматого года, и там написано: «актуально на текущий момент»… Или «по сегодняшнему курсу доллара»… n/c
А потом ищешь дату в посте… ищешь-ищешь находишь какую-нибудь «03 апреля» или «1 августа», без года. И думаешь — в этом году, или в прошлом, или в каком-то другом?
И единственный ответ получаешь, когда открываешь старую-старую статью хабра, и в ней узнаешь, что если год не написан — то это текущий год. А если год был прошлый — тогда Хабр любезно тебе его выдает…
Кстати, а не должен ли vk.com адресоваться к каким-нибудь
ns1.vk.com?
Ведь они как-раз ушли от .RU домена, чтобы обезопаситься от гос.регулирования. А тут вдруг домен vkontakte.ru разделегируют, тогда и vk.com достанется…
firehunt
Это зависит исключительно от соответствующих технических решений в самой компании. Может быть этот вопрос перестал быть важным, а может быть никто об этом не подумал в ключе зависимости от гос.регулирования.
HabrDev
Всё равно же Mail.Ru уже владеет ВКонтакте.
vadimr
Причём тут госрегулирование? Домен vk.com используется в интересах маркетинга среди зарубежных пользователей, как менее визуально чужой. Никакой связи между доменным именем и регулированием содержания сайта нет.
vadimr
Работа серверов Вконтакте регулируется российским законодательством, так как они физически расположены на территории России.
dim_s
Я всегда ее определял по комментариям, по их датам =)
ITMatika
Про дату — очень верно подмечено! Особенно про отсутствие года в датах!
Сам всегда указываю дату с годом и другим советую.
Очень часто при поиске актуальной информации (например, о различных мероприятиях) попадаются статьи без дат. Вот и думаешь — это о новость о предстоящем или о прошедшем 5 лет назад.