Ich habe mich immer gefragt, wie die DNS-Infrastruktur für (sagen wir eine .com-)TLD aufgebaut ist. Sie muss nicht nur ein hohes Maß an Zuverlässigkeit aufrechterhalten können, sondern auch eine große Anzahl von Echtzeit-Updates der Datensätze unterstützen.
Ich würde davon ausgehen, dass BIND von ISC auf dieser Ebene verwendet wird. Ich habe eine ziemlich klare Vorstellung davon, wie jemand mit BIND eine skalierbare Infrastruktur aufbauen würde. Was mir allerdings nicht klar ist, ist, wie jemand ein System entwerfen würde, das alle paar Sekunden Hunderte von DNS-Zonen hinzufügen, löschen und ändern kann. Es gibt unzählige Domain-Registrare auf der Welt und allein .com verzeichnet wahrscheinlich eine enorme Aktivität. Wie lässt sich ein auf BIND-Zonendateien basierendes System auf so viele Änderungen skalieren?
Habe ich Recht, zu bezweifeln, dass ein TLD-Betreiber Textdateien verwendet und BIND jedes Mal, wenn eine neue .com-Domain registriert wird, die Änderungen neu lädt? Wenn ja, was tun sie? Wird es von einer SQL- oder LDAP-Datenbank unterstützt? Ist das überhaupt skalierbar?
Antwort1
Erstens: Glauben Sie wirklich, dass es mehr Updates gibt als, sagen wir, Kreditkartentransaktionen pro Sekunde auf der Welt, die letztlich nur von zwei oder drei Unternehmen verwaltet werden? Diese funktionieren, also ist es ein lösbares Problem :-)
Zweitens sind Sie möglicherweise verwirrt, wie Aktualisierungen erfolgen, da dies ein nicht oft verstandener Teil ist, bei dem sich zwei Ebenen überschneiden: die Registrierungsebene und die Veröffentlichungsebene. Sie sind möglicherweise auch verwirrt darüber, was genau auf den Nameservern der Registrierung geschieht (nur die NSAufzeichnungen für die Delegation von Domänen werden verwaltet, NICHT der gesamte Inhalt dieser Zonen).
Aber bevor Sie darauf eingehen, scheinen Sie auch davon auszugehen, dass Aktualisierungen in Echtzeit erfolgen sollten, obwohl dies nicht erforderlich ist und häufig auch nicht der Fall ist. Aufgrund der TTL erfolgt im DNS ohnehin nichts in Echtzeit.
Also zurück zu Ihren beiden Flugzeugen:
- Registrare senden Updates an die Register, wenn sich Nameserver ändern und andere Vorgänge, die DNS-Nebeneffekte haben (z. B. Einrichten des EPP-
clientHoldStatus); dies ist die Registrierungsebene, sie ist völlig UNKORRELIERT mit der DNS-Veröffentlichung und verwendet normalerweise ein Protokoll namens EPP; wenn das Register antwortet „Update akzeptiert“, bedeutet das absolut nicht, dass es bereits in seiner DNS-Infrastruktur veröffentlicht wurde, es ist nur eine Garantie „das wird irgendwann passieren“ - Register pflegen die DNS-Veröffentlichungsebene und stellen sicher, dass ihre Nameserver die richtigen
NSDatensätze für alle Delegationen veröffentlichen, d. h. für alle Domänen, die unter den von ihnen verwalteten TLDs registriert sind.
Daher ist die Anzahl der Änderungen wahrscheinlich weitaus geringer als Sie meinen: Wenn ein .comEigentümer den Inhalt seiner Zone mit neuen Datensätzen ändert, muss in den meisten Fällen nichts über den Registrar unternommen werden und an den autoritativen Nameservern der Registrierungsstelle ändert sich nichts.
Und diese Änderungen erfolgen NICHT über den DNS-Update-Mechanismus. Änderungen werden von Registraren mithilfe eines bestimmten Protokolls, EPP, übertragen. Änderungen werden irgendwie in einer Registrierungsdatenbank gespeichert, wonach die neuen Daten von der Registrierung auf ihren autoritativen Nameservern veröffentlicht werden.
Sie scheinen auch zu glauben, dass „Echtzeit“ zwingend erforderlich ist. Das ist es nicht, zumindest nicht technisch, und es kann sogar an einem ineffektiven Design liegen (denken Sie darüber nach, ob Sie Tests durchführen möchten, um zu prüfen, ob die neuen Änderungen sinnvoll sind, wie es einige Register tun, indem sie prüfen, ob die Nameserver für die Auflösung des Namens, für den sie bald als maßgebend aufgeführt werden, richtig konfiguriert sind, oder beispielsweise DNSSEC-Tests durchführen …).
Eine typische Einrichtungsmethode, die von vielen Registern verwendet wird und Dinge wie eine „10-minütige Verzögerung für Aktualisierungen“ oder „1 Stunde“ vorsieht, besteht darin, alle in diesem bestimmten Zeitraum angeforderten Änderungen in einem internen Puffer zu speichern, dann ein für alle Mal die neue Zone zu generieren und sie zu veröffentlichen, während ein neuer Puffer gestartet wird, um alle Änderungen zu sammeln, die im nächsten Zeitraum eingehen.
Ich würde davon ausgehen, dass auf dieser Ebene BIND von ISC verwendet wird.
Überhaupt nicht. Verisign betreibt seine eigene proprietäre Nameserver-Software namens Atlas. Siehe zum Beispielhttps://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html Beachten Sie, dass in diesem Artikel aus dem Jahr 2004 bereits Folgendes heißt:
VeriSign Naming and Directory Services (VNDS) verspricht, die 13 wichtigsten .com- und .net-Nameserver in weniger als fünf Minuten zu aktualisieren. Derzeit erfolgt die Aktualisierung etwa zweimal täglich.
Natürlich hat es sich seitdem verbessert. Aber ich glaube, dass sogar einmal alle 5 Minuten für jede wirklich praktische Nutzung des DNS weitgehend ausreicht.
Es könnten auch vertragliche Verpflichtungen bestehen, insbesondere für gTLD-Registrare und Registrare, die alle einen Vertrag mit ICANN haben. Der aktuelle Verisign-ICANN-Vertrag steht beihttps://www.icann.org/en/registry-agreements/details/com Sie finden im §6.6 des Anhangs unterhttps://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-enDetails zu den Updatebeschränkungen:
6.6 Aktualisierungshäufigkeit. Der Registry Operator aktualisiert die Daten auf den DNS-Nameservern und Whois zeitnah. ICANN-akkreditierte Registrare zeichnen diese Aktualisierungen über den SRS auf. Der SRS aktualisiert dann den DNS-Nameserver und den Whois. Der Registry Operator verarbeitet diese Aktualisierungen nahezu in Echtzeit.
Die vereinbarte Leistungsspezifikation in Bezug auf die Aktualisierungshäufigkeit für DNS-Nameserver und Whois beträgt 3 Minuten für 95 % der Transaktionen während eines monatlichen Zeitraums. Das bedeutet, dass 95 % der Aktualisierungen der DNS-Nameserver und des Whois während eines monatlichen Zeitraums innerhalb von 3 Minuten abgeschlossen sein werden. Die Aktualisierungshäufigkeit wird von dem Zeitpunkt an gemessen, an dem der Registry Operator die Aktualisierung bestätigt, bis zu dem Zeitpunkt, an dem die Aktualisierung im DNS-Nameserver und Whois erscheint. Die Leistung der Aktualisierungshäufigkeit wird ICANN gemäß Anhang 4 monatlich gemeldet.
Beachten Sie die übliche Markierung bei „95 %“, die für viele SLAs verwendet wird. Es ist also nahezu Echtzeit, wenn möglich, in der Praxis jedoch normalerweise 3 Minuten (daher die oben beschriebene typische Pufferkonfiguration).
Ich habe eine ziemlich klare Vorstellung davon, wie jemand mit BIND eine skalierbare Infrastruktur aufbauen würde. Was mir allerdings nicht klar ist, ist, wie jemand ein System entwerfen würde, das alle paar Sekunden Hunderte von DNS-Zonen hinzufügen, löschen und ändern kann.
Verisign hat nur ein paar Zonen: .com, .net, einige IDNs usw. Sie verwalten keine „Hunderte von Zonen“. Und schon gar nicht Hunderte davon mit vielen Änderungen pro Sekunde.
Sie könnten/möchten sich mehr für DNS-Anbieter interessieren, die Millionen von Zonen mit möglicherweise hoher Aktualisierungsfrequenz hosten. Hier ist ein Artikel von CloudFlare, in dem sie erklären, was sie in Bezug auf die Leistung ihres autoritativen DNS-Dienstes tun:https://blog.cloudflare.com/wie-wir-unseren-DNS-Stack-3x-schneller-gemacht-haben/
Es gibt unzählige Domain-Registrare auf der Welt
Nein, nicht alle. Weit davon entfernt, zahlreich zu sein. Tatsächlich weniger als 2000 und wahrscheinlich nur etwa 500 wirklich aktiv mit hohem Änderungsvolumen. Alle Registrare für gTLDs müssen von der ICANN akkreditiert sein. Die vollständige Liste finden Sie unterhttps://www.icann.org/en/accredited-registrars
Habe ich Recht, zu bezweifeln, dass ein TLD-Betreiber Textdateien verwendet und BIND bei jeder neuen .com-Registrierung die Änderungen neu laden lässt?
Keine vernünftige Nameserver-Software mit hohem Transaktionsniveau würde durch Textdateien unterstützt werden. Sogar Bind tut dies nicht: Wenn dynamische Updates aktiviert sind, haben Sie eine „Journal“-Datei (die binär ist) und Sie sollten die Textdateiversion der Zone ausdrücklich nicht bearbeiten (ohne zuerst Updates einzufrieren und sie nach der Bearbeitung wieder zuzulassen).
Wenn ja, was machen sie? Wird es durch eine SQL- oder LDAP-Datenbank unterstützt? Ist das überhaupt skalierbar?
Ich bezweifle, dass SQL oder LDAP gute Speichermodule für DNS sind. Denken Sie daran, dass DNS hierarchisch aufgebaut ist, was verschiedene Einschränkungen mit sich bringt.
Antwort2
Zunächst einmal müssen Sie in manchen Fällen nicht sofort nachladen.
Wenn Sie ein SLA haben, das besagt: „Bezahlen Sie uns und Ihre Domain wird innerhalb von X Stunden registriert“, können Sie sogar regelmäßig mit einem Cron-Job oder Ähnlichem neu laden. Manche Registrare verwenden möglicherweise Flatfiles und laden regelmäßig neu.
Bedenken Sie, dass Sie mehrere DNS-Server mit derselben IP-Adresse verknüpfen könnten (beispielsweise mithilfe von Anycast). Sie könnten also sogar einen Mechanismus zum „Rolling Deploy“ einrichten, der die Flatfile überall ändert und jeweils einen DNS-Server neu lädt.
Allerdings unterstützt Bind >9 DLZ (Dynamically Loadable Zones), was es Bind im Wesentlichen ermöglicht, eine Datenbank als Zonendaten-Backend zu verwenden. Datenbanken (und Datenbankverbindungen) können dann gemäß klassischen Datenbankskalierungsstrategien skaliert werden, solange Sie über einen gültigen DLZ-Treiber für Ihre Datenbank verfügen.
Und schließlich hilft, wie es in einem Kommentar hieß, die vertikale Skalierung (also die Bereitstellung großer CPU-, RAM- und IOPS-Kapazitäten für jeden Server).
Es gibt eine 2009SANOGFolie, die Sie vielleicht interessant finden, obwohl sie offensichtlich etwas veraltet ist:https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf