Avere più CNAME

11

Abbiamo il nostro dominio DNS con CNAME a 5 livelli per motivi storici. Alcune delle cose sono state esternalizzate per l'alta disponibilità ecc. Ma non è questo il punto. La mia domanda è avere 5 CNAME in eccesso per il resolver DNS? Non sono stato in grado di scoprire alcun sito Web famoso con più di 2-3 livelli CNAME nidificati che punta a domini DNS diversi.

I nostri hop CNAME sono i seguenti: (Sto usando xyz solo come esempio)

www.xyz.com -> xyz.akadns.net -> xyz.worldwide.akadns.net -> xyz.cedexis.net -> xyz.msedge.net -> host1.msedge.net (record finale A \ AAAA)

Sto vedendo molti clienti lamentarsi dei problemi di risoluzione DNS sul nostro sito Web quando altri siti funzionano bene per loro, anche se quando uso http://check-host.net/check-dns?host=www.xyz.com per testare il nostro DNS risoluzione.

Sembra funzionare sempre bene in tutto il mondo. La mia conclusione è che principalmente è che il risolutore DNS del provider ISP locale si rovina quando uno dei Luppoli sopra non riesce a risolversi. nslookup fallisce su questi computer client solo per il nostro sito Web e che troppo sporadicamente.

Questo tipo di CNAME multilivello è un cattivo design in generale?

domain-name-system cname-record

— Vishal Naidu
fonte

1

Ho lavorato per Akamai alcuni anni fa e uno dei nostri clienti ha riferito che un certo router aveva un problema con 5 livelli di annidamento. Penso che il firmware del router sia stato eventualmente risolto.

— Barmar,

15

Questo tipo di CNAME multilivello è un cattivo design in generale?

Le catene da CNAME a CNAME non sono vietate ma, come già sperimentato, non è una soluzione molto solida.

Ogni CNAME aggiuntivo aumenta la profondità di ricorsione per il resolver e tale profondità non è sempre illimitata. Inoltre si corre il rischio di creare loop o attivare l'algoritmo di rilevamento loop.

Per avere un'idea di quante e quali query devono essere eseguite dal server dei nomi dei tuoi utenti, esegui una traccia DNS:

dig +trace www.example.com

o su Windows

nslookup -debug www.example.com

— HBruijn
fonte

11

HBrujin ha ragione, ma in verità la profondità della ricorsione è molto peggio di qualsiasi cosa dig +traceti mostrerà. La profondità della ricorsione è qualcosa che spesso viene sogghignata e troppo banalizzata, ma quelle persone dimenticano che non stai risolvendo solo ~ 5 CNAMErecord. Questo perché la risoluzione dell'obiettivo di un CNAMErecord crea la necessità di cercare tutti i nameserver nel percorso, che è spesso molto più di quanto non appaiano a prima vista.

Il CNAMEbersaglio vive in un altro dominio? Dovrai ricorrere ai suoi nameserver, che richiedono non solo NSricerche record ma anche A(AAA)ricerche in cui la colla non è presente. I server dei nomi per quei server dei nomi vivono in un dominio di primo livello diverso? Se quei TLD non condividono i server dei nomi, è probabile che i record di colla non vengano inclusi e che si debba ricorrere anche agli altri server dei nomi dei TLD. E così via.

Ogni CNAMErecord aggiunto alla catena può aumentare in modo esponenziale il numero di ricerche richieste in base al numero di nameserver che devono essere ripetuti. Queste catene di ricerche di record CNAME+ NS+ A(AAA)possono a loro volta essere follemente contorte, raggiungendo ben oltre 150 livelli in una cache vuota. È qui che i limiti di profondità di ricorsione possono diventare estremamente sgradevoli, con conseguenti errori temporanei nella ricerca del dominio in una cache vuota e per motivi che spesso non sono immediatamente evidenti.

In breve, puoi farlo, ma procedi con cautela e prendi sul serio il feedback di questa natura. Non hai alcun controllo sulla frequenza con cui i server DNS ricorsivi su Internet vengono riavviati o eliminati.

— Andrew B
fonte

Il mio software client si trova su un gruppo di macchine che effettuano chiamate http remote. Sarà quindi corretto riprovare tutti i CNAME dal client riducendo la profondità di ricorsione \ load sul resolver? Sembra un buon approccio o mi sto perdendo qualcosa? So che i CNAME non cambieranno tra aree geografiche.

— Vishal Naidu,

Non è un buon approccio. In genere il server che non è riuscito a cercare i dati memorizza temporaneamente nella cache l'errore. La query potrebbe riuscire nuovamente in futuro (diciamo, tra 5 minuti da ora), ma è improbabile che riesca con un nuovo tentativo immediato. Se fornisci il nome del tuo record DNS, posso farti sapere se questo è davvero un problema di profondità di ricorsione o qualcosa di meno ovvio. Odio per noi andare nella tana del coniglio sbagliata.

— Andrew B,

0

I livelli multipli CNAMEsono spesso utili nella pratica. Ogni livello di reindirizzamento fornisce un livello di controllo in una zona amministrativa potenzialmente distinta o in un'organizzazione completamente diversa. Sebbene ciò non sia tecnicamente necessario, può aggirare i problemi organizzativi .

Come altri hanno notato questo può causare difficoltà, ma questi possono essere risolti:

monitorare tutti i server DNS. Forse uno non funziona correttamente. Monitorare server esterni e propri. Potrebbe essere necessario segnalare un problema ad Akamai o ad altri fornitori.
TTLs dovrebbe essere impostato abbastanza alto da consentire la memorizzazione nella cache ma abbastanza basso da poter spostare il traffico abbastanza velocemente per la tua applicazione

— pulcini
fonte

2

Non sono sicuro di aver compreso la raccomandazione di monitoraggio. Non solo i limiti di profondità di ricorsione variano da prodotto a prodotto, come proponete di monitorarli? Non è possibile identificare facilmente la causa principale dell'infrazione ricorsiva di qualcun altro.

— Andrew B,