«Один мой друг» (с) рассказал историю про свои приключения с 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, указывающие на IP адреса двух DNS серверов и делегируем на них этот домен с указанием IP адресов у регистратора (glue records). Ждём, пока обновится зона .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 или другом регистраторе, прокомментировал ситуацию.
Комментарии (56)
w4r_dr1v3r
10.12.2016 07:36+1Однако! Всегда считал RU-Center весьма компетентной и серьёзной организацией. Автору отдельное спасибо за «срыв покровов», по крайней мере лично мне было очень познавательно.
motienko
10.12.2016 07:52Как правильно заметил знакомый, сами виноваты, что делали в последний день. Другой товарищ сказал, что нужно было сразу сделать сделать так, как предложили в первом ответе на заявку, достигли бы цели и появилось время на неспешное решение. С другой стороны, конечной целью было найти источник проблемы и исключить повторение в будущем.
По поводу скорости ответа поддержки могу сказать, что во многих организациях есть несколько линий поддержки, у которых цель — снизить нагрузку на технических специалистов, оказывая помощь по типовым вопросам. В нестандартных ситуациях, к сожалению, такая схема часто замедляет решение проблем. Но, конечно, когда оказываешься «на той стороне» (видишь ситуацию глазами клиента), остаётся не очень приятное ощущение.
vopper
10.12.2016 21:15+3Возможно не прав, но после того как ру центр при открытии доменной зоны рф, после того проверки доступности покупки домена, этот домен автоматически регистрировался на ру центр, это компания потеряла для меня авторитет.
mutin_sa
11.12.2016 08:45+2В техподдержке RU-Center далеко не все админы вообще в курсе что такое Glue Record. У них это называется Именованные DNS-серверы.
tankistua
10.12.2016 07:36-3Так а при чем тут глю рекорд?
Во втором случае это не глюрекорд вообще. Это просто кривой софт у них
tankistua
10.12.2016 16:23Окей, разворачиваю.
Глюрекорд прописывается для зоны только в случае нахождения нс-ов в этой самой зоне. Эта информация обязателльно есть хуиз
Для второго домена никакой глюрекорда быть в принципе не может — его нсы в другой зоне
Могу только предположить почему так произошло: для минимизации трафика к днс-у во время прописывания нс-ов они резолвятся и жестко прописываются, скорее всего это сделано только для своей подконтрольной ру-зоны. Скорее всего есть механизм обновления этих данных
motienko
10.12.2016 17:57в посте пример, как воспроизвести.
никто ничего не резолвит, просто домен сначала был делегирован с glue, а потом без них на ns в другом домене, а в .RU остались записи для glue
porutchik
10.12.2016 09:30+8В reg.ru аналогичная ситуцация с .ru. Только там техподдержке пришлось 5 дней объяснять, что такое glue records и проблему так и не решили.
;; QUESTION SECTION:
;relevate.ru. IN A
;; AUTHORITY SECTION:
RELEVATE.RU. 345600 IN NS dns2.relevate.RU.
RELEVATE.RU. 345600 IN NS dns1.relevate.RU.
;; ADDITIONAL SECTION:
dns1.RELEVATE.RU. 345600 IN A 178.57.216.1
dns2.RELEVATE.RU. 345600 IN A 178.57.217.1
;; QUESTION SECTION:
;01SOVET.RU. IN A
;; AUTHORITY SECTION:
01SOVET.RU. 345600 IN NS ns1.relevate.RU.
01SOVET.RU. 345600 IN NS ns2.relevate.RU.
;; ADDITIONAL SECTION:
ns1.RELEVATE.RU. 345600 IN A 178.57.216.5 <===
ns2.RELEVATE.RU. 345600 IN A 178.57.216.15 <=== этих быть не должно
P.S. glue records никуда не исчезали. Без них не будет работать dns.motienko
10.12.2016 11:46Вроде бы у вас не совсем такая ситуация, но весьма похожая и вызванная той же проблемой?
У вас IP адреса (для ns1.relevate.ru. ns2.relevate.ru.) в ответах от ваших NS (dns1.relevate.ru. и dns2.relevate.ru.) и от корневых NS показывают одинаковые IP, но разный TTL. Т.е. вы уже раньше меняли glue на правильный?
В самой зоне совсем другие glue.
nserver: dns1.relevate.ru. 178.57.216.1, 2a03:c980::3:1:1 nserver: dns2.relevate.ru. 178.57.217.1, 2a03:c980::3:2:1
$ dig +short any ns1.relevate.ru. @dns1.relevate.RU. 2a03:c980::3:1:5 178.57.216.5 $ dig +short any ns2.relevate.ru. @dns1.relevate.RU. 178.57.216.15 $ dig any 01SOVET.RU. @a.dns.ripn.net. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 01SOVET.RU. @a.dns.ripn.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37888 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;01SOVET.RU. IN ANY ;; AUTHORITY SECTION: 01SOVET.RU. 345600 IN NS ns2.relevate.ru. 01SOVET.RU. 345600 IN NS ns1.relevate.ru. ;; ADDITIONAL SECTION: ns1.RELEVATE.RU. 345600 IN AAAA 2a03:c980::3:1:5 ns1.RELEVATE.RU. 345600 IN A 178.57.216.5 ns2.RELEVATE.RU. 345600 IN A 178.57.216.15 ;; Query time: 38 msec ;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6) ;; WHEN: Sat Dec 10 11:37:58 MSK 2016 ;; MSG SIZE rcvd: 163
Получается, что проблема в зоне .RU и не зависит от регистратора?porutchik
10.12.2016 14:43+1Т.е. вы уже раньше меняли glue на правильный?
Да, пришлось у relevate.ru прописать ns1/ns1 с «правильными» ip, а потом сменить обратно на dns1/dns2, чтобы корневые серверы обновили записи A.
Получается, что glue records из зоны не удаляются пока на них делегирован хоть один домен. Это противоречит здравому смыслу.
karkarramba
10.12.2016 11:46+3Как сказали выше, Glue Records никуда не исчезли — из них состоит заметная часть корневой зоны, например.
Их особенность в том, что они не являются «собственностью» родительской зоны, т.е. если А запись в родительской зоне не совпадает с таковой в дочерней, будет закэширована вторая, поэтому в идеале TTL большой роли не играет.
В вашем случае загвоздка в следующем: резолвер идет за body-m-auto.ru к a.dns.ripn.net, получает от него неправильные (с вашей, но не с его, точки зрения) данные
ns10.INGAVTO.RU. 345600 IN A 89.249.20.188
ns11.INGAVTO.RU. 345600 IN A 89.249.24.177
дальше резолвер идет по одному из этих адресов и получает искомое, при этом даже не заглядывая в зону INGAVTO.RU, откуда он мог бы взять правильные адреса.
Т.е. проблема действительно заключается в том, что добавлены ненужные Glue, хотя и не означает, что они не нужны вовсе.
Писать об этой проблеме нужно в ТЦИ.motienko
10.12.2016 12:05Получается, бага во взаимодействии между регистраторами и ТЦИ? Т.е. когда регистратор передаёт данные о делегировании домена, старые записи Glue не очищаются. Судя по информации http://tcinet.ru/about/ проблема будет для .RU,.РФ, .SU,.ДЕТИ, .TATAR.
karkarramba
10.12.2016 12:30+2А они и не должны сами по себе очищаться — вот это точно было бы ошибкой.
Баги как таковой нету, есть выбор между несколькими видами зла.
Тут возможны несколько стратегий поведения:
- Принимать все дочерние для зоны glue записи;
- Принимать glue NS только для доменов, которые на них проделегированы;
- Принимать glue только от владельца дочерней зоны, в которой они располагаются.
В первом случае возможны проблемы типа вашей, но взамен в среднем ускоряется время резолва;
Второй вариант противоположен первому плюс добавляется неопределенность в случае разделегирования домена, в котором располагались NS;
Третий — компромисс, пример:
зона example.com проделегирована на ns1.example.ru и ns2.example.ru, в ней есть сервер имен ns3.example.com
чтобы проделегировать зону another-example.com на ns3.example.com, нужно сначала добавить ns3.example.com в зону .com в качестве glue, но сделать это может только владелец зоны example.com.motienko
10.12.2016 13:10Насколько я понимаю, для .RU сейчас работает второй вариант, но при удалении glue не происходит очистки в зоне TLD. Тесты показывают именно такую ситуацию.
karkarramba
10.12.2016 13:42Я могу ошибаться, но мне кажется, что как раз наоборот, по ситуации с body-m-auto.ru работает скорее первый вариант. Будь использован второй вариант, то ns10.INGAVTO.RU и ns11.INGAVTO.RU приняли бы в качестве glue исключительно в случае, если они прописаны как NS'ы для INGAVTO.RU, а это не так.
Первый вариант как раз описывает, что если у нас NS располагается в домене зоны RU (например ns10.INGAVTO.RU), то его можно прописать в этой зоне для любого дочернего домена. В случае второго вариант его можно было бы прописать как glue только если бы сам родительский домен этого NS'а (INGAVTO.RU) был проделегирован на него.
Но за более точными и конкретными комментариями лучше обратиться в ТЦИ.
porutchik
10.12.2016 14:52+1В Ру-центре мне ответили, что нельзя удалить glue record пока на неё проделегирован хотя бы один домен.
И не важно, что я владелец example.com
Например, не могу удалить ns3.IHC.RU хотя я администратор домена IHC.RU
;; QUESTION SECTION:
;0227.RU. IN A
;; AUTHORITY SECTION:
0227.RU. 345600 IN NS ns1.ihc.RU.
0227.RU. 345600 IN NS ns3.ihc.RU.
0227.RU. 345600 IN NS ns2.ihc.RU.
;; ADDITIONAL SECTION:
ns1.IHC.RU. 345600 IN A 190.115.26.198
ns1.IHC.RU. 345600 IN A 178.248.237.118
ns2.IHC.RU. 345600 IN A 91.121.54.18
ns2.IHC.RU. 345600 IN A 95.213.233.218
ns3.IHC.RU. 345600 IN A 46.254.23.37
ns1.IHC.RU. 345600 IN AAAA 2a03:c980::1:3:7
ns2.IHC.RU. 345600 IN AAAA 2001:41d0:1000:e98::
С другой стороны, есть домены, проделегированные на несуществующую glue record:
;; QUESTION SECTION:
;511TACTICAL29.RU. IN A
;; AUTHORITY SECTION:
511TACTICAL29.RU. 345600 IN NS ns4.ihc.RU. <===
511TACTICAL29.RU. 345600 IN NS ns2.ihc.RU.
511TACTICAL29.RU. 345600 IN NS ns3.ihc.RU.
511TACTICAL29.RU. 345600 IN NS ns1.ihc.RU.
;; ADDITIONAL SECTION:
ns1.IHC.RU. 345600 IN A 190.115.26.198
ns1.IHC.RU. 345600 IN A 178.248.237.118
ns2.IHC.RU. 345600 IN A 91.121.54.18
ns2.IHC.RU. 345600 IN A 95.213.233.218
ns3.IHC.RU. 345600 IN A 46.254.23.37
ns1.IHC.RU. 345600 IN AAAA 2a03:c980::1:3:7
ns2.IHC.RU. 345600 IN AAAA 2001:41d0:1000:e98::
karkarramba
10.12.2016 16:46+1В Ру-центре мне ответили, что нельзя удалить glue record пока на неё проделегирован хотя бы один домен.
Этот вопрос нигде не оговаривается, кроме фразы «объект HOST живет до тех пор пока на него ссылается хотя бы один объект DOMAIN», ну или как-то так. Т.е. прямого утверждения о невозможности удаления нет. Технические условия и политика доменов есть на сайте ТЦИ в свободном доступе.
С другой стороны, есть домены, проделегированные на несуществующую glue record:
Ну, это не glue record. glue record — это адресная запись в зоне верхнего уровня. NS запись в зоне верхнего уровня называется zone cut.
В целом делегирование на несуществующий хост ничему не противоречит :) нет такого технического требования — проверять существование NS'а.lehha
10.12.2016 20:51всё не так. Фраза «нельзя удалить, пока на него ссылается хотя бы одна запись» относится только к этому же домену. Если у вас домен domain.ru и ns1.domain.ru + ns2.domain.ru (с адресами), и на него кто-то проделегировал сайт example.ru, то вам никто не мешает крутить и вертеть записи как вздумается.
В общих чертах фраза означает, что ns3.domain.ru будет в корневых серверах светиться до тех пор, пока ему соответствует хотя бы один ip-адрес (в glue record). Если хотите удалить ns3 с корневых серверов, то выхода два:
1. делегировать основной домен domain.ru на список серверов, в котором нет ns3.domain.ru (например, ns1.domain.ru и ns2.domain.ru)
2. убрать у ns3.domain.ru ip-адрес для glue-записи. Обычно у регистратора достаточно делегировать домен на тот же список ns-серверов, но для ns3 не указывать ip-адрес.
karkarramba
11.12.2016 00:43Объект host хранится в реестре до тех пор, пока хотя бы один зарегистрированный домен имеет ссылку на этот объект.
Вот прямая цитата из технических условий, пункт 3.4.4. Как видите, в ней нет указаний на то, что она относится только к этому же домену, в котором живут серверы. Впрочем, из нее следует, что в предыдущем комментарии я несколько погрешил против истины.
Вообще, получается некая двусмысленность: с одной стороны удалить нельзя, с другой, пусть и с геморроем, но можно.lehha
11.12.2016 14:55Так пускай host хранится в реестре, что с него-то? IP-адресом для Glue Record управляет только владелец домена (domain.ru для ns1.domain.ru), и только он может поменять или удалить этот адрес.
Так что если example.ru делегирует на ваши серверы с левым ip-адресом:
ns1.domain.ru 127.0.0.1
ns2.domain.ru 127.0.0.2
то ничего не произойдет, потому что реестр в корневые серверы заносит Glue Record только записи от владельца домена domain.ru, а не от example.rukarkarramba
11.12.2016 22:21Я, если честно, не очень понимаю зачем вы повторяете то, что я описывал несколькими комментариями ранее.
И что значит «пускай»? У нас есть объективная реальность, в которой для реестра выбрана другая политика относительно glue записей. Изменить ее можно только обратившись в ТЦИ и доказав ее несостоятельность. Надеюсь, вы не думаете, что в логику работы реестра домена верхнего уровня кто-то будет вносить изменения руководствуясь комментарием на хабре?lehha
12.12.2016 07:57+1Тоже перестал всё понимать. Проблемы не вижу в упор. Glue Records управляет владелец домена (domain.ru для *.domain.ru).
Что должно само удаляться-то? Если владелец создал «ns3.domain.ru 127.0.0.1», а потом удалил его (просто проделегировав на ns1.domain.ru… и ns2.domain.ru)? В таком случае сам себе буратино. У реестра нормальная политика — если запись есть или была, она всё-равно будет храниться еще 30 дней, даже если на неё никто не ссылается.motienko
12.12.2016 17:14но она же не может храниться с весны 2011 по зиму 2016?
lehha
12.12.2016 17:34+1Если что-то существует и есть ссылка на оное, то оно будет храниться, в документации это указано.
Я так понял проблема в том, что регистратор не чистит список ранее установленных ns-серверов, если вы передали другие. Так? Из документации это нигде не следует, поэтому и не чистят.
В любом случае, просто поменять делегирование авторитарных серверов — достаточно необычное занятие, которое нужно проводить очень чутко. Можно ошибиться и разделегировать домен вовсе. Хорошо, что корневые реестры это не едят так быстро, как gtld, а может и плохо…
lehha
10.12.2016 20:44Всё не так плохо, как Вы описываете.
Корневые серверы имеют ровно ту информацию, которую вы указываете при делегировании домена. Если ранее использовался ns3 и он есть в glue record (то есть домен делегирован сам на себя и там есть такой nserver), то неважно, что вы делаете на своем сервере или на своём bind'e — запись в корневых серверах берется от регистратора и обновляется только через регистратора.
Так что процедура удаления dns-сервера достаточно простая:
1. вынимаете его из списка делегирования (domain.ru был делегирован на: ns1.domain.ru (127.0.0.1), ns2.domain.ru (127.0.0.2), ns3.domain.ru (127.0.0.3) — то есть делегируете домен на новый список без нужного сервера: ns1.domain.ru (127.0.0.1), ns2.domain.ru (127.0.0.2)
2. в течение 2х часов корневые серверы зоны подтягивают изменения и ns3 пропадает с них
3. ждете до суток, пока протухнет кэш у провайдеров.
4. profit!
motienko
10.12.2016 21:15посмотрите пример в конце поста, воспроизвели ситуацию для двух других доменов.
и также см. камент про аналогичную ситуацию у reg.ru.lehha
10.12.2016 21:25Нет, проблемы не вижу.
По ссылке коммента:
домен relevate.ru делегирован на dns1.relevate.RU и dns2.relevate.RU (нормально, ip корректные — 178.57.216.1, 178.57.217.1)
домен 01SOVET.RU делегирован на ns1.relevate.RU и ns2.relevate.RU. А вот тут ответ о левом ip-адресе выдает ваш же сервер (ns1.relevate.RU или ns2.relevate.RU), то есть проблема в зоне на вашем сервере.
Лучше дайте тоже самое +trace:
dig +trace IN A 01SOVET.RU ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.3 <<>> +trace IN A 01SOVET.RU ;; global options: +cmd . 82355 IN NS i.root-servers.net. . 82355 IN NS b.root-servers.net. . 82355 IN NS m.root-servers.net. . 82355 IN NS c.root-servers.net. . 82355 IN NS l.root-servers.net. . 82355 IN NS k.root-servers.net. . 82355 IN NS h.root-servers.net. . 82355 IN NS j.root-servers.net. . 82355 IN NS g.root-servers.net. . 82355 IN NS d.root-servers.net. . 82355 IN NS e.root-servers.net. . 82355 IN NS f.root-servers.net. . 82355 IN NS a.root-servers.net. ;; Received 449 bytes from 77.221.130.254#53(77.221.130.254) in 5 ms RU. 172800 IN NS a.dns.ripn.net. RU. 172800 IN NS b.dns.ripn.net. RU. 172800 IN NS d.dns.ripn.net. RU. 172800 IN NS e.dns.ripn.net. RU. 172800 IN NS f.dns.ripn.net. ;; Received 340 bytes from 198.97.190.53#53(198.97.190.53) in 119 ms 01SOVET.RU. 345600 IN NS ns1.relevate.RU. 01SOVET.RU. 345600 IN NS ns2.relevate.RU. ;; Received 133 bytes from 194.85.252.62#53(194.85.252.62) in 1 ms 01SOVET.RU. 300 IN A 178.57.216.18 01SOVET.RU. 300 IN NS ns1.relevate.RU. 01SOVET.RU. 300 IN NS ns2.relevate.RU. ;; Received 121 bytes from 178.57.216.5#53(178.57.216.5) in 8 ms
обратите внимание, что последний ответ пришел с сервера 178.57.216.5 — relevate.rumotienko
10.12.2016 21:42Проблема в том, что с a.dns.ripn.net. в ADDITIONAL SECTION для ns1.RELEVATE.RU и ns2.RELEVATE.RU приходят данные, которые могут не соответствовать данным в зоне RELEVATE.RU (отличается TTL).
$ dig any 01SOVET.RU. @a.dns.ripn.net. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 01SOVET.RU. @a.dns.ripn.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36184 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;01SOVET.RU. IN ANY ;; AUTHORITY SECTION: 01SOVET.RU. 345600 IN NS ns1.relevate.ru. 01SOVET.RU. 345600 IN NS ns2.relevate.ru. ;; ADDITIONAL SECTION: ns1.RELEVATE.RU. 345600 IN AAAA 2a03:c980::3:1:5 ns1.RELEVATE.RU. 345600 IN A 178.57.216.5 ns2.RELEVATE.RU. 345600 IN A 178.57.216.15 ;; Query time: 23 msec ;; SERVER: 2001:678:17:0:193:232:128:6#53(2001:678:17:0:193:232:128:6) ;; WHEN: Sat Dec 10 21:38:21 MSK 2016 ;; MSG SIZE rcvd: 163
Аналогично и для тестовых зон, там кроме TTL еще отличаются и IP адреса (см. данные в конце статьи)
motienko
10.12.2016 21:49Насчет +trace для тестовых body-m-auto.ru и ingavto.ru — там будет «всё хорошо», однако, например, рекурсивный DNS провайдера (например BIND9, 9.9.5-9+deb8u7-Debian у ТТК ), закеширует неправильные IP адреса для ns11.ingavto.ru. и ns10.ingavto.ru. (те, которые были когда-то указаны как Glue Record, а потом удалены).
lehha
11.12.2016 15:04Ну так это проблема кэша и кривых рук провайдера. Вы тут никак не решите её.
Я вынимал авторитарный сервер из зоны, всё ровно:
Через 2 часа 90% запросов уходит. Остаются какие-то китайцы и жутко пухлые кэши с космическим ttl. Вырубаете сервер и их запросы по roundrobin уходят на рабочий сервер.
В вашем случае проблема в том, что где-то в кэше у провайдеров лежат старые glue records, а вы резко переехали на все новые. В таких ситуациях полный переезд на новые ip нужно растягивать во времени, а вот менять один на другой — хоть каждый день.
litos
10.12.2016 22:21> Первый домен делегируем на другие NS, в зоне меняем в A записях адреса для ns10.ingavto.ru и ns11.ingavto.ru, также ждём обновления.
Только в зоне? А у регистратора ingavto.ru тоже меняли при этом записи (указывали новые IP адреса)? Надо менять…
Если домен делегирован на ns которые созданы в самой доменной зоне — то IP адреса надо указывать у регистратора доменного имена. Иначе как система DNS узнает на каком IP адресе они живут?motienko
10.12.2016 22:39> А у регистратора ingavto.ru тоже меняли при этом записи (указывали новые IP адреса)
поясните, пожалуйста, мысльlitos
10.12.2016 22:47Вы в доменной зоне на DNS сервере пошли и изменили ns10 и ns11 указав на новые IP адреса
Помимо этого надо было пойти в интерфейс регистратора доменного имени и там тоже указать для ns10.ingavto.ru и ns11.ingavto.ru новые IP
Вы это судя по всему не делали, а изменять записи только в зоне недостаточно, поскольку записи созданы в самом домене и система DNS не направит на них запросы не зная откуда их взятьmotienko
10.12.2016 23:04Идея именно в том, чтобы не указывать новые IP и не быть зависимыми от glue record. Пожалуйста, прочитайте «Глава 9» еще раз.
mutin_sa
11.12.2016 07:57Автор ошибается, Glue Records ни разу не устаревшая технология и не переставала использоваться. Скорее даже наоборот — почти все существующие домены так или иначе её используют.
Суть Glue Records в возможности делегировать домен на NS сервера, находящиеся непосредственно в зоне этого домена и поддерживать на них записи зоны.
Делается это очень просто — при делегировании домена на NS сервера указывается не только их DNS имена, но и IP адреса + на DNS серверах, на которые выполнено делегирование зоны, вносятся записи зоны — в частности NS записи указывающие на IP адреса этих DNS серверов.
Технология активно используется провайдерами услуг (к примеру хостерами и регистраторами) и крупными компаниями. А через провайдеров технология используется и всеми остальными.
Пример: когда клиент хостера делегирует свой домен client.com на ns[1-2].hoster.net он начинает использовать Glue Records домена хостера.
Что касается темы статьи и озвученной автором проблемы — из-за стиля написания сложно понять есть ли тут реальная проблема/особенность или же имеет место только некорректное применение технологии Glue Records. Для однозначной диагностики проблемы в статье недостаточно данных.motienko
11.12.2016 08:14Где написано, что Glue Records — устаревшая технология?
Суть поста в том, что для .RU есть проблемы с Glue Records.
Как воспроизвести проблему, написано в «Глава 9»mutin_sa
11.12.2016 08:37Так как уже очень давно Glue Records не используются (лет 5-6)
Признаю ошибку, неверно понял вашу фразу.
catharsis
13.12.2016 17:39Суть Glue Records в возможности делегировать домен на NS сервера, находящиеся непосредственно в зоне этого домена
Пример: когда клиент хостера делегирует свой домен client.com на ns[1-2].hoster.net он начинает использовать Glue Records домена хостера.
выходит, glue records используется не по назначению?mutin_sa
14.12.2016 17:40+1Вопрос немного неверный. Просто то, что является Glue Records -ом для домена хостера НЕ может является Glue Records -ом для домена клиента. Т.е. использовать можно и даже нужно, но нужно понимать, что с точки зрения клиента это уже не Glue Records, а обычный список NS -ов.
pavelodintsov
11.12.2016 14:45+1А вот и мой «негативный» опыт с Гарант Парк Телеком: https://www.stableit.ru/2013/12/r01ru.html Как раз при правке glue records :)
Olaf72
12.12.2016 07:11+1Жутко болит голова, и по этому, в качестве предположения (без копания куда то в глубину).
Когда то давно, когда запускали первую версию парковки доменов в ру-центре, нам для этого сервиса пришлось делать пару NS серверов, заточенных строго под этот сервис.
Они очень маленькие, на фряхе, там бинд, но не простой, он хранит записи зон в постгри.
и в отличии от простого бинда, который хранит зоны в текстовых файлах, отдают они зону на порядки быстрее.
Глядя на чехарду с доменами в рунете я вспоминаю свои днсы и думаю, не виноваты ли они в этом.
Может про них просто забыли.
Это было почти 10 лет назад, а работают они до сих, по моему. ))
Надо проверить, не проходили ли ваши домены через парковку доменов.
netch80
> Также напрашивается очевидный вывод, что в настоящее время не стоит использовать glue record для домена .RU
Совсем не использовать не получится — где-то они таки должны быть. И использовать для своего домена — совершенно нормально.
Скорее всего, система формирования зоны .ru допускает, что регистраторы домена 2 указывают glue-записи для домена 1. По-нормальному glue-записи внутри какого-то домена могут указываться только регистраторами этого же домена, независимо от того, кто иной использует их как NS. Это не гарантия полного избавления от проблемы неверных IP адресов, но позволяет значительно упростить диагностику и локализацию. В .ua, для сравнения, эта политика форсирована, как и (насколько я помню) в .com, .org и аналогичных местах.
Проблему следует лечить непосредственно у администратора зоны, регистратор тут не поможет, если чужие glue-записи будут залипшими из данных другого регистратора.
Специфика BIND9 здесь может быть в том, что он воспринимает glue-записи от чужого домена в additional, но использует их только для дальнейшей рекурсии, не сохраняя в основном кэше, и внутренне привязывая только к тому домену, для которого они были получены. Это лучше, чем более ранняя тотальная анархия с приёмом любых подобных записей (ещё лет 8 назад выяснение «откуда взялась эта запись в кэше?» могла выливаться в полноценный детективный роман), но по сравнению с тотальным игнорированием чужих glue-записей может давать описанные проблемы. К слову, указание BIND9 недостаточно подробно (например, существенные изменения в алгоритме были с переходом 9.3 -> 9.4).
motienko
Первой мыслью было именно то, что кто-то в другом домене сделал glue с именами из нашего, однако, на тестовых доменах воспроизвести не удалось.
Зато удалось убедиться и воспроизвести ситуацию, когда при удалении IP адресов для nserver у регистратора, соответствующие glue records не удаляются из .RU.
mutin_sa
Glue Records — это когда domain.com сделегирован на запись вида:
ns1.domain.com, 192.0.2.4
ns2.domain.com, 192.0.2.5
Если, к примеру, ваш клиент сделегировал свой домен client.com на:
ns1.hoster.net
ns2.hoster.net
то это уже не Glue Records.
motienko
Всё верно, именно эта ситуация и описана, но когда оба домена в .RU