Как стать автором
Обновить
19
0

Пользователь

Отправить сообщение
Оно имеет отношение к вебу (Usage of top level domains for websites), а не к днс, а это разные вещи.
Сотая часть от кол-ва доменов во всех зонах верхнего уровня.
Это чушь полнейшая на самом деле. В зоне 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, хотя и не означает, что они не нужны вовсе.

Писать об этой проблеме нужно в ТЦИ.
Справедливости ради, O'Reilly — тоже издательство, а магазин у них — загляденье.
оффтоп
image


Нет, я считаю, что спор 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. В конце концов, зачем писать скрипт на шелле, сомневаюсь, что для пыхи нет какого-нибудь днс модуля, через который можно соорудить дднс без костылей.
Это да, при покупке. А если я, к примеру, удалил письмо или, того хуже, потерял доступ к почте?
Скажите, а как из профиля пользователя в вашем магазине получить ссылки на скачивание электрокниг?
Есть консольные вкладки, urxvt с опцией tabbed.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность