Einführung
DNS, oder das Domain Name System, ist oft ein sehr schwieriger Teil des Erlernens, wie man Webseiten und Server konfiguriert. Das Verständnis der Funktionsweise von DNS hilft Ihnen bei der Diagnose von Problemen mit der Konfiguration des Zugriffs auf Ihre Websites und ermöglicht es Ihnen, Ihr Verständnis dafür zu erweitern, was hinter den Kulissen vor sich geht.

In diesem Leitfaden werden wir einige grundlegende DNS-Konzepte besprechen, die Ihnen helfen, mit Ihrer DNS-Konfiguration den ersten Schritt zu tun. Nachdem Sie sich mit diesem Leitfaden beschäftigt haben, sollten Sie bereit sein, Ihren Domainnamen mit DigitalOcean einzurichten oder Ihren eigenen DNS-Server einzurichten.

Bevor wir uns mit der Einrichtung Ihrer eigenen Server zur Auflösung Ihrer Domain oder der Einrichtung unserer Domains im Control Panel befassen, lassen Sie uns einige grundlegende Konzepte darüber durchgehen, wie all dies tatsächlich funktioniert.

Domänenterminologie
Wir sollten damit beginnen, unsere Bedingungen zu definieren. Während einige dieser Themen aus anderen Kontexten bekannt sind, gibt es viele Begriffe, die verwendet werden, wenn es um Domainnamen und DNS geht, die in anderen Bereichen des Computings nicht allzu oft verwendet werden.

Fangen wir ganz einfach an:

Domain Name System
Das Domain-Namensystem, besser bekannt als “DNS”, ist das bestehende Netzwerksystem, das es uns ermöglicht, menschenfreundliche Namen in eindeutige Adressen aufzulösen.

Domain Name
Ein Domainname ist der menschenfreundliche Name, den wir gewohnt sind, mit einer Internetressource zu verbinden. Zum Beispiel ist “google.com” ein Domainname. Einige Leute werden sagen, dass der “Google”-Abschnitt die Domain ist, aber wir können uns im Allgemeinen auf die kombinierte Form als Domain-Name beziehen.

Die URL “google.com” ist mit den Servern der Google Inc. verknüpft. Das Domain-Namenssystem ermöglicht es uns, die Google-Server zu erreichen, wenn wir “google.com” in unsere Browser eingeben.

IP-Adresse
Eine IP-Adresse ist das, was wir einen netzwerkadressierbaren Standort nennen. Jede IP-Adresse muss in ihrem Netzwerk eindeutig sein. Wenn wir über Websites sprechen, ist dieses Netzwerk das gesamte Internet.

IPv4, die gebräuchlichste Form von Adressen, wird als vier Zahlensätze mit jeweils bis zu drei Ziffern geschrieben, wobei jeder Satz durch einen Punkt getrennt ist. Beispielsweise könnte “111.222.111.111.111.222” eine gültige IPv4-IP-Adresse sein. Mit DNS ordnen wir dieser Adresse einen Namen zu, so dass Sie sich nicht an einen komplizierten Satz von Nummern für jeden Ort erinnern müssen, den Sie in einem Netzwerk besuchen möchten.

Top-Level-Domain
Eine Top-Level-Domain oder TLD ist der allgemeinste Teil der Domain. Die Top-Level-Domain ist der am weitesten rechts gelegene Teil (durch einen Punkt getrennt). Gängige Top-Level-Domains sind “com”, “net”, “org”, “gov”, “edu” und “io”.

Top-Level-Domains stehen in der Hierarchie an erster Stelle, was die Domain-Namen betrifft. Bestimmte Parteien erhalten von der ICANN (Internet Corporation for Assigned Names and Numbers) die Managementkontrolle über Top-Level-Domains. Diese Parteien können dann Domainnamen unter der TLD verteilen, in der Regel über einen Domain-Registrar.

Gastgeber
Innerhalb einer Domäne kann der Domäneninhaber einzelne Hosts definieren, die sich auf einzelne Computer oder Dienste beziehen, die über eine Domäne zugänglich sind. So machen die meisten Domaininhaber ihre Webserver über die bloße Domain (example.com) und auch über die “Host”-Definition “wwww” (www.example.com) zugänglich.

