![Sekundäres DNS erklärt](https://assets.gcore.pro/blog_containerizing_prod/uploads/2023/07/secondary-dns-explained-fi.png)
Ihre Domains sind der Einstiegspunkt zu Ihren Online-Diensten, daher sind ihre Zuverlässigkeit und Leistung entscheidend für den Erfolg. Mit sekundärem DNS können Sie Ihre Nameserver redundant gestalten und gleichzeitig die Latenzzeit bei der Domainauflösung minimieren. Ganz gleich, ob Sie als Produktmanager die ersten Stufen eines Verkaufstrichters verfeinern wollen oder als Ingenieur ein Service-Level-Ziel erreichen müssen, sekundäre DNS kann Ihnen helfen, Ihre Geschäftsziele zu erreichen. In diesem Artikel wird erklärt, was sekundäres DNS ist, wie es sich in das DNS-Design einfügt und welche Vorteile Sie haben, wenn Sie es zu Ihrer Architektur hinzufügen.
Was ist sekundäres DNS?
Ein sekundärer DNS-Server ist ein Typ von DNS-Server, der automatisch Kopien aller DNS-Einträge eines primären DNS-Servers speichert. Wenn Ihr primärer Server nicht erreichbar oder ausgelastet ist, springt der sekundäre DNS-Server ein und bearbeitet die Anfragen. Dies sorgt für zusätzliche Redundanz und gewährleistet die ständige Verfügbarkeit Ihrer DNS-Dienste und schützt Sie vor möglichen Unterbrechungen der Netzwerkdienste.
Wie funktioniert DNS?
Um das sekundäre DNS besser zu verstehen, machen wir einen kurzen Ausflug in die Grundlagen des DNS. Dieser Teil ist notwendig, um zu verstehen, wie sekundäre Nameserver in das Gesamtbild passen.
DNS ist die Abkürzung für Domain Name Service. DNS ist ein verteiltes System, das Domainnamen in IP-Adressen, andere Domainnamen oder beliebige Texte auflöst. Es fügt eine indirekte Ebene zwischen den tatsächlichen Adressen der einzelnen Server im Internet und den Clients, die auf sie zugreifen wollen, hinzu. Es ist ein wesentlicher Teil des Internets. Ohne DNS müssten Sie sich lange Nummern wie 192.168.43.10 oder 2001:db8::ff00:42:8329 merken und sie bei jeder Änderung aktualisieren.
Wie funktioniert die Namensauflösung?
Die Namensauflösung erfolgt über einfache Nachschlagetabellen, die Zonendateien heißen und mit RRs gefüllt sind. Jede dieser RRs enthält folgende Felder:
- Das Feld Name enthält einen voll qualifizierten Domainnamen, der den Schlüssel der Zonendateien bildet.
- Das Feld Typ enthält den Eintragstyp. Wichtige Typen sind:
- SOA für Verwaltungsdaten, z.B. die Version der Zonendatei
- A und AAAA für IP-Adressen
- CNAME für das Aliasing anderer Domainnamen
- MX für Mailserveradressen oder Domainnamen
- TXT für beliebigen Text
- NS für Adressen oder Domainnamen von autoritativen Nameservern; dies ist auch der Eintrag, den Sie für sekundäre Nameserver überprüfen können
- Das Feld Daten enthält Daten wie eine IP-Adresse, eine andere Domain oder Text. Es bildet den Wert der Zonendateien.
- Die Time to live (TTL) enthält die Zeit, die ein Client die aufgelösten Daten lokal zwischenspeichern kann.
- Das Feld Klasse enthält eine Protokollklasse. Im Internet ist der Wert immer IN.
Sehen Sie sich die folgende Zonendatei für eine fiktive example.com-Zone mit mehreren NS-Einträgen an. Erläuterungen finden Sie auf der linken Seite, die Einträge auf der rechten Seite und darunter.
![Ein Beispiel für eine DNS-Zonendatei mit Erläuterungen zu wichtigen DNS-Einträgen](https://assets.gcore.pro/blog_containerizing/uploads/2023/07/secondary-dns-explained-1-1024x805.png)
$TTL 86400 example.com. IN SOA ns1.example.com. hostmaster.example.com. ( 2023061901 ; serial number YYYYMMDDnn 3600 ; refresh every 1 hours 1800 ; retry every 30 minutes 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day example.com. IN NS ns1.example.com. ; could be a primary server example.com. IN NS ns2.example.com. ; could be a secondary server example.com. IN MX 10 mail.example.com. example.com. IN A 192.0.2.1 ns1.example.com. IN A 192.0.2.2 ns2.example.com. IN A 192.0.2.3 mail.example.com. IN A 192.0.2.4 hello.example.com. IN TXT "Hello, world!"
Die erste Zeile definiert die Standard-TTL, die ein Nameserver automatisch auf jeden RR-Eintrag anwendet, der keine eigene TTL definiert hat.
Der erste RR ist der SOA-Eintrag. Er ist obligatorisch und enthält administrative Informationen wie einen Nameserver, die E-Mail-Adresse (mit einem Punkt anstelle eines @-Symbols) des zuständigen Domainadministrators, eine Versionsnummer der Zonendatei und Zeitangaben für das Caching.
Die zwei NS-Einträge definieren die autoritativen Nameserver für diese Zone. Hier haben wir zwei, die ebenfalls Domains innerhalb der Zone verwenden. ns1.example.com ist der primäre Nameserver, ns2.example.com der sekundäre. Hier fügen Sie Ihre sekundären Nameserver hinzu, damit die Kunden sie finden können.
Der MX-Eintrag definiert den E-Mail-Server für diese Zone.
Die A-Einträge bilden dann die Domains der Name- und E-Mail-Server auf IP-Adressen ab, mit denen sich die Clients mit den Servern verbinden können. Sie enthält auch eine Apex-Domain, die die reine Domain example.com auf eine IP-Adresse abbildet.
Der letzte TXT-Eintrag wird bei der Abfrage in die Zeichenfolge Hallo, Welt! aufgelöst.
Wie verhalten sich sekundäre Server zu primären (autoritativen) Servern?
Durch Hinzufügen der Adresse eines sekundären Nameservers zu einem NS-Eintrag wird dieser zu einem autoritativen Nameserver für eine Zone; er wird Teil der globalen DNS-Hierarchie. Ein autoritativer Nameserver ist ein Server, dessen Adresse in einem NS-Eintrag für eine Zone angegeben ist und der in der Regel alle DNS-Einträge für die von ihm bezeichnete Zone besitzt. Sowohl primäre als auch sekundäre Server können autoritativ für eine Zone sein.
Das Hinzufügen von NS-Einträgen für sekundäre Server ist von entscheidender Bedeutung, da die Kunden nur autoritative Server kennen, das Konzept der primären und sekundären Nameserver ist ihnen normalerweise nicht bekannt. Wenn Sie einen sekundären Server zu einem primären Server hinzufügen, aber die Adresse des sekundären Servers nicht als NS-Eintrag hinzugefügt wird, können die Clients ihn nicht finden.
Rekursive Nameserver
Das Gegenstück zu einem autoritativen Nameserver ist ein rekursiver Nameserver, der nicht für eine Zone zuständig ist. Rekursive Server leiten Anfragen an andere Nameserver zur Auflösung weiter und können die Ergebnisse aus Leistungsgründen in den Cache stellen. Da sie keine Zonendateien haben, die synchronisiert werden müssen, können sie keine sekundären Nameserver sein.
Das DNS-Auflösungsverfahren
DNS ist ein verteiltes System, d. h. es ist kein einzelner Server für alle Domains zuständig. Stattdessen besteht der Domainraum aus mehreren Zonen, die eine Baumstruktur bilden. Jede Zone enthält einen oder mehrere Domainnamen und einen oder mehrere Nameserver, die für sie zuständig sind. Wenn er nicht für eine (Sub-)Domain zuständig ist, enthält er in seiner Zonendatei einen RR, der angibt, dass ein anderer Server für diese Domain zuständig ist. Die für eine Zone zuständigen Nameserver werden als autoritative Nameserver der Zone bezeichnet. Wir haben einen Artikel geschrieben, der DNS-Zonen ausführlicher erklärt; lesen Sie ihn, wenn Sie mehr über Zonen erfahren möchten.
Der Prozess des Hinzufügens einer neuen RR zur Zonendatei und deren Auflösung für einen Client ist in Abbildung 2 dargestellt.
![Ein Diagramm zur Erläuterung der DNS-Architektur. Es enthält primäre, sekundäre, autoritative, rekursive, root und TLD Server](https://assets.gcore.pro/blog_containerizing/uploads/2023/07/secondary-dns-explained-2-1024x832.png)
- Ein Domainadministrator fügt dem primären (autoritativen) Nameserver einen neuen RR hinzu, zum Beispiel einen A-Eintrag für die Domain example.com.
- Die sekundären Nameserver fragen entweder die primären Server nach Updates ab oder werden benachrichtigt und laden die Updates über AXFR oder IXFR herunter.
- Sekundäre Server, die den primären Server nicht erreichen können, können Updates von anderen sekundären Servern erhalten, die für ihre Zone autorisierend sind.
- Eine Anwendung – z.B. ein Browser – sendet eine Anfrage zur Auflösung der Domain example.com an den lokalen Resolver.
- Der lokale Resolver leitet die Abfrage an einen rekursiven Nameserver (RNS) weiter, der sie an autoritative Server weiterleitet, die über die Zonendateien mit den RRs verfügen.
- Der RNS fragt einen Root-Server ab, der nur NS-Einträge für Nameserver der Top-Level-Domain (TLD) enthält. Er gibt die NS-Einträge für Nameserver zurück, die für die Domain com autorisierend sind.
- Der RNS fragt den TLD-Server ab, der nur NS-Einträge für die Domains unter der TLD com besitzt. Er gibt die NS-Einträge für die autoritativen Nameserver der Domain example.com zurück.
- Der RNS fragt einen der für example.com zuständigen Nameserver ab, in diesem Fall einen sekundären Nameserver. Die Auswahl des Servers erfolgt nach dem Round-Robin-Verfahren. Dieser Server liefert die Daten des A- oder AAAA-Eintrags für example.com. Der RNS gibt die Daten an den Resolver zurück, und der Resolver gibt sie an die Anwendung zurück.
Wie werden sekundäre Nameserver mit einem primären Nameserver synchronisiert?
Der Mechanismus, mit dem die Namenserver synchronisiert werden, wird als Zonentransfer bezeichnet. Die sekundären Server fragen entweder andere Server in ihrer Zone nach Updates ab oder werden von ihrem primären Server benachrichtigt. Sowohl die Abfrage als auch die Benachrichtigung hängen von der Versionsnummer einer Zonendatei ab.
Angenommen, der sekundäre Namenserver sieht, dass sich die Version geändert hat. In einem solchen Fall initialisiert er einen Zonentransfer entweder mit dem DNS-Zonentransferprotokoll (AXFR) oder dem inkrementellen Zonentransferprotokoll (IXFR), um die neuesten RRs vom primären Server oder anderen sekundären Servern, die aktueller sind, zu holen.
Es ist auch möglich, mehrere primäre Nameserver zu haben, deren Zonendateien manuell synchronisiert werden. Im Zusammenhang mit dem sekundären DNS bedeutet „manuell“, dass die Server nicht über DNS-spezifische Mechanismen synchronisiert werden. Es ist möglich, sie mit anderen automatischen Mitteln zu synchronisieren, z.B. mit Terraform-Skripten. Dazu würde ein Domainadministrator die Zonendatei-Definition im Skript aktualisieren, und Terraform würde sie bei einer Neuverteilung auf mehrere primäre Nameserver anwenden.
Was sind die Vorteile des sekundären DNS?
Nachdem wir nun den Mechanismus des Zonentransfers verstanden haben, wollen wir uns die Vorteile des sekundären DNS ansehen, die über die automatische Synchronisierung hinausgehen.
Verbesserte DNS-Redundanz und Ausfallsicherheit
Das Hinzufügen von sekundären Nameservern, die sich in verschiedenen Datenzentren befinden, verbessert die DNS-Redundanz. Wenn ein Nameserver ausfällt oder aus anderen Gründen nicht verfügbar ist, können die Kunden weiterhin die verbleibenden Server zur Auflösung von Domainnamen verwenden.
Sekundäre Nameserver verbessern auch die DNS-Ausfallsicherheit, da sie nicht nur mit dem primären Server, sondern auch mit den anderen sekundären Servern in ihrer Zone synchronisiert werden. Auf diese Weise können aktualisierte RRs immer noch auf einen sekundären Server übertragen werden, der sich nicht mit dem primären Server verbinden kann.
Wenn ein primärer Server autoritativ ist, muss er Abfragen auflösen und Aktualisierungen an die sekundären Server senden. Die Beantwortung von Client-Anfragen hat in der Regel die höchste Priorität. Wenn also die Auslastung des Primärservers zu hoch ist, erhält der Sekundärserver möglicherweise eine Benachrichtigung, kann aber einen Zonentransfer initialisieren. Wenn der Zonentransfer zu lange dauert, kann der sekundäre Server andere sekundäre Server um die Aktualisierung bitten und so die Belastung des primären Servers verringern.
Niedrige DNS-Latenz
Wenn Sie Ihren Betrieb auf einen anderen Kontinent verlagern, können Sie die Latenzzeit verbessern, indem Sie einen sekundären Nameserver an diesem neuen Standort einrichten. Wenn die Benutzer geografisch verstreut sind, können Sie Ihre sekundären Nameserver über den ganzen Globus verteilen, so dass jeder Benutzer einen in seiner Nähe nutzen kann. Wenn Sie nur einen primären Server haben, müssen Sie sich für einen Standort entscheiden, der möglicherweise nur einigen Ihrer Benutzer eine niedrige Latenz bietet und anderen keine niedrige Latenz bietet.
Clients wählen Nameserver über NS-Einträge aus und verwenden Round-Robin, um für jede nachfolgende Anfrage einen neuen Server auszuwählen. Dieser Mechanismus hilft einem Client nicht, den Server mit der geringsten Latenz zu finden, aber Sie können mehrere Server zu einem NS-Eintrag hinzufügen, indem Sie ihnen eine Anycast-IP-Adresse geben. Anycast leitet eine Anfrage an alle Server weiter, die die gleiche IP-Adresse haben, gibt aber nur die Antwort zurück, die zuerst an den Client zurückgekommen ist. Auf diese Weise erhalten die Clients immer den Server mit der geringsten Latenzzeit.
Obwohl Anycast nicht direkt mit DNS zusammenhängt, arbeitet es Hand in Hand mit dem Zonentransfermechanismus. Die sekundären Nameserver halten sich gegenseitig mit dem primären Server synchronisiert, und das Anycast-Protokoll weist jedem Client den schnellsten Server zu.
DNS Load Balancing
Eine Zonendatei kann NS-Einträge für mehrere Nameserver enthalten. Der Prozess der Domainauflösung wählt einen dieser Server mit Hilfe eines Round-Robin-Algorithmus aus. Bei diesem Algorithmus merkt sich der Client, welchen Nameserver er bereits benutzt hat und wählt für die nächste Anfrage einen anderen aus. Auf diese Weise wird jede nachfolgende Anfrage an einen anderen Server weitergeleitet, der sie bearbeiten kann, während der vorherige Server noch beschäftigt ist.
Wenn Ihre Nutzerbasis wächst, muss auch Ihre Infrastruktur die zusätzliche Last tragen. Das Mantra der Cloud ist die horizontale Skalierung, d. h., wenn die Last steigt, müssen neue Server hinzugefügt werden. Das sekundäre DNS, das die Last auf mehrere Nameserver verteilt, funktioniert also im Sinne dieses Mantras.
Verbesserte Sicherheit für primäre Server
Bei einer typischen DNS-Einrichtung würden Sie einen NS-Eintrag für Ihren primären Nameserver hinzufügen, damit Clients den primären Nameserver direkt abfragen können. Clients verwenden NS-Einträge, um Nameserver zu finden, aber primäre und sekundäre Server verwenden andere Kommunikationsmittel, so dass es möglich ist, zu synchronisieren, ohne dass einer von ihnen in einem NS-Eintrag vorhanden ist. Wenn Sie also nur NS-Einträge für sekundäre Server hinzufügen, wissen die Kunden nichts von Ihrem primären Server. Sie können den primären Server verwenden, um Ihre RRs zu aktualisieren und mit den sekundären Servern zu synchronisieren, während die sekundären Server für die Auflösung von Client-Anfragen zuständig sind.
Mit dieser Technik ist Ihr Primärserver vor der Öffentlichkeit verborgen, kann sich auf Zonentransfers konzentrieren und ist vor potenziellen Angreifern geschützt.
Nutzung von Cloud-DNS mit lokalen DNS-Servern
Viele Unternehmen – vor allem größere, etabliertere Unternehmen – betreiben bereits ihre eigenen Nameserver vor Ort. Oft sind diese eng mit der Infrastruktur verbunden, mit benutzerdefinierten Skripten und Prozessen, die RRs erstellen, aktualisieren und entfernen.
Mit sekundären Nameservern können diese Unternehmen ihren vorhandenen Server vor Ort als primären Server beibehalten und sekundäre Nameserver hinzufügen, die in der Cloud laufen. Auf diese Weise können sie die Vorteile der Cloud und des sekundären DNS mit minimalen Änderungen an ihrer lokalen Infrastruktur nutzen.
Fazit
Ihre Domains sind der Einstiegspunkt zu Ihren Websites und Anwendungen. Daher ist es wichtig, dass die Nutzer sie immer sofort auflösen können. Sekundäres DNS hilft Ihnen, dieses Ziel zu erreichen, indem Sie Ihrer Einrichtung zusätzliche Nameserver hinzufügen können, die sich automatisch miteinander synchronisieren. Jeder sekundäre Nameserver agiert wie ein autoritativer Nameserver und kann Domainnamen genau wie Ihr primärer Server auflösen, jedoch ohne Verwaltungsaufwand. Bei intelligentem Einsatz rund um den Globus in Verbindung mit Technologien wie Anycast steigert sekundäres DNS sogar die Leistung, indem es die Latenzzeit verringert, und kann dazu beitragen, Ihre primären Sserver vor Angriffen zu schützen.
Das DNS-Hosting von Gcore ermöglicht Ihnen die Einrichtung von Zonentransfers für sekundäre DNS mit dem Open-Source-Tool OctoDNS, so dass Sie alle genannten Vorteile nutzen können, ohne sich Gedanken über globale Implementierungen machen zu müssen. Sehen Sie sich unsere Dokumente an, um zu erfahren, wie Sie anfangen können!