Questa è una domanda canonica sulla ridondanza geografica del DNS.

È risaputo che i server DNS con ridondanza geografica situati in posizioni fisiche separate sono estremamente desiderabili quando si forniscono servizi Web resilienti. Questo è trattato in modo approfondito dal documento BCP 16 , ma alcuni dei motivi più frequentemente citati includono:

• Protezione contro i disastri del datacenter. I terremoti accadono. Gli incendi si verificano negli scaffali e eliminano i server e le apparecchiature di rete nelle vicinanze. Più server DNS non ti faranno molto bene se i problemi fisici nel datacenter eliminano entrambi i server DNS contemporaneamente, anche se non si trovano nella stessa riga.

• Protezione contro i problemi dei colleghi a monte. Più server DNS non impediranno problemi se un peer di rete upstream condiviso fa un pisolino. Se il problema a monte ti porta completamente offline o isola semplicemente tutti i tuoi server DNS da una frazione della tua base di utenti, il risultato finale è che le persone non possono accedere al tuo dominio anche se i servizi stessi si trovano in un centro dati completamente diverso.

Va bene, ma i server DNS ridondanti sono davvero necessari se eseguo tutti i miei servizi dallo stesso indirizzo IP? Non riesco a vedere in che modo avere un secondo server DNS mi darebbe qualche vantaggio se nessuno potesse ottenere comunque qualcosa fornito dal mio dominio.

Capisco che questa è considerata una buona pratica, ma sembra davvero inutile!

Nota: contenuto in discussione, fare riferimento ai commenti per entrambe le risposte. Sono stati rilevati errori e queste domande e risposte necessitano di una revisione.

Sto rimuovendo l'accettazione da questa risposta per il momento fino a quando lo stato di queste domande e risposte canoniche viene affrontato correttamente. (l'eliminazione di questa risposta eliminerebbe anche i commenti allegati, il che non è il modo di passare all'IMO.

Potrei citare le RFC qui e usare termini tecnici, ma questo è un concetto che mi manca un sacco di persone su entrambi i lati dello spettro della conoscenza e cercherò di rispondere a questo per un pubblico più vasto.

Capisco che questa è considerata una buona pratica, ma sembra davvero inutile!

Può sembrare inutile ... ma in realtà non lo è!

I server ricorsivi sono molto bravi a ricordare quando i server remoti non rispondono a una query, in particolare quando ritentano e non vedono ancora una risposta. Molti implementano la memorizzazione nella cache negativa di questi errori di comunicazione e temporaneamente mettono i server dei nomi non rispondenti nella casella della penalità per un periodo di tempo non superiore a cinque minuti. Alla fine questo periodo di "penalità" scade e riprenderanno la comunicazione. Se la cattiva query fallisce di nuovo, tornano direttamente nella casella, altrimenti è di nuovo normale.

Qui è dove ci imbattiamo nel singolo problema del nameserver:

• Il periodo di penalità è per natura dell'implementazione sempre maggiore o uguale alla durata del problema di rete. In quasi tutti i casi sarà maggiore, fino ad un massimo di altri cinque minuti.
• Se il tuo singolo server DNS va nella casella di penalità, la query associata all'errore sarà completamente morta per l'intera durata.
• Brevi interruzioni del routing si verificano su Internet più di quanto si pensi. Le ritrasmissioni TCP / IP e simili protezioni per le applicazioni fanno un buon lavoro nel nasconderle all'utente, ma è alquanto inevitabile. Internet fa un buon lavoro nel routing di questo danno per la maggior parte a causa delle protezioni integrate nei vari standard che supportano lo stack di rete ... ma che include anche quelli integrati nel DNS, e avere server DNS con ridondanza geografica è un parte di quello.