Sie können andere Hostdefinitionen unter der allgemeinen Domäne haben. Sie können API-Zugriff über einen “api”-Host (api.example.com) oder ftp-Zugriff über die Definition eines Hosts namens “ftp” oder “files” (ftp.example.com oder files.example.com) haben. Die Hostnamen können beliebig sein, solange sie für die Domain eindeutig sind.

Subdomain
Ein Thema, das sich auf Hosts bezieht, sind Subdomains.

DNS arbeitet in einer Hierarchie. TLDs können viele Domänen unter sich haben. So hat beispielsweise die TLD “com” sowohl “google.com” als auch “ubuntu.com” darunter. Eine “Subdomain” bezieht sich auf jede Domain, die Teil einer größeren Domain ist. In diesem Fall kann man sagen, dass “ubuntu.com” eine Subdomain von “com” ist. Dies wird typischerweise nur als Domäne bezeichnet oder der “ubuntu”-Abschnitt wird als SLD bezeichnet, was soviel wie Second-Level-Domäne bedeutet.

Ebenso kann jede Domain “Subdomains” steuern, die sich darunter befinden. Dies ist in der Regel das, was wir unter Subdomains verstehen. Zum Beispiel könntest du eine Subdomain für die Geschichtsabteilung deiner Schule unter “www.history.school.edu” haben. Der Abschnitt “Geschichte” ist eine Subdomain.

Der Unterschied zwischen einem Hostnamen und einer Subdomain besteht darin, dass ein Host einen Computer oder eine Ressource definiert, während eine Subdomain die übergeordnete Domain erweitert. Es ist eine Methode zur Unterteilung der Domäne selbst.

Unabhängig davon, ob Sie über Subdomains oder Hosts sprechen, können Sie beginnen zu sehen, dass die links-meisten Teile einer Domain die spezifischsten sind. So funktioniert DNS: von den meisten bis zu den wenigsten spezifischen, während Sie von links nach rechts lesen.

Voll qualifizierter Domainname
Ein voll qualifizierter Domainname, oft auch FQDN genannt, ist das, was wir einen absoluten Domainnamen nennen. Domänen im DNS-System können relativ zueinander vergeben werden und können daher etwas mehrdeutig sein. Ein FQDN ist ein Absolutname, der seine Position in Bezug auf die absolute Wurzel des Domain-Namensystems angibt.

Das bedeutet, dass jede übergeordnete Domäne einschließlich der TLD angegeben wird. Ein korrekter FQDN endet mit einem Punkt, der die Wurzel der DNS-Hierarchie angibt. Ein Beispiel für einen FQDN ist “mail.google.com.”. Manchmal benötigt Software, die nach FQDN ruft, nicht den Endpunkt, aber der Endpunkt muss den ICANN-Standards entsprechen.

Nameserver
Ein Name-Server ist ein Computer, der dazu bestimmt ist, Domainnamen in IP-Adressen zu übersetzen. Diese Server erledigen den größten Teil der Arbeit im DNS-System. Da die Gesamtzahl der Domänenübersetzungen für einen Server zu hoch ist, kann jeder Server die Anfrage an andere Nameserver weiterleiten oder die Verantwortung für eine Teilmenge von Subdomänen übertragen, für die er verantwortlich ist.

Name-Server können “autoritativ” sein, d.h. sie beantworten Anfragen nach Domänen unter ihrer Kontrolle. Andernfalls können sie auf andere Server verweisen oder zwischengespeicherte Kopien der Daten anderer Name-Server bereitstellen.

Zonendatei
Eine Zonendatei ist eine einfache Textdatei, die die Zuordnungen zwischen Domänennamen und IP-Adressen enthält. So findet das DNS-System schließlich heraus, welche IP-Adresse kontaktiert werden soll, wenn ein Benutzer einen bestimmten Domainnamen anfordert.

Zonendateien befinden sich auf Name-Servern und definieren im Allgemeinen die unter einer bestimmten Domäne verfügbaren Ressourcen oder den Ort, an den man gehen kann, um diese Informationen zu erhalten.

Aufzeichnungen
Innerhalb einer Zonendatei werden Datensätze aufbewahrt. In seiner einfachsten Form ist ein Datensatz im Grunde genommen eine einzige Zuordnung zwischen einer Ressource und einem Namen. Diese können einen Domainnamen einer IP-Adresse zuordnen, die Name-Server für die Domain definieren, die Mail-Server für die Domain definieren, etc.

So funktioniert DNS
Jetzt, da Sie mit einigen der mit DNS verbundenen Terminologien vertraut sind, wie funktioniert das System tatsächlich?

Das System ist auf einer hohen Ebene sehr einfach, aber sehr komplex, wenn man sich die Details ansieht. Insgesamt handelt es sich jedoch um eine sehr zuverlässige Infrastruktur, die für die Verbreitung des Internets, wie wir es heute kennen, unerlässlich war.

Root-Server
Wie bereits erwähnt, ist DNS im Kern ein hierarchisches System. An der Spitze dieses Systems steht das, was als “Root-Server” bezeichnet wird. Diese Server werden von verschiedenen Unternehmen kontrolliert und von der ICANN (Internet Corporation for Assigned Names and Numbers) autorisiert.

Derzeit sind 13 Root-Server in Betrieb. Da es jedoch jede Minute eine unglaubliche Anzahl von Namen zu lösen gibt, wird jeder dieser Server tatsächlich gespiegelt. Das Interessante an dieser Einrichtung ist, dass jeder der Spiegel für einen einzelnen Root-Server die gleiche IP-Adresse hat. Wenn Anfragen für einen bestimmten Root-Server gestellt werden, wird die Anfrage an den nächsten Spiegel dieses Root-Servers weitergeleitet.

Was machen diese Root-Server? Root-Server bearbeiten Anfragen nach Informationen über Top-Level-Domains. Wenn also eine Anfrage für etwas eintrifft, das ein untergeordneter Name-Server nicht lösen kann, wird eine Anfrage an den Root-Server für die Domäne gestellt.

Die Root-Server wissen nicht genau, wo die Domain gehostet wird. Sie können den Antragsteller jedoch an die Nameserver verweisen, die die speziell angeforderte Top-Level-Domain verwalten.

Wenn also eine Anfrage für “www.wikipedia.org” an den Root-Server gerichtet wird, findet der Root-Server das Ergebnis nicht in seinen Datensätzen. Es wird seine Zonendateien auf eine Liste überprüfen, die mit “www.wikipedia.org” übereinstimmt. Es wird keins finden.

Stattdessen findet sie einen Datensatz für die TLD “org” und gibt der anfragenden Stelle die Adresse des für “org”-Adressen zuständigen Nameservers an.

TLD-Server
Der Antragsteller sendet dann eine neue Anfrage an die IP-Adresse (die ihm vom Root-Server zugewiesen wurde), die für die Top-Level-Domain der Anfrage verantwortlich ist.

Um unser Beispiel fortzusetzen, würde es also eine Anfrage an den Nameserver senden, der für die Kenntnis von “org”-Domains verantwortlich ist, um zu sehen, ob er weiß, wo sich “www.wikipedia.org” befindet.

Noch einmal wird der Antragsteller in seinen Zonendateien nach “www.wikipdia.org” suchen. Es wird diesen Datensatz nicht in seinen Dateien finden.

Es wird jedoch ein Datensatz mit der IP-Adresse des für “wikipedia.org” zuständigen Nameservers gefunden. Das kommt der von uns gewünschten Antwort viel näher.

Domain-Level-Name-Server
An dieser Stelle hat der Antragsteller die IP-Adresse des Nameservers, der für die Kenntnis der tatsächlichen IP-Adresse der Ressource verantwortlich ist. Er sendet eine neue Anfrage an den Nameserver und fragt erneut, ob er “www.wikipedia.org” auflösen kann.

Der Name-Server überprüft seine Zonendateien und stellt fest, dass er eine Zonendatei hat, die mit “wikipedia.org” verknüpft ist. In dieser Datei befindet sich ein Datensatz für den “www” Host. Dieser Datensatz gibt die IP-Adresse an, wo sich dieser Host befindet. Der Name-Server gibt die endgültige Antwort an den Antragsteller zurück.

Was ist ein Resolving Name Server?
Im obigen Szenario haben wir uns auf einen “Antragsteller” bezogen. Was ist in dieser Situation der Antragsteller?

In fast allen Fällen wird der Antragsteller das sein, was wir einen “resolving name server” nennen. Ein resolving name server ist einer, der konfiguriert ist, um anderen Servern Fragen zu stellen. Es ist im Grunde genommen ein Vermittler für einen Benutzer, der frühere Abfrageergebnisse zwischenspeichert, um die Geschwindigkeit zu verbessern, und die Adressen der Root kennt.

Grundsätzlich wird ein Benutzer in der Regel einige auflösende Name-Server auf seinem Computersystem konfiguriert haben. Die auflösenden Name-Server werden in der Regel von einem ISP oder anderen Unternehmen bereitgestellt. Zum Beispiel bietet Google die Lösung von DNS-Servern, die Sie abfragen können. Diese können entweder automatisch oder manuell in Ihrem Computer konfiguriert werden.

Wenn Sie eine URL in der Adressleiste Ihres Browsers eingeben, sucht Ihr Computer zunächst, ob er lokal herausfinden kann, wo sich die Ressource befindet. Es überprüft die Datei “hosts” auf dem Computer und an einigen anderen Stellen. Anschließend sendet er die Anforderung an den auflösenden Name-Server und wartet zurück, um die IP-Adresse der Ressource zu erhalten.

Der auflösende Name-Server überprüft dann seinen Cache auf die Antwort. Wenn es sie nicht findet, durchläuft es die oben beschriebenen Schritte.

Die Auflösung von Name-Servern komprimiert grundsätzlich den Anforderungsprozess für den Endbenutzer. Die Clients müssen es einfach nur wissen, die auflösenden Nameserver zu fragen, wo sich eine Ressource befindet, und sicher sein, dass sie die endgültige Antwort untersuchen und zurückgeben werden.

Zonendateien
Wir haben im obigen Prozess die Idee der “Zonendateien” und “Datensätze” erwähnt.

Zonendateien sind die Art und Weise, wie Name-Server Informationen über die Domänen speichern, von denen sie wissen. Jede Domäne, von der ein Name-Server weiß, wird in einer Zonendatei gespeichert. Die meisten Anfragen, die an den durchschnittlichen Nameserver kommen, sind nicht etwas, für das der Server Zonendateien hat.

Wenn es für die Verarbeitung rekursiver Abfragen konfiguriert ist, wie z.B. ein auflösender Name-Server, findet es die Antwort heraus und gibt sie zurück. Andernfalls teilt er dem anfragenden Partner mit, wo er als nächstes suchen soll.

Je mehr Zonendateien ein Name-Server hat, desto mehr Anfragen kann er zuverlässig beantworten.

Eine Zonendatei beschreibt eine DNS “Zone”, die im Grunde genommen eine Teilmenge des gesamten DNS-Namenssystems ist. Im Allgemeinen wird es verwendet, um nur eine einzelne Domäne zu konfigurieren. Es kann eine Reihe von Datensätzen enthalten, die definieren, wo sich Ressourcen für die jeweilige Domäne befinden.

Der $ORIGIN der Zone ist ein Parameter, der standardmäßig der höchsten Autoritätsstufe der Zone entspricht.

Wenn also eine Zonendatei verwendet wird, um die Domäne “example.com.” zu konfigurieren, wird der $ORIGIN auf example.com…. gesetzt.

Dies ist entweder oben in der Zonendatei konfiguriert oder kann in der Konfigurationsdatei des DNS-Servers definiert werden, die auf die Zonendatei verweist. So oder so, dieser Parameter beschreibt, wofür die Zone maßgebend sein wird.

Ebenso konfiguriert die $TTL die “Lebenszeit” der von ihr bereitgestellten Informationen. Es ist im Grunde genommen ein Timer. Ein Caching-Nameserver kann zuvor abgefragte Ergebnisse verwenden, um Fragen zu beantworten, bis der TTL-Wert abgelaufen ist.

Satzarten
Innerhalb der Zonendatei können wir viele verschiedene Datensatzarten haben. Wir werden hier auf einige der gebräuchlichsten (oder obligatorischen) Typen eingehen.

SOA-Aufzeichnungen
Der Start of Authority, oder SOA, Datensatz ist ein Pflichtdatensatz in allen Zonendateien. Es muss der erste echte Datensatz in einer Datei sein (obwohl die $ORIGIN- oder $TTL-Spezifikationen oben erscheinen können). Es ist auch eines der komplexesten zu verstehen.

Der Beginn der Autoritätsakte sieht in etwa so aus:

domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; Seriennummer
3h ; Aktualisierungsintervall
30m ; Wiederholungsintervall
3w ; Verfallszeit
1h ; negative TTL
)
Lassen Sie uns erklären, wofür jedes Teil bestimmt ist:

domain.com…: Dies ist die Wurzel der Zone. Dies gibt an, dass die Zonendatei für die Domäne domain.com. bestimmt ist. Oftmals werden Sie sehen, dass dies durch @ ersetzt wird, was nur ein Platzhalter ist, der den Inhalt der Variablen $ORIGIN ersetzt, die wir oben kennengelernt haben.
IN SOA: Der Abschnitt “IN” bedeutet Internet (und wird in vielen Datensätzen vorhanden sein). Die SOA ist das Kennzeichen, dass es sich um einen Start of Authority Datensatz handelt.
ns1.domain.com…: Hiermit wird der primäre Master-Name-Server für diese Domäne definiert. Name-Server können entweder Master oder Slaves sein, und wenn dynamisches DNS konfiguriert ist, muss ein Server ein “primärer Master” sein, der hier beschrieben wird. Wenn Sie kein dynamisches DNS konfiguriert haben, dann ist dies nur einer Ihrer Master-Name-Server.
admin.domain.com…: Dies ist die E-Mail-Adresse des Administrators für diese Zone. Das “@” wird durch einen Punkt in der E-Mail-Adresse ersetzt. Wenn der Namensteil der E-Mail-Adresse normalerweise einen Punkt enthält, wird dieser durch ein “\” in diesem Teil ersetzt (your.name@domain.com wird zu Ihrem\name.domain.com).
12083: Dies ist die Seriennummer für die Zonendatei. Jedes Mal, wenn Sie eine Zonendatei bearbeiten, müssen Sie diese Zahl erhöhen, damit sich die Zonendatei korrekt ausbreiten kann. Slave-Server prüfen, ob die Seriennummer des Master-Servers für eine Zone größer ist als die, die sie auf ihrem System haben. Ist dies der Fall, fordert es die neue Zonendatei an, andernfalls wird die ursprüngliche Datei weiterhin bereitgestellt.
3h: Dies ist das Aktualisierungsintervall für die Zone. Dies ist die Zeit, die der Slave wartet, bevor er den Master nach Zonendateiänderungen abfragt.

30m: Dies ist das Wiederholungsintervall für diese Zone. Wenn der Slave nach Ablauf der Aktualisierungsphase keine Verbindung zum Master herstellen kann, wartet er diese Zeitspanne und versucht erneut, den Master abzufragen.
3w: Dies ist die Verfallszeit. Wenn ein Slave-Name-Server den Master für diese Zeit nicht kontaktieren konnte, gibt er keine Antworten mehr als autoritative Quelle für diese Zone zurück.
1h: Dies ist die Zeitspanne, in der der Name-Server einen Namensfehler zwischenspeichert, wenn er den gewünschten Namen in dieser Datei nicht findet.
A und AAAA Aufzeichnungen
Beide Datensätze bilden einen Host auf eine IP-Adresse ab. Der Datensatz “A” wird verwendet, um einen Host einer IPv4-IP-Adresse zuzuordnen, während die Datensätze “AAAA” verwendet werden, um einen Host einer IPv6-Adresse zuzuordnen.

