Bei der Anpassung des DNS-Records wird auf den Umstand
zurückgegriffen, dass in den meisten Fällen mittels der Hostnamen und
nicht mittels der IP adressiert wird. Dabei wird dem Hostnamen des
ausgefallenen Rechners die IP des Servers zugeordnet, der den Dienst
übernimmt.
Dabei ist zu beachten, dass die weltweite Verteilung und das Caching
von DNS-Einträgen auf anderen Servern und in lokalen DNS-Caches zu
großen Verzögerungen bis zur vollständigen Bekanntmachung der
Umstellung führen kann - Zeiten im Bereich mehrerer Stunden sind
üblich. Während dieser Zeit werden Anfragen immer noch
an die IP des ausgefallenen Rechners vermittelt und die Dienste
scheinen für den Nutzer nicht erreichbar. Im schlimmsten Falle ist sogar
vorzustellen, dass einzelne Nutzer die Bekanntmachung erst erfahren,
nachdem der ausgefallene Rechner bereits wieder instand gesetzt wurde.
Es wäre auch denkbar, dass in der Folge der Server, der den Dienst
übernommen hatte, noch Stunden nach der Reparatur des urspünglichen
Zielrechners mit Anfragen beschäftigt wird, die für den anderen
Rechner gedacht sind - und das zusätzlich zu den ihm übertragenen
Aufgaben.
Neben dieser recht einfach zu implementierenden, aber mit oben
genannten unschönen Nebeneffekten behafteten Methode wäre ein Szenario
vorstellbar, in dem ein den Server vorgeschaltener virtueller Server
die Verteilung auf die diensterbringenden Rechner koordiniert. Dabei
sind die unterschiedlichen Möglichkeiten denkbar, die beispielsweise
das Linux Virtual Server Project oder die verschiedensten
Hardware-Router (beispielsweise von Cisco) bereitstellen.
So könnte der virtuelle Server die Erreichbarkeit der Dienste auf den
eigentlichen Servern testen und demnach die Verteilung vornehmen. Da
hierbei jeglicher Verkehr über die IP des virtuellen Servers
abgewickelt wird, wäre der Ausfall für die Nutzer transparent. Auch
ließe sich dabei der Einsatz von lastbasierten Verteilungsmechanismen
vorstellen.
Da aber der virtuelle Server hierbei einen Single Point of Failure
darstellt, sollte die Implementierung im Produktivbetrieb robust sein
- eventuell robuster, als ein Linux Virtual Server ist - und die
Möglichkeit dieser Ausfallstelle bedacht werden.
Die dritte Möglichkeit, die eine Umleitung der Anfragen, die
eigentlich
an einen ausgefallenen Server gerichtet sind, ermöglicht, ist die
Übernahme der IP durch den Ersatz-Rechner. Dabei erhält der
vorübergehende Dienstleister die IP, an die ursprünglich der Traffic
gerichtet ist.
Diese Umschaltung kann aktiv geschehen, indem der Ersatz-Rechner die
IP zusätzlich zu seiner oder seinen bisherigen auf ein Interface
schaltet oder auch indem er mittels arp-spoofing nur die ARP-Anfragen
an die IP beantwortet, dann allerdings auf IP-Ebene mit seiner eigenen
arbeitet. Da die einzelnen Schichten allerdings verschiedene
Sicherungsmaßnahmen zur Entlastung des eigenen Rechners und vor
Angriffen oder Fehlkonfigurationen anderer Rechner enthalten, würden
Pakete mit fehlerhafter Adressierung verworfen. Somit müsste man diese
Sicherungsmaßnahmen ausschalten und umgehen, sowie in der Folge für
deren Funktionalität eigene Vorkehrungen treffen, weshalb ein
zusätzliches Beschalten eines Interfaces mit der zu übernehmenden IP
einfacher, sicherer und stabiler ist.