В DNS может ли IN NS указывать на CNAME?


17

Разрешено ли иметь запись NS как CNAME? Например:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Это не работает в связке, хотя это (конечно):

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Будем благодарны за любые ссылки на RFC, запрещающие эту настройку.

Ответы:


20

Фактический RFC, который определяет NS RR ( RFC1035 ), просто говорит о том, что это доменное имя без указания типа RR цели (хотя оно и дает понять, что это не может быть IP). Тем не менее, в RFC1912 есть конкретное упоминание , раздел 2.4:

Наличие записей NS, указывающих на CNAME, плохо и может плохо конфликтовать с текущими серверами BIND. Фактически, текущие реализации BIND будут игнорировать такие записи, что может привести к неудачному делегированию. В BIND выполняется определенная проверка безопасности, чтобы предотвратить подделку записей DNS NS. Кроме того, старые серверы BIND, как сообщается, попадут в бесконечный цикл запросов, пытаясь выяснить адрес псевдонимного сервера имен, вызывая непрерывный поток запросов DNS.

Не совсем НЕ ДОЛЖЕН, но, безусловно, соответствует поведению, которое вы видите


5
А в RFC1034 говорится: «Доменные имена в RR, которые указывают на другое имя, всегда должны указывать на основное имя, а не на псевдоним. Это позволяет избежать лишних косвенных указаний при доступе к информации ... Конечно, по принципу надежности, программное обеспечение домена не должно выходить из строя. при наличии цепочек или петель CNAME следует использовать цепочки CNAME, а петли CNAME сигнализируют об ошибке ".
Жаворонки

10
Я обнаружил, что RFC 2181 10.3 ясно говорит, что он недействителен, но ваш ответ был достаточно хорошим.
Марк Вагнер

1
Для большей ясности: здесь MUST NOTне имеет значения словоблудие, потому что RFC 1912 является Информационным и не определяет стандарт. Отметьте правильно, что RFC 2181 является правильной ссылкой. (RFC 1034 был написан до того, как языковые стандарты укрепились, отсюда и расплывчатость)
Эндрю Б.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.