Das allgemeine Format dieser Datensätze ist folgendes:

Host IN A IPv4_Adresse
Host IN AAAA IPv6_Adresse
Da unser SOA-Datensatz also einen primären Master-Server unter “ns1.domain.com” aufgerufen hat, müssten wir diesen auf eine Adresse auf eine IP-Adresse abbilden, da “ns1.domain.com” innerhalb der Zone “domain.com” liegt, die diese Datei definiert.

Die Platte könnte ungefähr so aussehen:

ns1 IN A 111.222.111.111.222 222
Beachten Sie, dass wir nicht den vollen Namen angeben müssen. Wir können einfach den Host angeben, ohne den FQDN und der DNS-Server füllt den Rest mit dem Wert $ORIGIN. Wir könnten jedoch genauso einfach das gesamte FQDN verwenden, wenn wir Lust haben, semantisch zu sein:

ns1.domain.com. IN A 111.222.111.111.222
In den meisten Fällen werden Sie hier Ihren Webserver als “www” definieren:

www IN A 222.222.222.222.222.222
Wir sollten auch sagen, wohin die Basisdomäne auflöst. Wir können das so machen:

domain.com. IN EINEM 222.222.222.222.222.222
Wir hätten das “@” verwenden können, um uns stattdessen auf die Basisdomäne zu beziehen:

@ IN A 222.222.222.222.222.222
Wir haben auch die Möglichkeit, alles aufzulösen, was unter dieser Domain nicht explizit auch für diesen Server definiert ist. Wir können dies mit dem Platzhalter “*” tun:

* IN A 222.222.222.222.222.222
All dies funktioniert genauso gut mit AAAA-Einträgen für IPv6-Adressen.

CNAME-Einträge
CNAME-Records definieren einen Alias für den kanonischen Namen Ihres Servers (einen, der durch einen A- oder AAAA-Record definiert ist).

Zum Beispiel könnten wir einen A-Namensdatensatz haben, der den “server1”-Host definiert und dann das “www” als Alias für diesen Host verwenden:

server1 IN A 111.111.111.111.111.111
www IN CNAME server1
Beachten Sie, dass diese Aliase mit einigen Performance-Einbußen verbunden sind, da sie eine zusätzliche Abfrage an den Server erfordern. Meistens konnte das gleiche Ergebnis durch die Verwendung zusätzlicher A- oder AAAA-Einträge erzielt werden.

Ein Fall, in dem ein CNAME empfohlen wird, ist die Bereitstellung eines Alias für eine Ressource außerhalb der aktuellen Zone.

MX-Einträge
MX-Einträge werden verwendet, um die Mail-Exchanges zu definieren, die für die Domäne verwendet werden. Auf diese Weise können E-Mail-Nachrichten korrekt auf Ihrem Mailserver ankommen.

Im Gegensatz zu vielen anderen Datensatztypen bilden Mail-Datensätze im Allgemeinen keinen Host auf etwas ab, da sie für die gesamte Zone gelten. Als solche sehen sie in der Regel so aus:

IN MX 10 mail.domain.com.
Beachten Sie, dass am Anfang kein Hostname steht.

Beachten Sie auch, dass dort eine zusätzliche Nummer enthalten ist. Dies ist die Präferenznummer, die Computern hilft, zu entscheiden, an welchen Server sie E-Mails senden sollen, wenn mehrere Mailserver definiert sind. Geringere Zahlen haben eine höhere Priorität.

Der MX-Eintrag sollte im Allgemeinen auf einen Host zeigen, der durch einen A- oder AAAA-Eintrag definiert ist, und nicht durch einen CNAME.

Also, sagen wir, wir haben zwei Mailserver. Es müsste Aufzeichnungen geben, die so ähnlich aussehen:

IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111.111.111
mail2 IN A 222.222.222.222.222.222
In diesem Beispiel ist der “mail1”-Host der bevorzugte E-Mail-Austauschserver.

