Perché un record CNAME non può essere utilizzato all'apice (aka root) di un dominio?

Questa è una domanda canonica sui CNAME agli apici (o alle radici) delle zone

È conoscenza relativamente comune che i CNAMErecord all'apice di un dominio sono una pratica tabù.

Esempio: example.com. IN CNAME ithurts.example.net.

Nel migliore dei casi, il software nameserver potrebbe rifiutare di caricare la configurazione e, nel peggiore dei casi, accettare questa configurazione e invalidare la configurazione per esempio.com.

Recentemente ho avuto una società di web hosting che ha passato le istruzioni a un'unità di business di cui avevamo bisogno per CNAME l'apice del nostro dominio per un nuovo record. Sapendo che questa sarebbe una configurazione suicida se nutrita con BIND, ho avvisato loro che non saremmo stati in grado di ottemperare e che questo era un consiglio a castello in generale. La società di web hosting ha affermato che non è assolutamente vietato dalle RFC che definiscono gli standard e che il loro software lo supporta. Se non potessimo CNAME l'apice, il loro consiglio era di non avere alcun record di apice e non avrebbero fornito un server web di reindirizzamento. ...Che cosa?

Molti di noi sanno che RFC1912 insiste sul fatto che A CNAME record is not allowed to coexist with any other data., ma siamo onesti con noi stessi, che RFC è solo informativo. Il più vicino che conosco per parlare che proibisce la pratica è da RFC1034 :

Se un RR CNAME è presente in un nodo, non dovrebbero essere presenti altri dati; questo assicura che i dati per un nome canonico e i suoi alias non possano essere diversi.

Sfortunatamente sono stato nel settore abbastanza a lungo da sapere che "non dovrebbe" non è lo stesso di "non deve", e questa è la corda sufficiente per la maggior parte dei progettisti di software con cui aggrapparsi. Sapendo che qualsiasi cosa al di fuori di un collegamento conciso a una schiacciata sarebbe stata una perdita del mio tempo, ho finito per lasciare che la società scappasse con un rimprovero per raccomandare configurazioni che potrebbero rompere il software di uso comune senza una corretta divulgazione.

Questo ci porta alle domande e risposte. Per una volta mi piacerebbe che diventassimo davvero tecnici sulla follia dei CNAME dell'apice e non aggirassimo il problema come facciamo di solito quando qualcuno pubblica un post sull'argomento. RFC1912 è off limits, così come qualsiasi altra RFC informativa applicabile qui che non ho pensato. Chiudiamo questo bambino.

CNAMEi record sono stati originariamente creati per consentire a più nomi che forniscono la stessa risorsa di essere aliasati a un singolo "nome canonico" per la risorsa. Con l'avvento dell'hosting virtuale basato sul nome, è diventato invece un luogo comune usarli come forma generica di aliasing dell'indirizzo IP. Sfortunatamente, la maggior parte delle persone che provengono da un background di web hosting si aspettano che i CNAMErecord indichino l' equivalenza nel DNS , che non è mai stato l'intento. L'apice contiene tipi record che sono chiaramente non utilizzati per l'identificazione di una risorsa host canonica ( NS, SOA), che non possono essere alias senza rompere lo standard a livello fondamentale. (in particolare per quanto riguarda i tagli di zona )

Sfortunatamente, lo standard DNS originale è stato scritto prima che gli standard che regolavano gli organi comprendessero che era necessaria una verbosità esplicita per definire un comportamento coerente ( RFC 2119 ). È stato necessario creare RFC 2181 per chiarire diversi casi angolari dovuti a una formulazione vaga e la verbosità aggiornata chiarisce che CNAME non è possibile utilizzare a per ottenere l'aliasing dell'apice senza infrangere lo standard.

6.1. Autorità di zona

I server autorevoli per una zona sono elencati nei record NS per l'origine della zona che, insieme a un record Start of Authority (SOA), sono i record obbligatori in ogni zona. Tale server è autorevole per tutti i record di risorse in una zona che non si trova in un'altra zona. I record NS che indicano un taglio di zona sono di proprietà della zona figlio creata, così come qualsiasi altro record per l'origine di quella zona figlio o eventuali sottodomini di essa. Un server per una zona non deve restituire risposte autorevoli per le query relative ai nomi in un'altra zona, che include i record NS e forse A, in corrispondenza di un taglio di zona, a meno che non capiti anche che sia un server per l'altra zona.

Questo stabilisce che SOAe i NSrecord sono obbligatori, ma non dice nulla Ao altri tipi che appaiono qui. Può sembrare superfluo che cito questo allora, ma diventerà più rilevante in un momento.

RFC 1034 era alquanto vago sui problemi che possono sorgere quando CNAMEesiste accanto ad altri tipi di record. RFC 2181 rimuove l'ambiguità e afferma esplicitamente i tipi di record che possono esistere al loro fianco:

