Evitare i timeout DNS in caso di errore di un server DNS

Abbiamo un piccolo datacenter con circa un centinaio di host che punta a 3 server DNS interni (bind 9). Il nostro problema si presenta quando uno dei server DNS interni non è disponibile. A quel punto tutti i client che puntano a quel server iniziano a funzionare molto lentamente.

Il problema sembra essere che il risolutore linux di serie non abbia davvero il concetto di "failover" su un server DNS diverso. È possibile regolare il timeout e il numero di tentativi che utilizza (e impostare la rotazione in modo che funzioni attraverso l'elenco), ma indipendentemente dalle impostazioni utilizzate dai nostri servizi, le prestazioni vengono eseguite molto più lentamente se un server DNS primario non è disponibile. Al momento questa è una delle maggiori fonti di interruzione del servizio per noi.

La mia risposta ideale sarebbe qualcosa come "RTFM: tweak /etc/resolv.conf come questo ...", ma se questa è un'opzione non l'ho vista.

Mi chiedevo come altre persone hanno gestito questo problema?

Vedo 3 possibili tipi di soluzioni:

• Usa linux-ha / Pacemaker e ips di failover (quindi i VIP IP DNS sono "sempre" disponibili). Purtroppo, non disponiamo di una buona infrastruttura di scherma e senza pacemaker di scherma non funziona molto bene (nella mia esperienza Pacemaker riduce la disponibilità senza scherma).

• Esegui un server DNS locale su ciascun nodo e fai in modo che resolv.conf faccia riferimento a localhost. Funzionerebbe, ma ci darebbe molti più servizi da monitorare e gestire.

• Esegui una cache locale su ciascun nodo. La gente sembra considerare nscd "rotto", ma dnrd sembra avere il giusto set di funzionalità: contrassegna i server DNS come su o giù e non utilizzerà i server DNS "giù".

Any-casting sembra funzionare solo a livello di routing ip e dipende dagli aggiornamenti di route per guasti del server. Il multi-casting sembrava essere una risposta perfetta, ma il bind non supporta la trasmissione o il multi-casting e i documenti che ho trovato sembrano suggerire che il DNS multicast è più mirato alla scoperta del servizio e alla configurazione automatica piuttosto che alla normale risoluzione del DNS .

Mi sto perdendo una soluzione ovvia?

Un paio di opzioni. Entrambi distribuiranno il carico DNS tra i server DNS.

• Prova a utilizzare options rotatein resolv.conf. Ciò ridurrà al minimo l'impatto del server primario inattivo. Se uno degli altri server è inattivo, rallenterà le azioni.
• Utilizzare un ordine di nameserver diverso su client diversi. Ciò consentirà ad alcuni client di funzionare normalmente se il server DNS primario è inattivo. Questo diffonde l'impatto di un server DNS fuori servizio.

Queste opzioni possono essere combinate con options timeout:1 attempts:5. Aumentare i tentativi se si riduce il timeout in modo da poter gestire server esterni lenti.

A seconda della configurazione del router, potresti essere in grado di configurare i tuoi server DNS per assumere l'indirizzo IP del server DNS primario quando è inattivo. Questo può essere combinato con le tecniche di cui sopra.

NOTA: corro anni senza interruzioni DNS non pianificate. Come altri hanno notato, lavorerei per risolvere i problemi che causano il fallimento dei server DNS. I passaggi precedenti aiutano anche con server DNS non configurati con la specifica di server dei nomi non raggiungibili.

Dai un'occhiata a "man resolv.conf". È possibile aggiungere un'opzione di timeout a resolv.conf. Il valore predefinito è 5, ma l'aggiunta di quanto segue a resolv.conf dovrebbe ridurlo a 1 secondo:

timeout delle opzioni: 1

Software di clustering come battito cardiaco o pacemaker / corosync è il tuo amico qui. Come esempio, abbiamo impostato pacemaker / corosync come segue:

• Associare ogni server con un altro
• Per coppia hanno 2 dns vip, di solito uno su ciascuno
• Se il bind o il server falliscono, il vip si sposta sull'altro server entro millisecondi

Le ore di produzione sono di 24 ore su 24, 7 giorni su 7, ma crediamo fermamente che dovrebbe essere possibile che tutti i server falliscano senza influire sui clienti. l'opzione di rotazione è semplicemente una soluzione alternativa, non lo farei.

Esegui un server DNS locale su ciascun nodo e fai in modo che resolv.conf faccia riferimento a localhost. Funzionerebbe, ma ci darebbe molti più servizi da monitorare e gestire.

FWIW, questa è l'unica soluzione praticabile che ho trovato per questo problema. È necessario limitare il server all'ascolto solo su localhost, ma ha eliminato completamente gli utenti che hanno notato interruzioni del DNS nel nostro ambiente.

Un interessante effetto collaterale è che se il server localhost si arresta per qualche motivo, le librerie del resolver standard sembrano gestire il failover sul server successivo molto più velocemente rispetto al caso standard.

Lo facciamo da circa 3 anni e non ho riscontrato un singolo problema che può essere correlato al fallimento / interruzione di un server DNS in esecuzione su localhost.

Se un server dei nomi non funziona per manutenzione, è normale ridurre i timeout nel SOA per quel dominio in anticipo, in modo che quando si verifica la manutenzione, cambia (come rimuovere i record NS prima della manutenzione e rimetterli dopo la manutenzione ) propagarsi rapidamente. Si noti che si tratta di un approccio lato server: la modifica dei resolver è un approccio lato client e ... a meno che non si possa parlare con ognuno dei propri clienti e convincerli a fare questo aggiustamento sulla propria macchina ... potrebbe non essere l'approccio giusto. Bene, suppongo che tu abbia detto solo un centinaio di client in un data center utilizzando server DNS interni, ma vuoi davvero cambiare la configurazione su un centinaio di client quando puoi semplicemente cambiare la zona?

Ti direi quali valori nella SOA regolare, ma stavo navigando sul web per scoprire le informazioni esatte quando ho incontrato questa domanda.

Forse puoi mettere i tuoi server DNS dietro un bilanciamento del carico? Apparentemente LVS può bilanciare UDP. Ovviamente rendi la tua LB altamente disponibile, quindi non è un singolo punto di errore.

So che potrebbe sembrare banale, ma che ne dite di costruire un'infrastruttura DNS più stabile e flessibile come soluzione permanente al problema.

Una soluzione più incentrata sulla rete sarebbe utilizzare due server DNS con lo stesso instradamento IP (dedicato) e Anycast . (Non ho notato questa risposta in questo thread finora, ma è quello che viene utilizzato qui.)

Finché entrambi sono attivi, viene utilizzato il server più vicino. Se uno scende, il traffico per quell'IP verrà instradato all'altro nodo fino a quando non si ripresenta. Ciò è particolarmente utile se si dispone di due o più posizioni o data center.