Modo corretto per impostare DNS primario / secondario / ... per ridondanza e riduzione della latenza?

Ho pensato che DNS primario / secondario ai fini della ridondanza fosse semplice. La mia comprensione è che dovresti avere un primario e almeno un secondario e che dovresti impostare il secondario in una posizione geograficamente diversa, ma anche dietro un router diverso (vedi ad esempio /server/48087 / why-are-there-many-nameservers-for-my-domain )

Attualmente, abbiamo due server dei nomi entrambi nel nostro data center principale. Recentemente, abbiamo subito alcune interruzioni per vari motivi che hanno eliminato entrambi i server dei nomi e lasciato noi e i nostri clienti senza lavorare DNS per alcune ore. Ho chiesto al mio team di amministratore di sistema di completare la configurazione di un server DNS in un altro centro dati e di configurarlo come server dei nomi secondario.

Tuttavia, i nostri amministratori di sistema affermano che ciò non aiuta molto se l'altro data center non è almeno affidabile come il data center primario. Sostengono che la maggior parte dei client non riuscirà comunque a cercare correttamente o a scadere troppo a lungo quando il data center primario è inattivo.

Personalmente, sono convinto che non siamo l'unica azienda con questo tipo di problema e che molto probabilmente è già un problema risolto. Non riesco a immaginare che tutte quelle compagnie Internet siano colpite dal nostro tipo di problema. Tuttavia, non riesco a trovare buoni documenti online che spieghino cosa succede nei casi di errore (ad esempio, i timeout dei client) e come aggirarli.

Quali argomenti posso usare per creare buchi nel ragionamento dei nostri amministratori di sistema? Qualche risorsa online che posso consultare per comprendere meglio i problemi che sostengono esistano?

Alcune note aggiuntive dopo aver letto le risposte:

• siamo su Linux
• abbiamo esigenze DNS complicate aggiuntive; le nostre voci DNS sono gestite da alcuni software personalizzati, con BIND attualmente schiavo di un'implementazione DNS intrecciata e anche alcune viste nel mix. Tuttavia, siamo completamente in grado di configurare i nostri server DNS in un altro data center.
• Sto parlando di DNS autorevole per gli estranei per trovare i nostri server, non di server DNS ricorsivi per i nostri clienti locali.

Esiste un documento "Best Practices" davvero eccezionale, anche se abbastanza tecnico, che può rivelarsi utile nella lotta contro il tuo amministratore di sistema. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Se lui / lei non riconosce la validità degli articoli scritti da Cisco, potresti anche smettere di litigare con l'amministratore di sistema - salire di un livello di gestione.

Molti altri documenti "Best Practices" raccomandano di separare i nameserver primari e secondari non solo per blocco IP, ma per posizione fisica. In effetti, RFC 2182 consiglia di separare geograficamente i servizi DNS secondari. Per molte aziende, ciò significa noleggiare un server in un altro datacenter o sottoscrivere un provider DNS ospitato come ZoneEdit o UltraDNS .

Tuttavia, i nostri amministratori di sistema affermano che ciò non aiuta molto se l'altro data center non è almeno affidabile come il data center primario. Sostengono che la maggior parte dei client non riuscirà comunque a cercare correttamente o a scadere troppo a lungo quando il data center primario è inattivo.

Ah, l'attenzione è affidabile . Sembra che stiano prendendo un jab sul tuo link verso l'esterno, piuttosto che impostare un DNS secondario. Tuttavia, imposta il DNS secondario e procedi da lì. Aiuterà con il carico e sosterrà le cose in un pizzico ... ma informati sul perché pensano che l'altra posizione non sia affidabile .

Personalmente, sono convinto che non siamo l'unica azienda con questo tipo di problema e che molto probabilmente è già un problema risolto. Non riesco a immaginare che tutte quelle compagnie Internet siano colpite dal nostro tipo di problema.

Non sei l'unica compagnia, e questo è stato probabilmente ripassato un milione di volte in aziende di tutto il mondo.

Tuttavia, non riesco a trovare buoni documenti online che spieghino cosa succede nei casi di errore (ad esempio, i timeout dei client) e come aggirarli.

Quali argomenti posso usare per creare buchi nel ragionamento dei nostri amministratori di sistema? Qualche risorsa online che posso consultare per comprendere meglio i problemi che sostengono esistano?

• Sto parlando di DNS autorevole per gli estranei per trovare i nostri server, non di server DNS ricorsivi per i nostri clienti locali.

Puoi fare qualsiasi cosa, inclusa la configurazione di un servizio DNS esterno registrato come autorità per la tua zona, ma rendendo segretamente i server (esterni) autorevoli secondari ai tuoi server DNS (interni). Questa configurazione è orribile, sbagliata, dimostra che sono davvero un cattivo Amministratore di sistema e un gattino muore ogni volta che lo consiglio. Ma fa due cose:

• Ottieni il tuo servizio DNS per gestire il peso del carico, ponendo domande sulla capacità del tuo DNS (interno) come moot.
• Ottieni il tuo servizio DNS per rimanere attivo mentre i tuoi server DNS interni potrebbero essere inattivi, quindi non importa quanto sia affidabile il tuo link - ciò che conta è quanto sia affidabile il tuo fornitore di servizi DNS .