10.1. Record di risorse CNAME

Il record DNS CNAME ("nome canonico") esiste per fornire il nome canonico associato a un nome alias. Può esserci un solo nome canonico per ogni alias. Tale nome dovrebbe generalmente essere un nome esistente altrove nel DNS, sebbene esistano alcune rare applicazioni per alias con il nome canonico di accompagnamento non definito nel DNS. Un nome alias (etichetta di un record CNAME) può, se è in uso DNSSEC, avere RR SIG, NXT e KEY, ma potrebbe non avere altri dati. Cioè, per qualsiasi etichetta nel DNS (qualsiasi nome di dominio), è vera una delle seguenti condizioni:

• esiste un record CNAME, facoltativamente accompagnato da SIG, NXT e KEY RRs,
• esistono uno o più record, nessuno dei quali è record CNAME,
• il nome esiste, ma non ha RR associati di alcun tipo,
• il nome non esiste affatto.

"nome alias" in questo contesto si riferisce al lato sinistro del CNAMErecord. L'elenco puntato chiarisce esplicitamente che a SOA, NSe i Arecord non possono essere visualizzati in un nodo in cui CNAMEappare anche a. Quando lo combiniamo con la sezione 6.1, è impossibile CNAMEche esista all'apice in quanto dovrebbe convivere con l'obbligo SOAe i NSregistri.

(Questo sembra fare il lavoro, ma se qualcuno ha un percorso più breve per la prova, per favore, provaci.)

Aggiornare:

Sembra che la confusione più recente derivi dalla recente decisione di Cloudflare di consentire la definizione di un record CNAME illegale all'apice dei domini, per il quale sintetizzeranno i record A. "Conformità RFC", come descritto nell'articolo collegato, si riferisce al fatto che i record sintetizzati da Cloudflare funzioneranno bene con DNS. Ciò non cambia il fatto che si tratta di un comportamento completamente personalizzato.

A mio avviso, questo è un disservizio per la più ampia comunità DNS: in realtà non è un record CNAME e induce in errore le persone a credere che altri software siano carenti per non averlo permesso. (come dimostra la mia domanda)

L'Internet Systems Consortium ha recentemente pubblicato un articolo su CNAME all'apice di una zona , perché esiste questa limitazione e una serie di alternative. Questo non è probabile che cambi presto, purtroppo:

Non possiamo cambiare il modo in cui viene utilizzato lo speciale record CNAME senza modificare contemporaneamente tutte le implementazioni del server DNS nel mondo. Questo perché il suo significato e la sua interpretazione erano rigorosamente definiti nel protocollo DNS; tutte le attuali implementazioni client e server DNS aderiscono a questa specifica. Il tentativo di "rilassare" il modo in cui CNAME viene utilizzato nei server autorevoli senza modificare contemporaneamente tutti i resolver DNS attualmente in funzione causerà l'interruzione della risoluzione dei nomi (e i servizi Web ed e-mail diventeranno intermittentemente non disponibili per quelle organizzazioni che implementano soluzioni server autorevoli "rilassate".

Ma c'è speranza:

Un'altra potenziale soluzione attualmente in discussione aggiungerebbe un nuovo tipo di record di risorse DNS che i browser avrebbero cercato, che potrebbe esistere all'apice. Questo sarebbe un nome host specifico dell'applicazione per le richieste http (simile al modo in cui MX funziona).

Pro: Questo è completamente coerente con il design DNS.
Contro: questo non è ancora disponibile e richiederebbe un aggiornamento client del browser.

Se stai reindirizzando un'intera zona, devi utilizzare DNAME. Secondo RFC 6672 ,

Il DNAME RR e il CNAME RR [RFC1034] fanno sì che una ricerca restituisca (potenzialmente) dati corrispondenti a un nome di dominio diverso dal nome di dominio richiesto. La differenza tra i due record di risorse è che il RR CNAME indirizza la ricerca dei dati presso il suo proprietario verso un altro nome singolo, mentre un RR DNAME indirizza le ricerche per i dati discendenti del nome del proprietario verso nomi corrispondenti sotto un diverso (singolo) nodo di l'albero.

Ad esempio, esaminare una zona (vedere RFC 1034 [RFC1034], Sezione 4.3.2, passaggio 3) per il nome di dominio "foo.example.com" e un record di risorse DNAME si trova in "example.com" che indica che tutte le query in "esempio.com" siano indirizzate a "esempio.net". Il processo di ricerca tornerà al passaggio 1 con il nuovo nome della query "foo.example.net". Se il nome della query fosse "www.foo.example.com", il nuovo nome della query sarebbe "www.foo.example.net".