У DNS може IN NS вказувати на 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

Схоже, це не працює в поєднанні, хоча це (звичайно):

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

Будемо вдячні будь-які вказівки на RFC, що забороняють цю установку.

domain-name-system cname-record ns-record

— Марк Вагнер
джерело

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

Наявність записів NS, що вказують на CNAME, погано і може погано конфліктувати з поточними серверами BIND. Насправді, поточні BIND реалізації ігнорують подібні записи, можливо, призводять до кульгавої делегації. У BIND проводиться певна перевірка безпеки, щоб запобігти підробленню записів DNS NS. Крім того, старші сервери BIND, як повідомляється, потраплять у нескінченний цикл запитів, намагаючись з'ясувати адресу для псевдоніменного сервера імен, викликаючи надсилання безперервного потоку запитів DNS.

Не зовсім ОБОВ'ЯЗКОВО, але це, безумовно, відповідає поведінці, яку ви бачите

— jj33
джерело

І RFC1034 каже: "Доменні імена в RR, які вказують на інше ім'я, завжди повинні вказувати на основне ім'я, а не псевдонім. Це дозволяє уникнути додаткових перешкод у доступі до інформації .... Звичайно, за принципом надійності, програмне забезпечення домену не повинно провалюватися якщо вони представлені ланцюжками або петлями CNAME; слід керувати ланцюгами CNAME, а петлі CNAME сигналізувати як помилку. "

— larsks

Я виявив, що RFC 2181 10.3 чітко говорить, що він недійсний, але ваша відповідь була досить хорошою.

— Марк Вагнер

Для додаткової ясності: MUST NOTбагатослівність тут не має значення, оскільки RFC 1912 є інформаційним та не визначає стандарт. Позначте правильно, що RFC 2181 є правильним посиланням. (RFC 1034 був написаний до затвердження мовних стандартів, отже, розпливчастість)

— Андрій Б