Le ragioni per cui questa è la cosa sbagliata da fare:

• Dovresti impostare quello che viene chiamato "server dei nomi invisibile", perché mentre apparirà nei tuoi record di zona e puoi interrogare l'IP per il nome del server, non verrà mai toccato dall'esterno. Le richieste dei clienti non le raggiungeranno mai.
• Mentre il tuo DNS continuerebbe a funzionare correttamente (poiché il tuo servizio ospitato affronterebbe il problema), ciò non significa che tutti i siti web che hai funzionerebbero se la tua connessione a Internet fosse inattiva, vale a dire, risolve solo metà del problema . Sembra davvero che ci siano altri problemi di cui gli amministratori sono preoccupati.

Sfortunatamente il risolutore DNS di Linux non sembra avere un supporto diretto per il rilevamento e l'esecuzione di failover per i server DNS. Mantiene le richieste al server dei nomi principale in risoluzione, attende un timeout configurato, riprova, ecc.

Ciò comporta spesso ritardi fino a 30 secondi per qualsiasi richiesta. Senza prima provare il secondario fintanto che il primario è inattivo.

Volevo risolverlo poiché il nostro nameserver di risoluzione Amazon EC2 è irraggiungibile per molti dei nostri dipendenti. Ciò provoca grandi ritardi nei nostri processi e persino tempi di inattività in alcuni casi perché facciamo affidamento sulla risoluzione. Volevo un buon failover sui nameserver di Google / Level3 nel caso in cui Amazon fosse di nuovo in calo. E ricadere APPENA POSSIBILE, perché allora Amazon risolverà i nomi host in indirizzi locali ove applicabile, risolvendo a bassa latenza, ad esempio la comunicazione dell'istanza.

Ma qualunque sia il caso d'uso, è necessario un migliore failover. Volevo risolvere questo. Volevo stare lontano dai daemon, dai servizi proxy ecc., Poiché ciò avrebbe solo introdotto ulteriori Single Point Of Failures. Volevo usare una tecnologia il più arcaica e robusta possibile.

Ho deciso di usare crontab & bash e ho scritto nsfailover.sh . Spero che sia di aiuto.

Sembra che il problema sia che i client, che potrebbero essere chiunque, ovunque, vedano due server DNS e, se uno fallisce, o non eseguono il failover sul server secondario o c'è un timeout lungo prima di farlo.

Concordo sul fatto che i server DNS primari e secondari dovrebbero trovarsi in strutture diverse come best practice, ma non vedo come ciò risolva questo particolare problema.

Se il client insisterà nel richiedere un indirizzo IP specifico, ignorando l'indirizzo IP del secondario (o impiegando un po 'di tempo per il timeout), allora devi semplicemente trovare una soluzione che mantenga quell'indirizzo IP funzionante, anche se il il server primario non è attivo.

Alcune indicazioni da esplorare sarebbero un bilanciamento del carico in grado di reindirizzare il traffico per un singolo indirizzo IP a più server in data center diversi; o forse qualsiasi routing routing.

Finché ciascuno dei tuoi datacenter è su circuiti diversi (idealmente con diversi provider upstream fino al cloud), puoi configurare DNS abbastanza affidabili con solo i due datacenter. Devi semplicemente assicurarti che il tuo registrar di scelta popolare i record di colla appropriati ai grandi server nel cielo.

La nostra configurazione è:

• 2 datacenter fisici (circuiti separati, ISP e provider upstream)
• 2 server di query fisici in un cluster dietro uno SLB in ciascuna struttura
• 2 dispositivi di bilanciamento del carico per servire record specifici di cui vogliamo gestire il bilanciamento tra i due datacetner
• master nascosto accessibile internamente da entrambi i cluster di server (credo fortemente nelle configurazioni master nascoste per motivi di sicurezza)

Questa configurazione è stata abbastanza efficace da darci circa 5 9 di uptime negli ultimi 6 o 7 anni, anche con i tempi di inattività del server occasionali per gli aggiornamenti, ecc. Se sei disposto a spendere qualche dollaro in più, puoi guardare in outsourcing hosting della zona con qualcuno come ultradns ...

Quanto alla conversazione di caricamento menzionata da KPWINC, è corretta al 100%. Se il tuo datacenter più piccolo non è in grado di gestire il 100% del tuo carico, probabilmente verrai disossato comunque perché l'interruzione si verificherà quando meno lo desideri =)

Prendo il massimo carico da tutti i miei router perimetrali, li aggiungo tutti insieme e quindi divido per 0,65 ... questa è la larghezza di banda minima che dobbiamo avere in ogni datacenter. Ho messo in atto questa regola circa 5 anni fa, con alcuni documenti per giustificarla che ho raccolto dal CCO e su Internet, e non ci ha mai deluso. Tuttavia, è necessario controllare tali statistiche almeno trimestralmente. Abbiamo registrato un aumento del traffico di quasi 3 volte tra novembre e febbraio dell'anno scorso e non ero preparato per questo. Quel lato positivo è che la situazione mi ha permesso di generare alcuni dati concreti molto chiari che dicono che al 72% del carico sul nostro circuito WAN, iniziamo a far cadere i pacchetti. Non sono mai state richieste ulteriori giustificazioni per una maggiore larghezza di banda.

