|
Schäden durch DNS-Serverausfälle lassen sich durch redundante
Systeme weitgehend vermeiden. Clienten sind so zu konfigurieren,
dass sie mehrere Server kennen. Fällt ein solcher Server aus (der
ja ein caching-only Nameserver sein kann, also einer, der für
keine Zone authoritative ist), wechselt der Resolver einfach auf
einen anderen, bis auf etwas Zeitverlust kein weiterer Nachteil.
Die Reihenfolge der Server ist von Client zu Client zu mischen,
um Lastverteilung zu erreichen.
Es sind ausreichend viele Secondaries bereitzustellen, ansonsten
wird der Betrieb u.U. durch Überlast gestört. Verwenden lokale
Clienten andere DNS-Server, so wird das u.U. spät bemerkt. Fällt
ein Secondary aus, stellt das kurzfristig kein allzu großes
Problem dar, solange noch mindestens ein Secondary verfügbar ist.
Dabei muß vermieden werden, dass in diesem Falle der oder die
verbleibenden Secondaries überlastet werden.
Fällt ein Primary aus, und ist dieser nur Primary, aber keiner
mit einem NS-RR aufgeführter (auch
hidden primary; genannt), so verläuft der Ausfall
vollkommen transparent, bis die Secondaries die Zone expiren
(also wegwerfen), was so um die zwei bis sechs Wochen dauern
sollte (je nach Konfiguration der SOA-Records der Zone).
Nach dieser Zeit ist die Zone jedoch vollkommen unbekannt! In
der Praxis ist das jedoch mehr als genug Zeit, um einen neuen
Server aufzusetzen, ein Backup einzuspielen, und so notfalls
einfach den kompletten Server zu wechseln.
Da DNS auf verteilten Datenbanken beruht, muß bei einer Kontrolle
bzw. beim Debugging beachtet werden, welcher Server (welcher
Secondary, welcher Forwarder etc.) welche Antwort gibt. So kann
es z.B. sein, dass ein Secondary fehlerhaft arbeitet. Ein Test
kann aber die richtige Antwort liefern, falls dieser zufällig
nicht gefragt wird. Diese Antwort wird dann evtl. noch von einem
Forwarder gecached. Deshalb sollte man bei Tests die Secondaries
einen nach dem anderen direkt fragen. Widersprechen sich z.B.
zwei Secondaries, können die Fehler diffus und versteckt
auftreten.
Haben sich die Zonendateien in letzter Zeit geändert, ist es auch
möglich, dass ein Secondary den Transfer noch nicht durchführen
konnte. Deshalb muß als erstes geprüft werden, ob die SOA-Serial
überhaupt die aktuelle ist. Eventuell gibt es Probleme mit der
Notification (wenn alles funktioniert, sollten die aktualisierten
Zonen in wenigen Minuten den Secondaries bekannt sein).
Es gibt auch Fehler, die eigentlich in anderen Zonen liegen, als
in der sie bemerkt werden. So ist es zum Beispiel denkbar, dass
ein NS-Record fehlerhaft scheint, in Wirklichkeit aber der
dazugehörige A-Record aus der Zone, zu der der DNS-Server gehört,
fehlerhaft ist oder nicht existiert. Diese Zone wird dann
eventuell auch noch von anderen verwaltet...
|
SelfLinux 