Wir könnten das auch so schreiben:

IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111.111.111
mail2 IN A 222.222.222.222.222.222
NS-Datensätze
Diese Satzart definiert die Name-Server, die für diese Zone verwendet werden.

Sie fragen sich vielleicht, “wenn sich die Zonendatei auf dem Nameserver befindet, warum muss sie sich selbst referenzieren”. Ein Teil dessen, was DNS so erfolgreich macht, sind die verschiedenen Ebenen des Caching. Ein Grund für die Definition von Name-Servern innerhalb der Zonendatei ist, dass die Zonendatei möglicherweise tatsächlich von einer zwischengespeicherten Kopie auf einem anderen Name-Server bereitgestellt wird. Es gibt noch andere Gründe, warum man die auf dem Nameserver selbst definierten Nameserver benötigt, aber darauf werden wir hier nicht eingehen.

Wie die MX-Einträge sind dies zonenweite Parameter, so dass sie auch keine Hosts aufnehmen. Im Allgemeinen sehen sie so aus:

IN NS ns1.domain.com.
IN NS ns2.domain.com.
Sie sollten in jeder Zonendatei mindestens zwei Name-Server definiert haben, um bei einem Problem mit einem Server korrekt zu arbeiten. Die meisten DNS-Serversoftware betrachtet eine Zonendatei als ungültig, wenn es nur einen einzigen Nameserver gibt.

Fügen Sie wie immer das Mapping für die Hosts mit A- oder AAAA-Einträgen hinzu:

IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111.111.111
ns2 IN A 123.211.111.233
Es gibt noch eine ganze Reihe anderer Datensatztypen, die Sie verwenden können, aber das sind wahrscheinlich die häufigsten Typen, auf die Sie stoßen werden.

PTR-Einträge
Die PTR-Einträge werden verwendet, um einen Namen zu definieren, der einer IP-Adresse zugeordnet ist. PTR-Einträge sind die Umkehrung eines A- oder AAAA-Eintrags. PTR-Datensätze sind insofern einzigartig, als sie mit dem Wurzelverzeichnis.arpa beginnen und an die Eigentümer der IP-Adressen delegiert werden. Die regionalen Internet-Register (RIRs) verwalten die Übertragung von IP-Adressen an Unternehmen und Dienstanbieter. Zu den regionalen Internet-Registern gehören APNIC, ARIN, RIPE NCC, LACNIC und AFRINIC.

Hier ist ein Beispiel für einen PTR-Eintrag für 111.222.333.444, der so aussehen würde:

444.333.222.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Dieses Beispiel eines PTR-Eintrags für eine IPv6-Adresse zeigt das Nibbelformat der Rückseite des IPv6-DNS-Servers 2001:4860:4860:4860::8888 von Google.

8.8.8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
Das Kommandozeilen-Tool dig mit dem Flag -x kann verwendet werden, um den Reverse-DNS-Namen einer IP-Adresse zu ermitteln.

Hier ist ein Beispiel für einen dig-Befehl. Das +short wird angehängt, um die Ausgabe auf den umgekehrten DNS-Namen zu reduzieren.

dig -x 8.8.4.4.4 +kurzzeitig
Die Ausgabe für den obigen dig-Befehl ist der Domänenname im PTR-Record für die IP-Adresse:

google-public-dns-b.google.com.
Server im Internet verwenden PTR-Records, um Domänennamen in Log-Einträgen zu platzieren, fundierte Entscheidungen zur Behandlung von Spam zu treffen und leicht lesbare Details über andere Geräte anzuzeigen.

Am häufigsten verwendete E-Mail-Server suchen den PTR-Eintrag einer IP-Adresse, von der sie E-Mails empfangen. Wenn der Quell-IP-Adresse kein PTR-Eintrag zugeordnet ist, können die gesendeten E-Mails als Spam behandelt und abgelehnt werden. Es ist nicht wichtig, dass der FQDN im PTR mit dem Domänennamen der gesendeten E-Mail übereinstimmt. Wichtig ist, dass es einen gültigen PTR-Datensatz mit einem entsprechenden und passenden forward A-Datensatz gibt.