Dalla lettura della tua descrizione mi sono reso conto che non è chiaro se intendi DNS autorevole per gli estranei per trovare i tuoi server o server DNS ricorsivi per i tuoi clienti locali. Il comportamento di quei due è molto diverso.

Per i server DNS autorevoli, i "client" saranno altri server DNS che dispongono di cache e molta intelligenza. Tenderanno a provare più server contemporaneamente se il primo è affatto lento e tenderanno a preferire quello che fornisce loro risposte più veloci. In tal caso, i tempi di inattività di un data center avrebbero un impatto molto limitato sulle prestazioni.

Per i server DNS ricorsivi, i client sono i client locali che probabilmente hanno i server DNS elencati in DHCP. Proveranno sempre i loro server nell'ordine elencato, con un timeout dolorosamente lungo (diversi secondi) prima di passare dal primo server al secondo server.

Se il tuo datacenter principale è inattivo, nessuno sarà in grado di raggiungere comunque quei server, ma spesso gli errori che ne derivano sono più comprensibili degli errori dei server DNS non raggiungibili. "impossibile contattare il server" o "timeout della connessione" anziché "impossibile trovare il server" o "nessun server di questo tipo". Ad esempio, la maggior parte dei server SMTP metterà in coda la posta per una settimana se vede il server in DNS ma non riesce a raggiungerlo; se non riescono a trovarlo nel DNS, possono immediatamente rifiutare di provare a consegnarlo al tuo dominio.

Il DNS secondario essendo geograficamente e separato dalla rete è una buona cosa. Potresti essere in grado di scambiare DNS secondario con un'azienda amichevole e ci sono molti fornitori DNS che puoi pagare per farlo per te. Alcuni registrar hanno anche DNS secondario come servizio.

Tommaso,

Dopo aver letto il mio aggiornamento ho rivisto il mio post (il post precedente ha fatto riferimento al software Windows).

Mi sembra quasi che i tuoi amministratori di sistema ti stiano dicendo che la tua posizione secondaria non ha l'hardware necessario per gestire il CARICO COMPLETO?

Sembra che stia dicendo: "Ehi amico, se la nostra posizione principale (che include il DNS primario) scende, allora il DNS è l'ULTIMO delle nostre preoccupazioni perché se COLO1 è inattivo, COLO2 non può comunque gestire il carico".

In tal caso, ti suggerirei di esaminare la tua infrastruttura e provare a trovare un design migliore. Questo è più facile a dirsi che a farsi, soprattutto ora che si vive in un ambiente di produzione.

A parte questo, in un mondo perfetto, COLO1 e COLO2 sarebbero in grado di stare da soli e gestire il carico.

Una volta che era a posto ... il DNS non è altro che avere abbastanza server DNS con un aggiornamento abbastanza veloce e se una parte fallisce puoi riscrivere il tuo DNS per puntare ai server che sono SU.

Ho usato questo metodo in ambienti di dimensioni da piccole a ragionevoli e funziona benissimo. Il failover richiede in genere meno di 10 minuti.

Devi solo assicurarti che i tuoi server DNS possano gestire il carico aggiuntivo di un breve TTL (tempo di vita).

Spero che sia di aiuto.

I tuoi amministratori di sistema hanno (principalmente) torto.

I server ricorsivi che interrogano i tuoi server autorevoli noteranno molto rapidamente se uno dei due siti non risponde.

Sì, c'è qualche possibilità che i client possano riscontrare ritardi di risoluzione DNS molto modesti quando si verifica un'interruzione, ma saranno solo un secondo o due e una volta che i server DNS del client hanno appreso che uno dei server è inattivo, useranno i server rimanenti preferiscono quello fallito.

Se necessario (per placare gli amministratori di sistema), continuare a eseguire due server nel data center principale, ma almeno uno in più all'esterno.

Un server DNS secondario non fa mai male, a seconda di dove è ospitato ti darà più o meno funzionalità.

Se il tuo host primario fallisce, un secondario può subentrare, indipendentemente dal fatto che si trovi accanto ad esso o in una posizione remota. Se tuttavia il tuo uplink del datacenter fallisce, potresti comunque ricevere risposte DNS dal server in un altro datacenter ma non sarai comunque in grado di raggiungere i tuoi server. Pertanto, gli utenti finali non beneficeranno direttamente del DNS secondario nella posizione remota.

Diversi client reagiscono in altri modi alla mancata disponibilità dei server DNS, quindi c'è un po 'di verità sul timeout dei client, ma non tutti.

Un DNS secondario in un datacenter remoto sarà comunque in grado di risolvere l'indirizzo IP del server che si desidera raggiungere in modo da poter eseguire il debug del routing e vedere quando si presentano di nuovo. E se hai configurato correttamente i server MX secondari non perderai nemmeno la posta.