RFC 1034erfordert, dass wir mindestens zwei IP-Adressen für DNS-Server zuweisen. Redundanz kann jedoch bereits durch eine einzige IP-Adresse erreicht werden, wenn wir Anycast-Adressierung verwenden. BGP Anycast scheint sich problemlos auf Hunderte oder sogar Tausende von Servern skalieren zu lassen.
Wenn ja, warum benötigen wir dann noch mehrere IP-Adressen für DNS-Server? Verbessert es tatsächlich die Redundanz (trägt zur Verfügbarkeit bei), wenn wir bereits Anycast eingerichtet haben, oder ist das nur ein Mythos?
Mit welchen Problemen und Fehlern müssen wir rechnen?wenn wir nur eine einzige IP-Adresse verwenden?
Damit meine ich das völlige Weglassen sekundärer DNS-Adressen oder die Verwendung einer falschen IP (z. B. 1.2.3.4) für die zweite Adresse, wenn für manche Setups mindestens zwei erforderlich sind.
Antwort1
Eine einzelne Anycast-IP-Adresse bietet nicht die gleiche Redundanz wie zwei Unicast-IP-Adressen in unterschiedlichen IP-Präfixen.
Das größte Redundanzproblem liegt häufig nicht darin, dass etwas vollständig ausfällt, sondern darin, dass die Fehlfunktion gerade so groß ist, dass sie die Integritätsprüfungen zwar noch besteht, aber nicht mehr funktioniert.
Ich habe ein Anycast-DNS-Setup gesehen, bei dem ein DNS-Server ausgefallen ist, aber Pakete trotzdem an diesen DNS-Server weitergeleitet wurden. Wer auch immer für die Bekanntgabe des Präfixes zuständig war, wusste möglicherweise einfach nicht, dass der DNS-Server ausgefallen war.
Noch kniffliger wird es, wenn es sich bei dem betreffenden DNS-Server nicht um einen autoritativen DNS-Server, sondern um einen rekursiven Resolver handelt.
Ein solcher rekursiver Resolver müsste sowohl über die Anycast-Adresse zum Empfangen von Anfragen von Clients als auch über Unicast-Adressen zum Abfragen autoritativer DNS-Server verfügen. Wenn die Unicast-Adressen jedoch ausfallen, könnte es leicht so aussehen, als sei er in einem guten Zustand, dass er weiterhin Anfragen weiterleitet.
Anycast ist ein großartiges Tool für Skalierbarkeit und Latenzreduzierung. Aber für Redundanz sollte es nicht allein eingesetzt werden.
Mehrere redundante Anycast-Pools sind jedoch eine gute Lösung für die Verfügbarkeit. Ein bekanntes Beispiel sind 8.8.8.8 und 8.8.4.4. Beides sind Anycast-Adressen, aber sie sollten nie an denselben physischen DNS-Server weitergeleitet werden (vorausgesetzt, Google hat seine Arbeit gut gemacht).
Wenn Sie 10 physische DNS-Server haben, können Sie diese als 2 Pools mit jeweils 5 Servern oder 5 Pools mit jeweils 2 Servern konfigurieren. Sie möchten vermeiden, dass ein physischer DNS-Server gleichzeitig in mehreren Pools vorhanden ist.
Wie viele IPs sollten Sie also zuweisen? Sie benötigen IPs, die unabhängig voneinander als Anycast konfiguriert werden können. Das bedeutet normalerweise, dass Sie für jeden Pool einen gesamten /24-IPv4-Adressraum oder /48-IPv6-Adressraum zuweisen müssen. Dies kann die Anzahl der Pools, die Sie haben können, sehr wohl einschränken.
Wenn wir über autoritative Server sprechen, sollte die DNS-Antwort mit all Ihren NS-Einträgen und A- und AAAA-Glue in ein einzelnes 512-Byte-Paket passen. Für die Root-Server ergab das 13 Adressen. Aber Glue und IPv6 waren darin nicht enthalten, also wäre die Zahl, die Sie erreichen würden, niedriger.
Jeder Pool sollte so weit wie möglich geografisch verteilt sein. Wenn Sie 5 Server in Europa und 5 in Nordamerika und 2 Anycast-IPs haben, erstellen Sie nicht einen Pool, der alle Kontinente abdeckt. Sie legen 2 aus Europa in einen Pool mit 3 aus Nordamerika und die anderen 5 in den anderen Pool.
Wenn Sie über mehr als zwei Anycast-Pools verfügen, können Sie einen physischen Server vorübergehend in mehreren Pools zulassen. Sie sollten jedoch niemals zulassen, dass ein physischer Server gleichzeitig in allen Pools ist.
Die Kombination von Anycast und Unicast ist möglich, aber Sie müssen dabei vorsichtig sein. Wenn Sie IPs für zwei Pools haben, würde ich sie nicht kombinieren. Wenn Sie jedoch nur mit einer einzigen Anycast-IP arbeiten können, kann es sinnvoll sein, auch Unicast-IPs einzubeziehen. Das Problem besteht darin, dass die Einbeziehung von Unicast-IPs keine so gute Latenz und Lastverteilung bietet.
Wenn ein physischer Server sowohl per Unicast als auch per Anycast verfügbar gemacht wird, besteht das Risiko, dass Benutzer denselben Server als primären und sekundären Server erreichen und den Zugriff verlieren, wenn dieser ausfällt. Dies kann vermieden werden, indem nur Unicast-Adressen von Servern verwendet werden, die sich nicht im Anycast-Pool befinden, oder indem Benutzern immer zwei Unicast-Adressen bereitgestellt werden.
Je mehr Unicast-Adressen Sie in den Mix einbringen, desto weniger Abfragen werden an die Anycast-Adresse gesendet und desto weniger Nutzen ziehen Sie aus Anycast in Bezug auf Latenz und Skalierbarkeit.
Antwort2
Die beste Vorgehensweise besteht darin, mindestens zwei Adressen mit unterschiedlichen Präfixen zu verwenden und ihnen einen Namen unter zwei unterschiedlichen TLDs zu geben. Beide Adressen können auf Wunsch Anycast-Adressen sein. Wenn Sie nur eine IP-Adresse haben, entsteht ein einzelner Ausfallpunkt. Wenn das Routing zu dieser Adresse nicht funktioniert (Konfigurationsfehler, eine nicht ordnungsgemäß funktionierende Anycast-Instanz, das Präfix wurde gekapert usw.), ist Ihre gesamte Domain nicht erreichbar.
Jede Anycast-Adresse benötigt mindestens ein /24IPv4- oder /48IPv6-Präfix, um in BGP geroutet werden zu können. Kleinere (längere) Präfixe werden in der globalen Routing-Tabelle vielerorts normalerweise nicht akzeptiert.
NiemalsimmerGeben Sie als DNS-Server eine falsche IP-Adresse ein. Dies führt zu erheblichen Verzögerungen bei den Resolvern.
Antwort3
RFC 1034 besagt lediglich, dass Sie zwei DNS-Server benötigen. Dies ist keine zwingende Anforderung, sondern eine Empfehlung, also machen Sie damit, was Sie wollen. Unabhängig davon, wenn Sie HA möchten, können Ihren beiden DNS-Servern mithilfe von Anycast dieselbe IP zugewiesen werden, und das Einzige, was Ihre Endbenutzer bemerken würden, wenn ein DNS-Server ausfällt, ist ein vorübergehender Verbindungsverlust, während das Netzwerk wieder zusammengeführt wird.
Zusammenfassend lässt sich also sagen, dass die Verwendung von Anycast ausreicht, um RFC 1034-kompatibel zu sein.