Czy w DNS IN IN NS może wskazywać na CNAME?

Czy rekord NS może mieć nazwę CNAME? Na przykład:

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

Nie wydaje się to działać w trybie wiążącym, chociaż to (oczywiście) powoduje:

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

Będziemy wdzięczni za wszelkie wskaźniki RFC zabraniające tej konfiguracji.

domain-name-system cname-record ns-record

— Mark Wagner
źródło

Rzeczywisty RFC, który definiuje NS RR ( RFC1035 ), mówi tylko, że jest to nazwa domeny bez określania typu RR obiektu docelowego (chociaż wyraźnie wyjaśnia, że nie może to być adres IP). W RFC1912 wymieniono go jednak konkretnie , rozdział 2.4:

Posiadanie rekordów NS wskazujących na CNAME jest złe i może powodować konflikt z bieżącymi serwerami BIND. W rzeczywistości obecne implementacje BIND zignorują takie rekordy, prawdopodobnie prowadząc do kiepskiej delegacji. W BIND wykonano pewną kontrolę bezpieczeństwa, aby zapobiec fałszowaniu rekordów DNS NS. Ponadto podobno starsze serwery BIND zostaną złapane w nieskończoną pętlę zapytań, próbując znaleźć adres aliasu serwera nazw, powodując ciągły strumień żądań DNS.

Niezupełnie NIE MUSI, ale z pewnością pasuje do zachowania, które widzisz

— jj33
źródło

I RFC1034 mówi, „Nazwy domen w RR które wskazują na inną nazwą należy zawsze punkt na pierwotnej nazwy, a nie alias. Pozwala to uniknąć dodatkowych indirections w dostępie do informacji .... Oczywiście, na zasadzie solidności, oprogramowanie domeny powinna nie zawodzą gdy są prezentowane z łańcuchami lub pętlami CNAME; należy przestrzegać łańcuchów CNAME, a pętle CNAME są sygnalizowane jako błąd. ”

— larsks

Odkryłem, że RFC 2181 10.3 wyraźnie mówi, że jest nieważny, ale twoja odpowiedź była wystarczająco dobra.

— Mark Wagner

Dla większej przejrzystości: MUST NOTverbiage nie ma tutaj znaczenia, ponieważ RFC 1912 ma charakter informacyjny i nie definiuje standardu. Znak jest poprawny, że RFC 2181 jest poprawnym odniesieniem. (RFC 1034 został napisany przed utrwaleniem standardów językowych, stąd niejasność)

— Andrew B