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


117

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.


1
RFC 1034 precede RFC 2119 per un bel po 'di tempo ed esperienza.
Michael Hampton

Risposte:


94

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)


8
Sono d'accordo con questa dimostrazione e non credo che questo percorso di prova in due fasi sia particolarmente lungo o contorto. (1. l'apice di zona deve avere almeno SOA+ NSrecord, 2. i CNAMErecord non possono coesistere con altri dati)
Håkan Lindqvist,

2
Nel complesso, penso che sia un'ottima spiegazione. Se si potesse aggiungere qualcosa, penso che probabilmente spiegherebbe ulteriormente cosa CNAMEsignifichi effettivamente un disco, poiché è probabilmente il tipo di record più ampiamente frainteso. Anche se questo è un po 'oltre il punto, penso che questa sia una FAQ sia il risultato diretto di molti (la maggior parte?) Che non hanno una corretta comprensione CNAME.
Håkan Lindqvist,

2
OK è illegale ma ha senso? Perché un dominio con un CNAME necessita di record NS e SOA? E se lo fa, perché non può averli?
Denis Howe,

2
@Denis Non è possibile rispondere in modo completo in un commento. La risposta più breve è che è necessario leggere gli RFC (1034, 1035) e avere una buona comprensione di quali sono i riferimenti, quali sono i comportamenti richiesti per un rinvio (AUTORITÀ, presenza di record SOA, ecc.) E perché questo tipo di l'aliasing "senza referral" viola molte aspettative dei server DNS a livello funzionale. E questo è solo per cominciare. Questa domanda non è un buon argomento qui perché è speculativa e non radicata in un problema che potresti incontrare lavorando con un server DNS progettato correttamente e conforme agli standard.
Andrew B,

6
@Ekevoo Si può sostenere che le implementazioni HTTP avrebbero dovuto SRVinvece essere adottate , il che avrebbe anche reso questo un problema. Il problema non si limita a ciò che viene discusso qui; CNAMEè, contrariamente alla credenza popolare, non una grande corrispondenza per ciò che è necessario. Alla fine, poiché CNAMEnon funziona come le persone si aspettano (!) E non può essere riprogettato retroattivamente e poiché le implementazioni HTTP non vengono utilizzate SRV, sembra più probabile che la funzionalità di stile "alias" diventi più diffusa per soddisfare HTTP (specifico del tipo di record aliasing implementato dietro le quinte anziché come tipo di record visibile)
Håkan Lindqvist,

2

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.


2
"Speranza"? Esisteva già una "soluzione", ovvero i record SRV HTTP, ma questi erano universalmente respinti. Ciò che non è chiaro è quale sia il "problema".
Michael Hampton

Non ero nemmeno a conoscenza di HTTP SRV, quindi non ho idea del perché sia ​​stato rifiutato. Speriamo che questa potenziale nuova soluzione veda una migliore ricezione ogni volta che esce.
Daniel Liuzzi,

0

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".


3
Questa è un'interpretazione errata. Fare riferimento alla seconda riga della tabella in RFC 6672 §2.2 . Un DNAME all'apice non comporterà alcuna corrispondenza per tipi di query diversi da DNAME all'apice, ovvero non si tradurrà in un aliasing effettivo di un record A o AAAA dell'apice.
Andrew B,

Un DNAME apice non comporterà il reindirizzamento per le query del nome apice. Tecnicamente non è corretto affermare che non si tradurrà in alcuna corrispondenza . Otterrai comunque una corrispondenza se esegui una query per NS, SOA o qualsiasi altro tipo di RR effettivamente presente per il nome dell'apice. Da RFC 6672 : "Se è presente un record DNAME all'apice della zona, è comunque necessario disporre anche dei record di risorse SOA e NS consueti. Tale DNAME non può essere utilizzato per il mirroring completo di una zona, poiché non rispecchia l'apice della zona ".
Quuxplusone,
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.