«Один мой друг» (с) рассказал историю про свои приключения с DNS.
Предыстория
Представьте, что заканчивается 2016 год, на ваших DNS серверах есть несколько сотен доменов, давным давно запущено штук 5 мощных DNS серверов в разных датацентрах, вы хотите наконец-таки избавиться от старых DNS серверов, которые последнее время просто тянут деньги на аренду и занимают место в стойке. Однако, сразу после попытки их отключения, телефоны поддержки раскаляются докрасна, поэтому старые сервера приходится быстро включить и вдумчиво разбираться в ситуации.
Глава 1
Еще раз проверяем DNS зоны, убеждаемся, что нигде нет старых адресов и очень давно. Проверяем на из разных регионов запросами на каждый из своих NS. Везде всё отдаётся правильно. Берем tcpdump и смотрим запросы на 53 порт на старыx DNS. Оказывается, что запросов к ним удивительно много. И это при том, что IP адреса этих серверов уже много месяцев нигде не фигурируют!
Смотрим tcpdump на новых DNS, а там потом запросов заметно меньше, чем на старых. Просто чудеса!
Проанализировав запросы к старым DNS, берем top10 клиентских адресов и выясняем, что это BIND9 (отвечает на dig +short version.bind txt chaos @сервер) крупных отечественных провайдеров (Ростелеком, ТТК и т.д.).
Глава 2
Слезно просим нескольких коллег прорезолвить клиентские домены с домашнего интернета через DNS сервер провайдера ( dig any clientsite.ru. @ns1.provider.ru ) и получаем ответ с неверными IP адресами и громадным TTL 345600 (4 суток!!!) в ADDITIONAL SECTION. Причем, если прорезолвить имя, на которое делегирован домен, то DNS сервер провайдера начинает отвечать правильными IP и правильным TTL, но «счастье» заканчивается вместе и истечением этого TTL. Ситуация воспроизводится в 6 случаях из 10, там, где рекурсором у провайдера используется BIND9. Собираем тестовую площадку с последней версией BIND9 на debian и ubuntu, ситуация воспроизводится, перезапуск и т.п. не помогают.
Глава 3
Внезапно приходит идея запросить корневые сервера зоны .RU ( на текущий момент это a.dns.ripn.net., b.dns.ripn.net. и т.д., список можно получить командой dig ns ru. ). И получаем тот самый ответ с неверными IP адресами, TTL 345600 в ADDITIONAL SECTION. Проблему удалось локализовать, теперь нужно понять, как она возникла.
Глава 4
Вспоминаем теорию про DNS, читаем на всякий случай статью в Википедии про склейку зон (Glue Records). Так как уже очень давно Glue Records не используются (лет 5-6), то приходим к неверному выводу: кто-то из клиентов умудрился при делегировании домена указать старые IP адреса DNS. Пришлось написать скрипты, которые по списку клиентских доменов запросили whois для анализа.
К сожалению, из-за этого неверного предположения потеряли время, но зато нашли другие ошибки. Например, клиенты любят доменную почту от Яндекса и умудряются делегировать домен на наши NS и на NS Яндекса одновременно.
Глава 5
На следующее утро, проанализировав еще раз собранные данные whois, ничего не находим. Остаётся только обращаться в RU-Center с диагностикой и нашими предположениями. Не смотря на длительное сотрудничество с этой компанией, у нас практически не было обращений в техподдержку, в основном вопросы возникали по бухгалтерской части. Поэтому отправляем письмо на support@ и ждём ответа. Через пару часов ожидания ответа на Email наши сотрудники уже не могут терпеть и пытаются звонить по телефону. Послушав достаточное количество музыки попадаем на живого человека, который находит наше письмо и сообщает номер тикета. Ура! Однако, ответа по заявке не получаем. Еще несколько звонков с периодичностью в 1-2 часа результат не приближают. К счастью, под конец рабочего дня получаем примерно такой ответ:
Существование glue records означает, что ранее для домена были указаны дочерние DNS-серверами с этими IP-адресами. Чтобы изменить данные записи необходимо делегировать домен на такие же дочерние DNS-сервера с указанием новых IP-адресов.
Очень удивляемся. Последний раз glue records были очень много лет назад. Неужели, такое возможно? Поднимаем архивы почты, находим там письма за 2011 год, когда домен был делегирован на другие ns и еще раз удивляемся. Получается, столько лет оно работало неправильно и никто ничего не заметил!
Глава 6
А тем временем идут последние часы аренды старых железок, и мы понимаем, что при TTL в 4 дня в провайдерских кешах, потребуется проплатить еще месяц аренды, а это не совсем то, что планировалось.
Просим поддержку Ru-Center удалить glue records. Нам ведь они совсем не нужны, зачем нам привязываться к новым IP адресам?! Тем более, что в нашей DNS зоне для каждого NS указаны несколько IP адресов + IPv6. И получаем ответ, который ставит нас в тупик. Примерно такой:
заявка передана на исполнение в отдел системного администрирования, о результате сообщим
Т.е. делаем вывод, что готового механизма для этой операции у регистратора нет (нам представлялось это кнопкой в интерфейсе сотрудника поддержки), а это значит, что либо никто не сталкивался с подобной проблемой (что маловероятно), либо просто меняли IP адреса в glue records и жили дальше. Но это же неправильно, ведь логично, что если удаляются IP адреса для NS у регистратора, то должны удалиться и glue records. Предполагаем, что это старые глюки, начала этого десятилетия, давно решены, и, вероятно, нам просто не повезло.
Глава 7
К полудню следующего дня осторожно интересуемся по email, есть ли ответ на заявку? После проходим несколько раз в квест с прослушиванием музыки по телефону, дозваниваемся до живых человека, но кроме «ваша заявка передана в отдел системного администрирования» ничего добиться не можем. Проходят еще почти сутки, нам ничего не остаётся, как последовать совету с указанием новых glue records, что мы и делаем. Через несколько часов изменения вступают в силу (как вы помните, .RU обновляется не слишком часто) и мы удаляем эти glue records (они же нам не нужны и даже мешают). Ждём следующего обновления .RU, однако, корневые сервера .RU продолжают отвечать с этими записями, но уже с новыми IP адресами. Неужели глюк остался?!!!
Глава 8
Так как ответа по заявке нет, на следующий день опять проходим квесты с телефонной музыкой. Особенно понравится уровень, когда попросили соединить с руководителем поддержки и девушка предупредила, что «придется некоторое время подождать» и поставила нам музыку, которая прекратилась через 30 минут и звонок разорвался. К счастью, ближе к концу рабочего дня пришел наконец ответ, что glue record удалены. Ура, товарищи!
Глава 9
Вспоминая про TTL в 4 дня в провайдерских кешах смотрим tcpdump. Действительно, запросов к старым DNS серверам становится всё меньше, т.е. всё идёт как задумано. Остаётся только ждать. На всякий случай, берем пару ненужных доменов и пытаемся воспроизвести ситуацию. И она повторяется!
Для истории оставлю тут рецепт, как воспроизвести ситуацию:
Берем первый домен ingavto.ru, создаём в нём A записи для ns10.ingavto.ru и ns11.ingavto.ru, указывающие на одну пару DNS серверов и делегируем на них этот домен с указанием IP адресов. Ждём, пока обновится зона .RU
Берем второй домен body-m-auto.ru, делегируем его на ns10.ingavto.ru и ns11.ingavto.ru, ждём обновления.
Первый домен делегируем на другие NS, в зоне меняем в A записях адреса для ns10.ingavto.ru и ns11.ingavto.ru, также ждём обновления.
В результате имеем в корневой зоне .RU неправильные glue records и глюки, которые описаны выше.
Запросим IP адреса NS серверов у гугла
$ dig +short A ns10.ingavto.ru. @8.8.8.8 136.243.55.209 $ dig +short A ns11.ingavto.ru. @8.8.8.8 136.243.55.194 Ответ совпадает с тем, что прописано в DNS-зоне.
Пример запроса к корневому серверу, видно, что отдаются совсем другие IP адреса:
$ dig any body-m-auto.ru @a.dns.ripn.net. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any body-m-auto.ru @a.dns.ripn.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;body-m-auto.ru. IN ANY ;; AUTHORITY SECTION: BODY-M-AUTO.RU. 345600 IN NS ns11.ingavto.ru. BODY-M-AUTO.RU. 345600 IN NS ns10.ingavto.ru. ;; ADDITIONAL SECTION: ns10.INGAVTO.RU. 345600 IN A 89.249.20.188 ns11.INGAVTO.RU. 345600 IN A 89.249.24.177 ;; Query time: 42 msec ;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6) ;; WHEN: Sat Dec 10 00:00:30 MSK 2016 ;; MSG SIZE rcvd: 153 Эпилог
К сожалению, не удалось выяснить, это проблема связана только с Ru-Center или актуальна для других регистраторов. Если у вас есть пара доменов для экспериментов, купленных через другого регистратора, пожалуйста, протестируйте и напишите в комментарии.
С большой вероятностью, такая проблема может существовать не только для домена .RU, но и для домена.РФ, но у нас тоже нет сейчас таких доменов для теста.
Также напрашивается очевидный вывод, что в настоящее время не стоит использовать glue record для домена .RU и в некоторых случаях имеет смысл обращаться к регистраторам с заявкой на зачистку таких записей.
P.S. Было бы неплохо, если бы кто-то из специалистов, работающих в Ru-Center или другом регистраторе, прокомментировал ситуацию.
ссылка на оригинал статьи https://habrahabr.ru/post/317286/
Добавить комментарий