Normalerweise erhalten Netzwerkrouter im Internet PTR-Einträge, die ihrem physischen Standort entsprechen. Beispielsweise können Sie Referenzen auf “NYC” oder “CHI” für einen Router in New York City oder Chicago sehen. Dies ist hilfreich, wenn Sie eine Traceroute oder MTR ausführen und den Verlauf des Internetverkehrs überprüfen.

Die meisten Anbieter, die dedizierte Server oder VPS-Dienste anbieten, geben Kunden die Möglichkeit, einen PTR-Eintrag für ihre IP-Adresse zu erstellen. DigitalOcean weist automatisch den PTR-Eintrag eines beliebigen Droplets zu, wenn das Droplet mit einem Domänennamen benannt ist. Der Droplet-Name wird bei der Erstellung vergeben und kann später über die Einstellungsseite der Droplet-Konsole bearbeitet werden.

Hinweis: Es ist wichtig, dass der FQDN im PTR-Datensatz einen entsprechenden und passenden Vorwärts-A-Datensatz hat. Beispiel: 111.222.333.444 hat eine PTR von server.example.com und server.example.com ist ein A-Eintrag, der auf 111.222.333.444 zeigt.

CAA-Sätze
CAA-Datensätze werden verwendet, um anzugeben, welche Zertifizierungsstellen (CAs) SSL/TLS-Zertifikate für Ihre Domain ausstellen dürfen. Ab dem 8. September 2017 sind alle CAs verpflichtet, vor der Ausstellung eines Zertifikats nach diesen Aufzeichnungen zu suchen. Wenn kein Datensatz vorhanden ist, kann jede CA ein Zertifikat ausstellen. Andernfalls dürfen nur die angegebenen CAs Zertifikate ausstellen. CAA-Einträge können auf einzelne Hosts oder ganze Domänen angewendet werden.

Es folgt ein exemplarischer CAA-Eintrag:

example.com. IN CAA 0 Ausgabe “letsencrypt.org”.
Der Host, IN und der Satztyp (CAA) sind gemeinsame DNS-Felder. Die oben genannten CAA-spezifischen Informationen sind der Abschnitt “letsencrypt.org” mit der Ausgabe 0. Es besteht aus drei Teilen: Flags (0), Tags (issue) und Werte (“letsencrypt.org”).

Flags sind eine ganze Zahl, die angibt, wie eine CA mit Tags umgehen soll, die sie nicht versteht. Wenn das Flag 0 ist, wird der Datensatz ignoriert. Wenn 1, muss die CA die Ausstellung des Zertifikats ablehnen.
Tags sind Zeichenketten, die den Zweck eines CAA-Eintrags bezeichnen. Derzeit können sie ausgestellt werden, um eine CA zu autorisieren, Zertifikate für einen bestimmten Hostnamen zu erstellen, um Wildcard-Zertifikate zu autorisieren, oder um eine URL zu definieren, unter der CAs Richtlinienverletzungen melden können.
Werte sind eine Zeichenkette, die dem Tag des Datensatzes zugeordnet ist. Für Issue und Issuewild ist dies in der Regel die Domäne der CA, der Sie die Berechtigung erteilen. Für iodef kann dies die URL eines Kontaktformulars oder ein mailto: Link für E-Mail-Feedback sein.
Sie können dig verwenden, um CAA-Einträge mit den folgenden Optionen abzurufen:

dig example.com Typ257
Weitere Informationen zu CAA-Datensätzen finden Sie in RFC 6844 oder in unserem Tutorial How To Create and Manage CAA Records Using DigitalOcean DNS.

Fazit
Du solltest jetzt ein ziemlich gutes Verständnis dafür haben, wie DNS funktioniert. Während die allgemeine Idee relativ leicht zu verstehen ist, sobald Sie mit der Strategie vertraut sind, ist dies immer noch etwas, das für unerfahrene Administratoren schwierig in die Praxis umzusetzen sein kann.