Это чушь полнейшая на самом деле. В зоне com порядка 100 миллионов доменов, в de и net — 15 миллионов и так далее. В общем 5% там и не пахнет, дай бог сотая часть, а скорее всего и того меньше.
И что значит «пускай»? У нас есть объективная реальность, в которой для реестра выбрана другая политика относительно glue записей. Изменить ее можно только обратившись в ТЦИ и доказав ее несостоятельность. Надеюсь, вы не думаете, что в логику работы реестра домена верхнего уровня кто-то будет вносить изменения руководствуясь комментарием на хабре?
Объект host хранится в реестре до тех пор, пока хотя бы один зарегистрированный домен имеет ссылку на этот объект.
Вот прямая цитата из технических условий, пункт 3.4.4. Как видите, в ней нет указаний на то, что она относится только к этому же домену, в котором живут серверы. Впрочем, из нее следует, что в предыдущем комментарии я несколько погрешил против истины.
Вообще, получается некая двусмысленность: с одной стороны удалить нельзя, с другой, пусть и с геморроем, но можно.
В Ру-центре мне ответили, что нельзя удалить glue record пока на неё проделегирован хотя бы один домен.
Этот вопрос нигде не оговаривается, кроме фразы «объект HOST живет до тех пор пока на него ссылается хотя бы один объект DOMAIN», ну или как-то так. Т.е. прямого утверждения о невозможности удаления нет. Технические условия и политика доменов есть на сайте ТЦИ в свободном доступе.
С другой стороны, есть домены, проделегированные на несуществующую glue record:
Ну, это не glue record. glue record — это адресная запись в зоне верхнего уровня. NS запись в зоне верхнего уровня называется zone cut.
В целом делегирование на несуществующий хост ничему не противоречит :) нет такого технического требования — проверять существование NS'а.
Я могу ошибаться, но мне кажется, что как раз наоборот, по ситуации с body-m-auto.ru работает скорее первый вариант. Будь использован второй вариант, то ns10.INGAVTO.RU и ns11.INGAVTO.RU приняли бы в качестве glue исключительно в случае, если они прописаны как NS'ы для INGAVTO.RU, а это не так.
Первый вариант как раз описывает, что если у нас NS располагается в домене зоны RU (например ns10.INGAVTO.RU), то его можно прописать в этой зоне для любого дочернего домена. В случае второго вариант его можно было бы прописать как glue только если бы сам родительский домен этого NS'а (INGAVTO.RU) был проделегирован на него.
Но за более точными и конкретными комментариями лучше обратиться в ТЦИ.
А они и не должны сами по себе очищаться — вот это точно было бы ошибкой.
Баги как таковой нету, есть выбор между несколькими видами зла.
Тут возможны несколько стратегий поведения:
Принимать все дочерние для зоны 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.
Как сказали выше, 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, хотя и не означает, что они не нужны вовсе.
Нет, я считаю, что спор Delphinum с shasoft о работе из дома не несет смысла и истина где-то посередине. Заключается она в том, что правила устанавливает работодатель, а работник уже для себя решает, что ему лучше — следовать им или нет.
1. Это да, я прочитал, но обновляться-то нужно, не всегда ж на девятке жить, да и базовый bind тоже лучше поменять на какую-нибудь ESV.
3.
шепотом
там ошибочка :)
4. Да, я ее пропустил, пардон.
5. Вы используете один и тот же ключ для аутентификации rndc и для подписи динамических апдейтов, это немножко несекьюрненько. То есть можно сказать «Да что там может случиться? Зачем все усложнять?», но это тот случай, когда проще перебдеть и сделать раздельные ключи, чем думать об этом, когда кто-то скажет: «А давай я буду слать эти апдейты со своего компа?». Кстати, что вы будете делать в этой ситуации?
6. Вот вам в копилочку еще одна слабость вашего скрипта: он позволяет только один апдейт за раз, при том, что даже сама nsupdate умеет менять записи пачками.
Тогда вот еще добавки:
1. В 10-й фре bind убрали из базы -> нужно ставить и конфиги будут, соответственно, в /usr/local/etc
2. Утилита называется rndc, если bind открывает сокет для нее на лупбеке, то файервол для нее трогать ни к чему. Кстати, распространенная ошибка, связанная с ним, заключается в том, что открывают 53 порт только для udp, забыв про tcp.
3. Зачем выполнять команду rndc reload? Для проверки работоспособности лучше подойдет rndc status.
4. В настройках bind'а не замечено allow-update -> nsupdate работать не будет, т.к. динамические обновления отключены по умолчанию.
5. Использовать ключ для rndc в качестве tsig'а — мягко выражаясь, неправильно.
6. В конце концов, зачем писать скрипт на шелле, сомневаюсь, что для пыхи нет какого-нибудь днс модуля, через который можно соорудить дднс без костылей.
И что значит «пускай»? У нас есть объективная реальность, в которой для реестра выбрана другая политика относительно glue записей. Изменить ее можно только обратившись в ТЦИ и доказав ее несостоятельность. Надеюсь, вы не думаете, что в логику работы реестра домена верхнего уровня кто-то будет вносить изменения руководствуясь комментарием на хабре?
Вот прямая цитата из технических условий, пункт 3.4.4. Как видите, в ней нет указаний на то, что она относится только к этому же домену, в котором живут серверы. Впрочем, из нее следует, что в предыдущем комментарии я несколько погрешил против истины.
Вообще, получается некая двусмысленность: с одной стороны удалить нельзя, с другой, пусть и с геморроем, но можно.
Этот вопрос нигде не оговаривается, кроме фразы «объект HOST живет до тех пор пока на него ссылается хотя бы один объект DOMAIN», ну или как-то так. Т.е. прямого утверждения о невозможности удаления нет. Технические условия и политика доменов есть на сайте ТЦИ в свободном доступе.
Ну, это не glue record. glue record — это адресная запись в зоне верхнего уровня. NS запись в зоне верхнего уровня называется zone cut.
В целом делегирование на несуществующий хост ничему не противоречит :) нет такого технического требования — проверять существование NS'а.
Первый вариант как раз описывает, что если у нас NS располагается в домене зоны RU (например ns10.INGAVTO.RU), то его можно прописать в этой зоне для любого дочернего домена. В случае второго вариант его можно было бы прописать как glue только если бы сам родительский домен этого NS'а (INGAVTO.RU) был проделегирован на него.
Но за более точными и конкретными комментариями лучше обратиться в ТЦИ.
Баги как таковой нету, есть выбор между несколькими видами зла.
Тут возможны несколько стратегий поведения:
В первом случае возможны проблемы типа вашей, но взамен в среднем ускоряется время резолва;
Второй вариант противоположен первому плюс добавляется неопределенность в случае разделегирования домена, в котором располагались 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.
Их особенность в том, что они не являются «собственностью» родительской зоны, т.е. если А запись в родительской зоне не совпадает с таковой в дочерней, будет закэширована вторая, поэтому в идеале 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, хотя и не означает, что они не нужны вовсе.
Писать об этой проблеме нужно в ТЦИ.
Нет, я считаю, что спор Delphinum с shasoft о работе из дома не несет смысла и истина где-то посередине. Заключается она в том, что правила устанавливает работодатель, а работник уже для себя решает, что ему лучше — следовать им или нет.
3.
4. Да, я ее пропустил, пардон.
5. Вы используете один и тот же ключ для аутентификации rndc и для подписи динамических апдейтов, это немножко несекьюрненько. То есть можно сказать «Да что там может случиться? Зачем все усложнять?», но это тот случай, когда проще перебдеть и сделать раздельные ключи, чем думать об этом, когда кто-то скажет: «А давай я буду слать эти апдейты со своего компа?». Кстати, что вы будете делать в этой ситуации?
6. Вот вам в копилочку еще одна слабость вашего скрипта: он позволяет только один апдейт за раз, при том, что даже сама nsupdate умеет менять записи пачками.
1. В 10-й фре bind убрали из базы -> нужно ставить и конфиги будут, соответственно, в /usr/local/etc
2. Утилита называется rndc, если bind открывает сокет для нее на лупбеке, то файервол для нее трогать ни к чему. Кстати, распространенная ошибка, связанная с ним, заключается в том, что открывают 53 порт только для udp, забыв про tcp.
3. Зачем выполнять команду rndc reload? Для проверки работоспособности лучше подойдет rndc status.
4. В настройках bind'а не замечено allow-update -> nsupdate работать не будет, т.к. динамические обновления отключены по умолчанию.
5. Использовать ключ для rndc в качестве tsig'а — мягко выражаясь, неправильно.
6. В конце концов, зачем писать скрипт на шелле, сомневаюсь, что для пыхи нет какого-нибудь днс модуля, через который можно соорудить дднс без костылей.