Комментарии 56
> Также напрашивается очевидный вывод, что в настоящее время не стоит использовать glue record для домена .RU
Совсем не использовать не получится — где-то они таки должны быть. И использовать для своего домена — совершенно нормально.
Скорее всего, система формирования зоны .ru допускает, что регистраторы домена 2 указывают glue-записи для домена 1. По-нормальному glue-записи внутри какого-то домена могут указываться только регистраторами этого же домена, независимо от того, кто иной использует их как NS. Это не гарантия полного избавления от проблемы неверных IP адресов, но позволяет значительно упростить диагностику и локализацию. В .ua, для сравнения, эта политика форсирована, как и (насколько я помню) в .com, .org и аналогичных местах.
Проблему следует лечить непосредственно у администратора зоны, регистратор тут не поможет, если чужие glue-записи будут залипшими из данных другого регистратора.
Специфика BIND9 здесь может быть в том, что он воспринимает glue-записи от чужого домена в additional, но использует их только для дальнейшей рекурсии, не сохраняя в основном кэше, и внутренне привязывая только к тому домену, для которого они были получены. Это лучше, чем более ранняя тотальная анархия с приёмом любых подобных записей (ещё лет 8 назад выяснение «откуда взялась эта запись в кэше?» могла выливаться в полноценный детективный роман), но по сравнению с тотальным игнорированием чужих glue-записей может давать описанные проблемы. К слову, указание BIND9 недостаточно подробно (например, существенные изменения в алгоритме были с переходом 9.3 -> 9.4).
Совсем не использовать не получится — где-то они таки должны быть. И использовать для своего домена — совершенно нормально.
Скорее всего, система формирования зоны .ru допускает, что регистраторы домена 2 указывают glue-записи для домена 1. По-нормальному glue-записи внутри какого-то домена могут указываться только регистраторами этого же домена, независимо от того, кто иной использует их как NS. Это не гарантия полного избавления от проблемы неверных IP адресов, но позволяет значительно упростить диагностику и локализацию. В .ua, для сравнения, эта политика форсирована, как и (насколько я помню) в .com, .org и аналогичных местах.
Проблему следует лечить непосредственно у администратора зоны, регистратор тут не поможет, если чужие glue-записи будут залипшими из данных другого регистратора.
Специфика BIND9 здесь может быть в том, что он воспринимает glue-записи от чужого домена в additional, но использует их только для дальнейшей рекурсии, не сохраняя в основном кэше, и внутренне привязывая только к тому домену, для которого они были получены. Это лучше, чем более ранняя тотальная анархия с приёмом любых подобных записей (ещё лет 8 назад выяснение «откуда взялась эта запись в кэше?» могла выливаться в полноценный детективный роман), но по сравнению с тотальным игнорированием чужих glue-записей может давать описанные проблемы. К слову, указание BIND9 недостаточно подробно (например, существенные изменения в алгоритме были с переходом 9.3 -> 9.4).
Первой мыслью было именно то, что кто-то в другом домене сделал glue с именами из нашего, однако, на тестовых доменах воспроизвести не удалось.
Зато удалось убедиться и воспроизвести ситуацию, когда при удалении IP адресов для nserver у регистратора, соответствующие glue records не удаляются из .RU.
Зато удалось убедиться и воспроизвести ситуацию, когда при удалении IP адресов для nserver у регистратора, соответствующие glue records не удаляются из .RU.
Однако! Всегда считал RU-Center весьма компетентной и серьёзной организацией. Автору отдельное спасибо за «срыв покровов», по крайней мере лично мне было очень познавательно.
Как правильно заметил знакомый, сами виноваты, что делали в последний день. Другой товарищ сказал, что нужно было сразу сделать сделать так, как предложили в первом ответе на заявку, достигли бы цели и появилось время на неспешное решение. С другой стороны, конечной целью было найти источник проблемы и исключить повторение в будущем.
По поводу скорости ответа поддержки могу сказать, что во многих организациях есть несколько линий поддержки, у которых цель — снизить нагрузку на технических специалистов, оказывая помощь по типовым вопросам. В нестандартных ситуациях, к сожалению, такая схема часто замедляет решение проблем. Но, конечно, когда оказываешься «на той стороне» (видишь ситуацию глазами клиента), остаётся не очень приятное ощущение.
По поводу скорости ответа поддержки могу сказать, что во многих организациях есть несколько линий поддержки, у которых цель — снизить нагрузку на технических специалистов, оказывая помощь по типовым вопросам. В нестандартных ситуациях, к сожалению, такая схема часто замедляет решение проблем. Но, конечно, когда оказываешься «на той стороне» (видишь ситуацию глазами клиента), остаётся не очень приятное ощущение.
Возможно не прав, но после того как ру центр при открытии доменной зоны рф, после того проверки доступности покупки домена, этот домен автоматически регистрировался на ру центр, это компания потеряла для меня авторитет.
В техподдержке RU-Center далеко не все админы вообще в курсе что такое Glue Record. У них это называется Именованные DNS-серверы.
Так а при чем тут глю рекорд?
Во втором случае это не глюрекорд вообще. Это просто кривой софт у них
Окей, разворачиваю.
Глюрекорд прописывается для зоны только в случае нахождения нс-ов в этой самой зоне. Эта информация обязателльно есть хуиз
Для второго домена никакой глюрекорда быть в принципе не может — его нсы в другой зоне
Могу только предположить почему так произошло: для минимизации трафика к днс-у во время прописывания нс-ов они резолвятся и жестко прописываются, скорее всего это сделано только для своей подконтрольной ру-зоны. Скорее всего есть механизм обновления этих данных
В reg.ru аналогичная ситуцация с .ru. Только там техподдержке пришлось 5 дней объяснять, что такое glue records и проблему так и не решили.
P.S. glue records никуда не исчезали. Без них не будет работать dns.
;; 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.
Вроде бы у вас не совсем такая ситуация, но весьма похожая и вызванная той же проблемой?
У вас IP адреса (для ns1.relevate.ru. ns2.relevate.ru.) в ответах от ваших NS (dns1.relevate.ru. и dns2.relevate.ru.) и от корневых NS показывают одинаковые IP, но разный TTL. Т.е. вы уже раньше меняли glue на правильный?
В самой зоне совсем другие glue.
Получается, что проблема в зоне .RU и не зависит от регистратора?
У вас 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 и не зависит от регистратора?
Т.е. вы уже раньше меняли glue на правильный?
Да, пришлось у relevate.ru прописать ns1/ns1 с «правильными» ip, а потом сменить обратно на dns1/dns2, чтобы корневые серверы обновили записи A.
Получается, что glue records из зоны не удаляются пока на них делегирован хоть один домен. Это противоречит здравому смыслу.
Да, противоречит. Ниже в каментах предположение на эту тему.
Как сказали выше, 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, хотя и не означает, что они не нужны вовсе.
Писать об этой проблеме нужно в ТЦИ.
Их особенность в том, что они не являются «собственностью» родительской зоны, т.е. если А запись в родительской зоне не совпадает с таковой в дочерней, будет закэширована вторая, поэтому в идеале 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, хотя и не означает, что они не нужны вовсе.
Писать об этой проблеме нужно в ТЦИ.
Получается, бага во взаимодействии между регистраторами и ТЦИ? Т.е. когда регистратор передаёт данные о делегировании домена, старые записи Glue не очищаются. Судя по информации http://tcinet.ru/about/ проблема будет для .RU,.РФ, .SU,.ДЕТИ, .TATAR.
А они и не должны сами по себе очищаться — вот это точно было бы ошибкой.
Баги как таковой нету, есть выбор между несколькими видами зла.
Тут возможны несколько стратегий поведения:
В первом случае возможны проблемы типа вашей, но взамен в среднем ускоряется время резолва;
Второй вариант противоположен первому плюс добавляется неопределенность в случае разделегирования домена, в котором располагались 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.
Баги как таковой нету, есть выбор между несколькими видами зла.
Тут возможны несколько стратегий поведения:
- Принимать все дочерние для зоны 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.
Насколько я понимаю, для .RU сейчас работает второй вариант, но при удалении glue не происходит очистки в зоне TLD. Тесты показывают именно такую ситуацию.
Я могу ошибаться, но мне кажется, что как раз наоборот, по ситуации с body-m-auto.ru работает скорее первый вариант. Будь использован второй вариант, то ns10.INGAVTO.RU и ns11.INGAVTO.RU приняли бы в качестве glue исключительно в случае, если они прописаны как NS'ы для INGAVTO.RU, а это не так.
Первый вариант как раз описывает, что если у нас NS располагается в домене зоны RU (например ns10.INGAVTO.RU), то его можно прописать в этой зоне для любого дочернего домена. В случае второго вариант его можно было бы прописать как glue только если бы сам родительский домен этого NS'а (INGAVTO.RU) был проделегирован на него.
Но за более точными и конкретными комментариями лучше обратиться в ТЦИ.
Первый вариант как раз описывает, что если у нас NS располагается в домене зоны RU (например ns10.INGAVTO.RU), то его можно прописать в этой зоне для любого дочернего домена. В случае второго вариант его можно было бы прописать как glue только если бы сам родительский домен этого NS'а (INGAVTO.RU) был проделегирован на него.
Но за более точными и конкретными комментариями лучше обратиться в ТЦИ.
В Ру-центре мне ответили, что нельзя удалить glue record пока на неё проделегирован хотя бы один домен.
И не важно, что я владелец example.com
Например, не могу удалить ns3.IHC.RU хотя я администратор домена IHC.RU
С другой стороны, есть домены, проделегированные на несуществующую 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::
В Ру-центре мне ответили, что нельзя удалить glue record пока на неё проделегирован хотя бы один домен.
Этот вопрос нигде не оговаривается, кроме фразы «объект HOST живет до тех пор пока на него ссылается хотя бы один объект DOMAIN», ну или как-то так. Т.е. прямого утверждения о невозможности удаления нет. Технические условия и политика доменов есть на сайте ТЦИ в свободном доступе.
С другой стороны, есть домены, проделегированные на несуществующую glue record:
Ну, это не glue record. glue record — это адресная запись в зоне верхнего уровня. NS запись в зоне верхнего уровня называется zone cut.
В целом делегирование на несуществующий хост ничему не противоречит :) нет такого технического требования — проверять существование NS'а.
всё не так. Фраза «нельзя удалить, пока на него ссылается хотя бы одна запись» относится только к этому же домену. Если у вас домен 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-адрес.
В общих чертах фраза означает, что 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-адрес.
Объект host хранится в реестре до тех пор, пока хотя бы один зарегистрированный домен имеет ссылку на этот объект.
Вот прямая цитата из технических условий, пункт 3.4.4. Как видите, в ней нет указаний на то, что она относится только к этому же домену, в котором живут серверы. Впрочем, из нее следует, что в предыдущем комментарии я несколько погрешил против истины.
Вообще, получается некая двусмысленность: с одной стороны удалить нельзя, с другой, пусть и с геморроем, но можно.
Так пускай 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.ru
Так что если example.ru делегирует на ваши серверы с левым ip-адресом:
ns1.domain.ru 127.0.0.1
ns2.domain.ru 127.0.0.2
то ничего не произойдет, потому что реестр в корневые серверы заносит Glue Record только записи от владельца домена domain.ru, а не от example.ru
Я, если честно, не очень понимаю зачем вы повторяете то, что я описывал несколькими комментариями ранее.
И что значит «пускай»? У нас есть объективная реальность, в которой для реестра выбрана другая политика относительно glue записей. Изменить ее можно только обратившись в ТЦИ и доказав ее несостоятельность. Надеюсь, вы не думаете, что в логику работы реестра домена верхнего уровня кто-то будет вносить изменения руководствуясь комментарием на хабре?
И что значит «пускай»? У нас есть объективная реальность, в которой для реестра выбрана другая политика относительно glue записей. Изменить ее можно только обратившись в ТЦИ и доказав ее несостоятельность. Надеюсь, вы не думаете, что в логику работы реестра домена верхнего уровня кто-то будет вносить изменения руководствуясь комментарием на хабре?
Тоже перестал всё понимать. Проблемы не вижу в упор. Glue Records управляет владелец домена (domain.ru для *.domain.ru).
Что должно само удаляться-то? Если владелец создал «ns3.domain.ru 127.0.0.1», а потом удалил его (просто проделегировав на ns1.domain.ru… и ns2.domain.ru)? В таком случае сам себе буратино. У реестра нормальная политика — если запись есть или была, она всё-равно будет храниться еще 30 дней, даже если на неё никто не ссылается.
Что должно само удаляться-то? Если владелец создал «ns3.domain.ru 127.0.0.1», а потом удалил его (просто проделегировав на ns1.domain.ru… и ns2.domain.ru)? В таком случае сам себе буратино. У реестра нормальная политика — если запись есть или была, она всё-равно будет храниться еще 30 дней, даже если на неё никто не ссылается.
но она же не может храниться с весны 2011 по зиму 2016?
Если что-то существует и есть ссылка на оное, то оно будет храниться, в документации это указано.
Я так понял проблема в том, что регистратор не чистит список ранее установленных ns-серверов, если вы передали другие. Так? Из документации это нигде не следует, поэтому и не чистят.
В любом случае, просто поменять делегирование авторитарных серверов — достаточно необычное занятие, которое нужно проводить очень чутко. Можно ошибиться и разделегировать домен вовсе. Хорошо, что корневые реестры это не едят так быстро, как gtld, а может и плохо…
Я так понял проблема в том, что регистратор не чистит список ранее установленных ns-серверов, если вы передали другие. Так? Из документации это нигде не следует, поэтому и не чистят.
В любом случае, просто поменять делегирование авторитарных серверов — достаточно необычное занятие, которое нужно проводить очень чутко. Можно ошибиться и разделегировать домен вовсе. Хорошо, что корневые реестры это не едят так быстро, как gtld, а может и плохо…
Оказалось, что удалить можно, но нужно пройти все круги поддержки :)
Статья о том, как облажаться и свалить всё на регистратора, приправив это всё ложными утверждениями про «отменённые glue records».
Всё не так плохо, как Вы описываете.
Корневые серверы имеют ровно ту информацию, которую вы указываете при делегировании домена. Если ранее использовался 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!
Корневые серверы имеют ровно ту информацию, которую вы указываете при делегировании домена. Если ранее использовался 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!
посмотрите пример в конце поста, воспроизвели ситуацию для двух других доменов.
и также см. камент про аналогичную ситуацию у reg.ru.
и также см. камент про аналогичную ситуацию у reg.ru.
Нет, проблемы не вижу.
По ссылке коммента:
домен 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:
обратите внимание, что последний ответ пришел с сервера 178.57.216.5 — relevate.ru
По ссылке коммента:
домен 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.ru
Проблема в том, что с a.dns.ripn.net. в ADDITIONAL SECTION для ns1.RELEVATE.RU и ns2.RELEVATE.RU приходят данные, которые могут не соответствовать данным в зоне RELEVATE.RU (отличается TTL).
Аналогично и для тестовых зон, там кроме TTL еще отличаются и IP адреса (см. данные в конце статьи)
$ 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 адреса (см. данные в конце статьи)
Насчет +trace для тестовых body-m-auto.ru и ingavto.ru — там будет «всё хорошо», однако, например, рекурсивный DNS провайдера (например BIND9, 9.9.5-9+deb8u7-Debian у ТТК ), закеширует неправильные IP адреса для ns11.ingavto.ru. и ns10.ingavto.ru. (те, которые были когда-то указаны как Glue Record, а потом удалены).
Ну так это проблема кэша и кривых рук провайдера. Вы тут никак не решите её.
Я вынимал авторитарный сервер из зоны, всё ровно:
Через 2 часа 90% запросов уходит. Остаются какие-то китайцы и жутко пухлые кэши с космическим ttl. Вырубаете сервер и их запросы по roundrobin уходят на рабочий сервер.
В вашем случае проблема в том, что где-то в кэше у провайдеров лежат старые glue records, а вы резко переехали на все новые. В таких ситуациях полный переезд на новые ip нужно растягивать во времени, а вот менять один на другой — хоть каждый день.
Я вынимал авторитарный сервер из зоны, всё ровно:
Через 2 часа 90% запросов уходит. Остаются какие-то китайцы и жутко пухлые кэши с космическим ttl. Вырубаете сервер и их запросы по roundrobin уходят на рабочий сервер.
В вашем случае проблема в том, что где-то в кэше у провайдеров лежат старые glue records, а вы резко переехали на все новые. В таких ситуациях полный переезд на новые ip нужно растягивать во времени, а вот менять один на другой — хоть каждый день.
> Первый домен делегируем на другие NS, в зоне меняем в A записях адреса для ns10.ingavto.ru и ns11.ingavto.ru, также ждём обновления.
Только в зоне? А у регистратора ingavto.ru тоже меняли при этом записи (указывали новые IP адреса)? Надо менять…
Если домен делегирован на ns которые созданы в самой доменной зоне — то IP адреса надо указывать у регистратора доменного имена. Иначе как система DNS узнает на каком IP адресе они живут?
Только в зоне? А у регистратора ingavto.ru тоже меняли при этом записи (указывали новые IP адреса)? Надо менять…
Если домен делегирован на ns которые созданы в самой доменной зоне — то IP адреса надо указывать у регистратора доменного имена. Иначе как система DNS узнает на каком IP адресе они живут?
> А у регистратора ingavto.ru тоже меняли при этом записи (указывали новые IP адреса)
поясните, пожалуйста, мысль
поясните, пожалуйста, мысль
Вы в доменной зоне на DNS сервере пошли и изменили ns10 и ns11 указав на новые IP адреса
Помимо этого надо было пойти в интерфейс регистратора доменного имени и там тоже указать для ns10.ingavto.ru и ns11.ingavto.ru новые IP
Вы это судя по всему не делали, а изменять записи только в зоне недостаточно, поскольку записи созданы в самом домене и система DNS не направит на них запросы не зная откуда их взять
Помимо этого надо было пойти в интерфейс регистратора доменного имени и там тоже указать для ns10.ingavto.ru и ns11.ingavto.ru новые IP
Вы это судя по всему не делали, а изменять записи только в зоне недостаточно, поскольку записи созданы в самом домене и система DNS не направит на них запросы не зная откуда их взять
Автор ошибается, Glue Records ни разу не устаревшая технология и не переставала использоваться. Скорее даже наоборот — почти все существующие домены так или иначе её используют.
Суть Glue Records в возможности делегировать домен на NS сервера, находящиеся непосредственно в зоне этого домена и поддерживать на них записи зоны.
Делается это очень просто — при делегировании домена на NS сервера указывается не только их DNS имена, но и IP адреса + на DNS серверах, на которые выполнено делегирование зоны, вносятся записи зоны — в частности NS записи указывающие на IP адреса этих DNS серверов.
Технология активно используется провайдерами услуг (к примеру хостерами и регистраторами) и крупными компаниями. А через провайдеров технология используется и всеми остальными.
Пример: когда клиент хостера делегирует свой домен client.com на ns[1-2].hoster.net он начинает использовать Glue Records домена хостера.
Что касается темы статьи и озвученной автором проблемы — из-за стиля написания сложно понять есть ли тут реальная проблема/особенность или же имеет место только некорректное применение технологии Glue Records. Для однозначной диагностики проблемы в статье недостаточно данных.
Суть Glue Records в возможности делегировать домен на NS сервера, находящиеся непосредственно в зоне этого домена и поддерживать на них записи зоны.
Делается это очень просто — при делегировании домена на NS сервера указывается не только их DNS имена, но и IP адреса + на DNS серверах, на которые выполнено делегирование зоны, вносятся записи зоны — в частности NS записи указывающие на IP адреса этих DNS серверов.
Технология активно используется провайдерами услуг (к примеру хостерами и регистраторами) и крупными компаниями. А через провайдеров технология используется и всеми остальными.
Пример: когда клиент хостера делегирует свой домен client.com на ns[1-2].hoster.net он начинает использовать Glue Records домена хостера.
Что касается темы статьи и озвученной автором проблемы — из-за стиля написания сложно понять есть ли тут реальная проблема/особенность или же имеет место только некорректное применение технологии Glue Records. Для однозначной диагностики проблемы в статье недостаточно данных.
Где написано, что Glue Records — устаревшая технология?
Суть поста в том, что для .RU есть проблемы с Glue Records.
Как воспроизвести проблему, написано в «Глава 9»
Суть поста в том, что для .RU есть проблемы с Glue Records.
Как воспроизвести проблему, написано в «Глава 9»
Суть Glue Records в возможности делегировать домен на NS сервера, находящиеся непосредственно в зоне этого домена
Пример: когда клиент хостера делегирует свой домен client.com на ns[1-2].hoster.net он начинает использовать Glue Records домена хостера.
выходит, glue records используется не по назначению?
А вот и мой «негативный» опыт с Гарант Парк Телеком: https://www.stableit.ru/2013/12/r01ru.html Как раз при правке glue records :)
Жутко болит голова, и по этому, в качестве предположения (без копания куда то в глубину).
Когда то давно, когда запускали первую версию парковки доменов в ру-центре, нам для этого сервиса пришлось делать пару NS серверов, заточенных строго под этот сервис.
Они очень маленькие, на фряхе, там бинд, но не простой, он хранит записи зон в постгри.
и в отличии от простого бинда, который хранит зоны в текстовых файлах, отдают они зону на порядки быстрее.
Глядя на чехарду с доменами в рунете я вспоминаю свои днсы и думаю, не виноваты ли они в этом.
Может про них просто забыли.
Это было почти 10 лет назад, а работают они до сих, по моему. ))
Надо проверить, не проходили ли ваши домены через парковку доменов.
Когда то давно, когда запускали первую версию парковки доменов в ру-центре, нам для этого сервиса пришлось делать пару NS серверов, заточенных строго под этот сервис.
Они очень маленькие, на фряхе, там бинд, но не простой, он хранит записи зон в постгри.
и в отличии от простого бинда, который хранит зоны в текстовых файлах, отдают они зону на порядки быстрее.
Глядя на чехарду с доменами в рунете я вспоминаю свои днсы и думаю, не виноваты ли они в этом.
Может про них просто забыли.
Это было почти 10 лет назад, а работают они до сих, по моему. ))
Надо проверить, не проходили ли ваши домены через парковку доменов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Багофича .RU или как получить проблемы там, где их не должно быть уже много лет