Per farla breve, se si utilizza un singolo server DNS (questo include l'utilizzo dello stesso indirizzo IP più volte tra i NSrecord), ciò accadrà. Succederà anche molto più di quanto pensiate, ma il problema sarà così sporadico che le probabilità del fallimento 1) che vi vengono segnalate, 2) che vengono riprodotte e 3) che sono legate a questo specifico problema sono estremamente vicine a zero. Sono più o meno erano pari a zero, se siete venuti in questo Q & A non sapendo come questo processo ha funzionato, ma per fortuna questo non dovrebbe essere il caso ora!

Questo dovrebbe disturbarti? Non è davvero il mio posto da dire. Ad alcune persone non interesserà affatto questo problema di interruzione di cinque minuti, e non sono qui per convincerti di questo. Quello che sono qui per convincerti è che in effetti sacrifichi qualcosa eseguendo un solo server DNS e in tutti gli scenari.

OP chiede:

Va bene, ma i server DNS ridondanti sono davvero necessari se eseguo tutti i miei servizi dallo stesso indirizzo IP? Non riesco a vedere in che modo avere un secondo server DNS mi darebbe qualche vantaggio se nessuno potesse ottenere comunque qualcosa fornito dal mio dominio.

Ottima domanda!

La migliore risposta è fornita dal professor Daniel J. Bernstein, PhD Berkeley , che non è solo un ricercatore, scienziato e crittografo di fama mondiale, ma ha anche scritto una suite DNS molto popolare e ben nota nota come DJBDNS ( ultima versione 2001- 02-11 , ancora popolare fino ad oggi).

http://cr.yp.to/djbdns/third-party.html (2003-01-11)

Costi e vantaggi del servizio DNS di terze parti

Presta attenzione a questa parte breve e concisa:

Argomenti errati per il servizio DNS di terze parti

...

La seconda tattica è affermare che i client DNS diffusi faranno qualcosa di particolarmente malvagio quando non saranno in grado di raggiungere tutti i server DNS. Il problema con questo argomento è che l'affermazione è falsa. Qualsiasi client di questo tipo è chiaramente difettoso e non sarà in grado di sopravvivere sul mercato: considera cosa succede se i router del client si interrompono brevemente o se la rete del client viene temporaneamente allagata.

Pertanto, la risposta originale a questa domanda non potrebbe essere più sbagliata.

Sì, ogni tanto si verificano brevi interruzioni temporanee della rete della durata di pochi secondi. No, l'incapacità di risolvere un nome durante un'interruzione del genere non verrebbe memorizzata nella cache per un numero qualsiasi di minuti (altrimenti, anche avere la migliore configurazione di nameserver autorevoli ad alta disponibilità al mondo non aiuterà).

Qualsiasi software che implementa liberamente le linee guida conservative dei tempi fino a 5 minuti dall'RFC 1998-03 per la memorizzazione nella cache degli errori viene semplicemente interrotto in base alla progettazione e avere un server extra ridondante geograficamente non farà un male.

In effetti, secondo quanto tempo viene memorizzato nella cache un timeout DNS? , in BIND, la SERVFAILcondizione era tradizionalmente NON memorizzata nella cache prima del 2014 e dal 2015 è memorizzata nella cache per impostazione predefinita per solo 1 secondo , meno di quanto ci vorrebbe un utente medio per raggiungere un timeout del resolver e premere nuovamente il pulsante Aggiorna .

(E anche prima di arrivare al punto precedente se un tentativo di risoluzione debba o meno essere memorizzato nella cache, ci vogliono più di un paio di pacchetti rilasciati anche perché il primo SERVFAIL si verifichi in primo luogo.)

Inoltre, gli sviluppatori di BIND hanno persino implementato un limite per la funzione, di soli 30 anni, che, anche come un limite (ad esempio, il valore massimo che la funzione potrà mai accettare), è già 10 volte inferiore al suggerimento di 5 minuti (300 secondi) dalla RFC, assicurando che anche gli amministratori più intenzionati (degli utenti del bulbo oculare) non saranno in grado di sparare ai propri utenti nel piede.

Inoltre, ci sono molti motivi per cui potresti non voler eseguire un servizio DNS di terze parti : leggi tutto djbdns/third-party.htmlper tutti i dettagli e noleggiare un minuscolo server aggiuntivo solo per il DNS da amministrare da solo è difficilmente garantito quando non è necessario diverso da BCP 16 esiste per tale sforzo.

Nella mia personale esperienza "aneddotica" di possedere e impostare nomi di dominio almeno dal 2002, posso dirti con tutta certezza e onestà che in realtà ho avuto un significativo downtime dei miei vari domini a causa della gestione professionale server di terze parti dei miei registrar e provider di hosting , che, un provider alla volta e nel corso degli anni, avevano tutti i loro incidenti, non erano disponibili, abbattendo inutilmente i miei domini, nello stesso momento in cui il mio indirizzo IP (dove l'HTTP e l'SMTP per un determinato dominio sono stati ospitati da) altrimenti era completamente raggiungibile. Si noti che queste interruzioni si sono verificate con più fornitori indipendenti, rispettati e gestiti professionalmente e non sono affatto incidenti isolati e si verificano su base annuale e, come servizio di terze parti,sono completamente al di fuori del tuo controllo ; succede che poche persone ne parlano mai a lungo.

In breve:

Il DNS con ridondanza geografica NON è affatto necessario per i siti di piccole dimensioni.

Se stai eseguendo tutti i tuoi servizi dallo stesso indirizzo IP , l'aggiunta di un secondo DNS è molto probabile che comporti un ulteriore punto di errore e pregiudica la continua disponibilità del tuo dominio. La "saggezza" di sempre doverlo fare in ogni situazione immaginabile è un mito molto popolare, anzi; ARRESTATO.

Naturalmente, la consulenza sarebbe totalmente diversa qualora alcuni dei servizi del dominio, siano essi web (HTTP / HTTPS), posta (SMTP / IMAP) o voce / testo (SIP / XMPP), siano già gestiti da terze parti provider, nel qual caso eliminare il proprio IP come singolo punto di errore sarebbe davvero un approccio molto saggio e la ridondanza geografica sarebbe davvero molto utile.

Allo stesso modo, se hai un sito particolarmente popolare con milioni di visitatori e richiedi consapevolmente la flessibilità e le protezioni aggiuntive del DNS con ridondanza geografica come da BCP 16, allora ... Probabilmente non stai usando un singolo server / sito per web / mail / voce / testo già, quindi ovviamente questa domanda e risposta non si applicano. In bocca al lupo!