Вопрос: В DNS может IN IN указывать CNAME?


Возможно ли, чтобы запись 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

Это, похоже, не работает в bind, хотя это (конечно) делает:

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

Любые указатели на RFC, запрещающие эту установку, будут оценены.


15
2018-01-14 19:36


Источник




Ответы:


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

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

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


19
2018-01-14 19:56



А также RFC1034 говорит: «Доменные имена в RR, которые указывают на другое имя, должны всегда указывать на первичное имя, а не на псевдоним. Это позволяет избежать дополнительных ограничений при доступе к информации ... Конечно, по принципу надежности программное обеспечение домена не должно терпеть неудачу при представлении с целями CNAME или циклами, следует следовать целям CNAME, а циклы CNAME - как ошибка ». - larsks
Я обнаружил, что RFC 2181 10.3 четко говорит, что он недействителен, но ваш ответ был достаточно хорошим. - Mark Wagner
Для дополнительной ясности: MUST NOT словосочетание здесь не имеет значения, поскольку RFC 1912 является информационным и не определяет стандарт. Марк верно, что RFC 2181 является правильной ссылкой. (RFC 1034 был написан до того, как языковые стандарты затвердели, следовательно, неопределенность) - Andrew B