Nel DNS un IN NS può puntare a un CNAME?


17

È consentito che un record NS sia un CNAME? Per esempio:

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

Questo non sembra funzionare bene, sebbene questo (ovviamente):

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

Tutti i suggerimenti per RFC che vietano questa configurazione sarebbero apprezzati.

Risposte:


20

L'attuale RFC che definisce NS RR ( RFC1035 ) dice solo che è un nome di dominio senza specificare il tipo RR della destinazione (sebbene chiarisca che non può essere un IP). Ottiene una menzione specifica in RFC1912 , sezione 2.4:

Avere record NS che puntano a un CNAME è male e potrebbe entrare in conflitto con i server BIND correnti. In effetti, le attuali implementazioni di BIND ignoreranno tali record, portando probabilmente a una delega lame. Esiste un certo numero di controlli di sicurezza eseguiti in BIND per impedire lo spoofing dei record DNS NS. Inoltre, secondo quanto riferito, i server BIND più vecchi verranno catturati in un ciclo di query infinito nel tentativo di individuare l'indirizzo per il nameserver con alias, causando l'invio di un flusso continuo di richieste DNS.

Non proprio NON DEVE, ma sicuramente si adatta al comportamento che stai vedendo


5
E RFC1034 dice: "I nomi di dominio nei RR che indicano un altro nome devono sempre indicare il nome principale e non l'alias. Ciò evita ulteriori indicazioni indirette nell'accesso alle informazioni .... Naturalmente, secondo il principio di robustezza, il software di dominio non dovrebbe fallire quando presentato con catene o anelli CNAME; le catene CNAME devono essere seguite e gli anelli CNAME segnalati come errore. "
Larks

10
Ho scoperto che RFC 2181 10.3 afferma chiaramente che non è valido ma la tua risposta è stata abbastanza buona.
Mark Wagner,

1
Per maggiore chiarezza: la MUST NOTverbosità non ha importanza qui perché RFC 1912 è informativo e non definisce uno standard. Mark è corretto che RFC 2181 è il riferimento corretto. (RFC 1034 è stato scritto prima che gli standard linguistici si solidificassero, quindi la vaghezza)
Andrew B,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.