Überblick über DNS-Terminologien, -Komponenten und -Konzepte

DNS (Domain Name System) ist eine der entscheidenden Komponenten, die das Internet antreiben. Ein gutes Verständnis der Funktionsweise von DNS kann helfen, Probleme mit der Website-Konfiguration zu diagnostizieren und Ihr Verständnis dafür zu erweitern, was hinter den Kulissen vorgeht.

In diesem Leitfaden werden wir über einige grundlegende Konzepte von DNS sprechen, um Ihnen eine solide Grundlage für die Arbeit mit Ihrer DNS-Konfiguration zu bieten. Dieser Leitfaden hilft Ihnen auch bei der Einrichtung Ihres eigenen Domainnamens oder DNS-Servers.

Lassen Sie uns beginnen!

Domain-Terminologien

Zuerst müssen wir ein Verständnis für die Begriffe entwickeln, die wir verwenden werden. Einige davon sind Ihnen vielleicht schon aus anderen Zusammenhängen bekannt. Es gibt jedoch viele spezifische Begriffe im Zusammenhang mit Domainnamen und DNS, die in anderen Bereichen der Informatik kaum besprochen werden.

• Domain Name System

Das Domain Name System (kurz DNS) ist ein Netzwerksystem, das benutzerfreundliche Domainnamen in eindeutige IP-Adressen übersetzt.

• Domainname

Ein Domainname bezieht sich auf den benutzerfreundlichen Namen, der mit einer Internetressource verknüpft wird. Zum Beispiel ist “cloudsigma.com” ein Domainname. Einige mögen argumentieren, dass nur der Teil “cloudsigma” der Domainname ist, aber im Allgemeinen bezieht es sich auf das Ganze.

Die URL “cloudsigma.com” ist mit den Servern im Besitz von CloudSigma verknüpft. Wenn Sie die URL in den Webbrowser eingeben, kommuniziert dieser mit dem DNS, um eine Verbindung zur IP-Adresse des Zielservers herzustellen.

• IP-Adresse

Eine IP-Adresse fungiert als Netzwerkadresse für ein mit dem Netzwerk verbundenes Gerät. Jede IP-Adresse muss innerhalb des Netzwerks eindeutig sein. Im Kontext von Websites ist das Netzwerk meistens das gesamte Internet.

Es gibt zwei Arten von IP-Adressen:

• • IPv4: Dies ist die gebräuchlichste Form einer IP-Adresse. Sie wird als eine Gruppe von vier Zahlen geschrieben, wobei jede Gruppe bis zu 3 Ziffern hat. Jede Gruppe ist durch einen Punkt getrennt. Der Bereich von IPv4 reicht von 0.0.0.0 bis 255.255.255.255.

  • IPv6: Es ist ein modernerer Standard, der entwickelt wurde, um das Problem der Erschöpfung von IPv4-Adressen. IPv4 unterstützt bis zu 232 eindeutige Adressen, während IPv6 bis zu 2128 Adressen unterstützt. Jede IPv6-Adresse wird in Hexadezimalziffern geschrieben. Sie kann bis zu 32 Ziffern enthalten, die in 8 Abschnitte (jeweils 4 Ziffern) unterteilt sind. Jeder Abschnitt ist durch einen Doppelpunkt (:) getrennt.

Top-Level-Domain

Eine Top-Level-Domain (kurz TLD) ist der allgemeinste Teil der Domain. Sie bezieht sich auf den am weitesten rechts stehenden Teil (durch einen Punkt getrennt). Einige der gängigen Top-Level-Domains sind:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

In Bezug auf Domainnamen stehen diese Domains an der Spitze der Hierarchie. Die ICANN (Internet Corporation for Assigned Names and Numbers) kann bestimmten Parteien die Erlaubnis zur Kontrolle über Top-Level-Domains erteilen. Mit dieser Erlaubnis können diese Parteien Domainnamen unter der TLD verteilen (normalerweise über einen Domain-Registrar).

• Hosts

Innerhalb der Domain kann der Eigentümer einzelne Hosts angeben, die sich auf separate Maschinen/Dienste beziehen, die über eine Domain zugänglich sind. Beispielsweise ist es gängige Praxis, die Webserver über die reine Domain zugänglich zu machen ( example.com) und die “Host”-Definition “www  ( www.example.com).

Es ist möglich, zusätzliche Hosts unter der allgemeinen Domain zu haben, zum Beispiel einen API-Zugriff über den “api”-Host ( api.example.com), einen FTP-Zugriff über den “ftp”- oder “files”-Host ( ftp.example.com oder files.example.com).

Beachten Sie, dass die Domainnamen beliebig sein dürfen, solange sie innerhalb der Domain eindeutig sind.

• Subdomain

Eine Subdomain ist ein Thema, das mit Hosts zusammenhängt. Das DNS funktioniert in einer Hierarchie. Eine TLD kann viele Domains unter sich haben. Zum Beispiel “ example.com”, “ cloudsigma.com” usw. befinden sich alle unter der TLD “com”. In dieser Hinsicht ist eine Subdomain ein Verweis auf jede Domain, die Teil der Ziel-Domain ist. Somit können wir sagen, dass “example.com” eine Subdomain von “com” ist. Im Allgemeinen wird der Teil “example” als SLD (Second-Level-Domain) bezeichnet.

Ebenso kann eine Domain alle darunter liegenden “Subdomains” kontrollieren. Dies ist normalerweise das, worauf sich “Subdomain” bezieht. Zum Beispiel “ history.example.com” ist eine Subdomain von “ example.com”.

Der Hauptunterschied zwischen einem Hostnamen und einer Subdomain besteht darin, dass ein Host einen Computer/eine Ressource definiert, während eine Subdomain die übergeordnete Domain erweitert. Wann immer wir über Subdomains oder Hosts sprechen, können Sie sich vergewissern, indem Sie auf den am weitesten links stehenden Teil einer Domain schauen, da dieser am spezifischsten ist. So funktioniert das DNS: vom spezifischsten (ganz links) zum am wenigsten spezifischen (ganz rechts).

• Vollständig qualifizierter Domainname

Ein vollständig qualifizierter Domainname (kurz FQDN) bezieht sich auf einen absoluten Domainnamen. Im DNS-System können Domains relativ zueinander angegeben werden. Dies kann zu Unklarheiten führen. Ein FQDN ist jedoch ein absoluter Name, der sich auf den absoluten Stamm (Root) des Domainnamensystems bezieht.

Das bedeutet, dass der FQDN jede übergeordnete Domain einschließlich der TLD angibt. Ein passendes Beispiel wäre “ mail.google.com”. In bestimmten Fällen endet der FQDN möglicherweise nicht mit einem Punkt, aber er muss einen abschließenden Punkt haben (erforderlich nach den ICANN-Standards).

• Nameserver

Ein Nameserver ist ein dedizierter Computer zur Übersetzung von Domainnamen in IP-Adressen. Nameserver tragen die meiste Last im DNS-System. Da die Gesamtzahl der Anfragen zur Domainübersetzung zu hoch ist, um von einem einzelnen Server bewältigt zu werden, werden die Anfragen oft an andere Nameserver weitergeleitet, um den Druck auszugleichen.

Ein Nameserver kann “autoritativ” sein, was bedeutet, dass er nur Antworten auf Anfragen zu Domains gibt, die unter seiner Kontrolle stehen. Solche Server können die Anfrage an andere Nameserver weiterleiten oder eine zwischengespeicherte Kopie der Daten anderer Nameserver bereitstellen.

• Zonendatei

Eine Zonendatei ist eine Textdatei, die die Zuordnungen zwischen Domainnamen und IP-Adressen enthält. Sie dient als Datenbank des DNS-Systems. Dies ist das Verzeichnis, das DNS verwendet, um herauszufinden, welche IP-Adresse kontaktiert werden muss, wenn eine Benutzeranfrage für einen bestimmten Domainnamen ausgeführt wird.

Im Allgemeinen hosten die Nameserver die Zonendateien und definieren die unter einer einzelnen Domain verfügbaren Ressourcen. Sie können auch Informationen darüber enthalten, wohin man sich wenden muss, um diese Informationen zu erhalten.

• Einträge

Eine Zonendatei umfasst zahlreiche Einträge. Hier ist ein Eintrag als eine einzelne Zuordnung zwischen einer Ressource und einem Namen definiert. Einträge können die Zuordnung eines Domainnamens zu einer IP-Adresse sein, Ressourcen, die unter einer bestimmten Domain verfügbar sind, oder Verweise auf Orte, an denen man die Informationen erhält.

DNS in Aktion

Bisher haben wir uns mit einigen gängigen Begriffen im Zusammenhang mit DNS vertraut gemacht. Aber wie funktioniert das System eigentlich? Auf hoher Ebene mag das System sehr einfach erscheinen. Wenn man jedoch tiefer in die Details einsteigt, offenbart sich seine wahre Komplexität. Insgesamt ist das DNS-System wichtig für die breite Akzeptanz des Internets.

• Root-Server

DNS funktioniert im Kern in einer Hierarchie. An der Spitze des Systems befinden sich die “Root-Server”. Diese Server stehen unter der Kontrolle verschiedener Organisationen. Die Autorität dieser Server wird von der ICANN (Internet Corporation for Assigned Names and Numbers) delegiert.

Derzeit sind etwa 13 Root-Server in Betrieb. Aufgrund der Last ist jedoch jeder dieser Server gespiegelt. Es ist wichtig zu beachten, dass alle Mirror-Server dieselbe IP-Adresse wie der Root-Server haben. Wann immer eine Anfrage an den Root-Server gestellt wird, wird die Anfrage an den nächstgelegenen Mirror dieses Servers weitergeleitet.

Was sind die Aufgaben der Root-Server? Sie liefern Informationen über Top-Level-Domains. Wann immer ein Nameserver auf niedrigerer Ebene eine Anfrage nicht auflösen kann, wird sie an den Root-Server der Domain weitergeleitet.

Der Root-Server kennt jedoch nicht die tatsächliche Position der Domain. Er leitet lediglich die Anfrage weiter, die die speziell angeforderte Top-Level-Domain verarbeitet. Wenn beispielsweise eine Anfrage für “ blog.cloudsigma.com” gestellt wird, hat der Root-Server dies nicht in seinen Einträgen. Er wird seine Zonendateien durchsuchen, aber es wird keinen Eintrag dafür geben. Stattdessen erkennt er die TLD “com” und leitet die anfragende Stelle an den Nameserver weiter, der für “com”-Adressen zuständig ist.

• TLD-Server

Anknüpfend an unser vorheriges Beispiel sendet die anfragende Stelle nun die Anfrage an die IP-Adresse (die vom Root-Server bereitgestellt wurde). Im Fall von “ blog.cloudsigma.com”, durchsucht der “com”-Nameserver seine Einträge in seinen Zonendateien.

Es wird keinen Eintrag geben, der der Anfrage entspricht. Er wird jedoch einen Eintrag finden, der die IP-Adresse des Nameservers auflistet, der verantwortlich ist für “ cloudsigma.com”.

• Nameserver auf Domain-Ebene

Nun verfügt die anfragende Stelle über die IP-Adresse des Nameservers, der tatsächlich die Informationen über “ blog.cloudsigma.com” hostet. Sie wird nun eine neue Anfrage an den Server senden und darum bitten, “www.cloudsigma.com” aufzulösen.

Wie zuvor überprüft der Nameserver seine Zonendateien und findet diejenige, die mit “ cloudsigma.com” verknüpft ist. In dieser Datei befindet sich ein Eintrag für den Host “www”. Dieser Eintrag beschreibt, wo sich der Host befindet. Die endgültige Antwort wird dann an die anfragende Stelle weitergeleitet.

• Auflösender Nameserver

In dem Beispiel haben wir eine anfragende Stelle erwähnt. Was ist das? In den meisten Fällen ist der Anfragende ein “auflösender Nameserver”. Das ist ein Server, der so konfiguriert ist, dass er Anfragen an andere Server stellt. Er fungiert als Vermittlungsserver für Benutzer. Er speichert die Ergebnisse im Cache, um die Geschwindigkeit zu verbessern.

Jeder Benutzer hat in der Regel ein paar auflösende Nameserver auf seinem System konfiguriert. Im Allgemeinen werden die auflösenden Nameserver vom ISP oder anderen Organisationen bereitgestellt. Zum Beispiel bietet Google öffentliche auflösende DNS-Server für Abfragen an. Sie können diese manuell auf Ihrem System konfigurieren.

Wenn Sie eine URL in den Webbrowser eingeben, sucht dieser nach dem Speicherort der Ressource. Zuerst wird die Suche lokal durchgeführt. Dies schließt die “hosts”-Datei (und einige andere Orte) ein. Wenn sie dort nicht gefunden wird, wird die Anfrage an den auflösenden Nameserver gesendet. Nach Erhalt der Anfrage durchsucht der auflösende Nameserver seinen Cache nach der Antwort. Wenn sie nicht gefunden wird, durchläuft er die zuvor erwähnten Schritte.

Auflösende Nameserver vereinfachen den Anfrageprozess für den Endbenutzer. Der Client muss lediglich die auflösenden Nameserver nach dem Speicherort einer Ressource fragen. Der Nameserver führt die Recherche durch und liefert die endgültige Antwort.

• Zonendateien

Wir haben bereits die Konzepte von “Zonendateien” und “Einträgen” besprochen. Wie funktionieren sie nun?

Zonendateien fungieren als Datenbank für die Nameserver und speichern die Informationen über die Domains, die sie kennen. Alle Domains, die ein Nameserver kennt, werden in seiner Zonendatei gespeichert. Die meisten Anfragen, die an einen Nameserver gerichtet werden, werden jedoch nicht durch die Zonendatei aufgelöst. Wenn die Serverkonfiguration so ausgelegt ist, dass sie rekursive Abfragen verarbeitet (z. B. auflösende Nameserver), gibt er die Antwort zurück. Andernfalls leitet er die anfragende Partei an eine andere Stelle weiter, an der sie als Nächstes suchen kann.

Je mehr Zonendateien ein Nameserver hostet, desto autoritativer sind seine Antworten. Zonendateien beschreiben eine DNS-“Zone” (eine Teilmenge des gesamten DNS-Namenssystems). Im Allgemeinen enthält eine Zonendatei die Konfigurationsdaten von nur einer einzigen Domain. Sie kann zahlreiche Einträge enthalten, die den Speicherort der Ressourcen der betreffenden Domain definieren.

Der $ORIGIN-Parameter einer Zone entspricht der höchsten Autoritätsstufe der Zone. Beispielsweise hat eine Zonendatei für “ cloudsigma.com” hat ihren $ORIGIN als “ cloudsigma.com”. Der Wert des Parameters kann am Anfang der Zonendatei oder in der Konfiguration des DNS-Servers gespeichert werden. In jedem Fall beschreibt der Parameter, für welche Zone die Datei autoritativ ist.

Der $TTL -Parameter legt die “Time to Live”-Information des bereitgestellten Ergebnisses fest. Er kann als ein Timer beschrieben werden, den ein Caching-Server verwenden kann, um die Gültigkeit der zwischengespeicherten Antworten zu verfolgen. Wenn der TTL-Wert abläuft, ist die Antwort nicht mehr gültig und wird verworfen.

• Eintragstypen

Die Zonendateien bestehen aus zahlreichen Einträgen. Es gibt verschiedene Arten von Einträgen. Als Nächstes werden wir einige der gängigsten (und obligatorischen) Eintragstypen durchgehen:

SOA-Einträge

Der Start of Authority-Eintrag (kurz SOA) ist in allen Zonendateien obligatorisch. Er muss der erste echte Eintrag in der Datei sein. Einträge wie $ORIGIN oder $TTL dürfen jedoch vorher erscheinen.

Der SOA-Eintrag ist einer der komplexeren Eintragstypen. Seine Struktur sieht in etwa so aus:

Lassen Sie es uns aufschlüsseln:

• • example.com: Dieser Teil definiert den Stamm (Root) der Zone. In diesem Beispiel ist die Zonendatei für die Domain “ example.com”. Manchmal kann der Wert durch @ ersetzt werden (ein Platzhalter, um den Wert von $ORIGIN).

  • IN SOA: Der Begriff “IN” steht für “Internet”. Sie werden ihn in vielen Einträgen finden. Der Begriff “SOA” zeigt an, dass es sich um einen SOA-Eintrag handelt.

  • ns1.example.com: Dieser Wert enthält den primären Nameserver für die Domain “ example.com”. Nameserver können entweder primär oder sekundär sein. Wenn sie mit dynamischem DNS konfiguriert wurden, muss es einen “primären” Server geben. Wenn kein dynamisches DNS konfiguriert wurde, ist es einer der primären Nameserver.

  • admin.example.com: Hier wird die E-Mail-Adresse des Zonen-Admins eingetragen. Beachten Sie, dass das @ hier durch . ersetzt wird. Wenn die ursprüngliche E-Mail-Adresse einen Punkt enthält, wird dieser durch ein \ ersetzt. Zum Beispiel würde “ my.domain@example.com” zu “ my\domain.example.com”.

  • 12083: Dies ist die Seriennummer der Zonendatei. Jedes Mal, wenn die Zonendatei bearbeitet wird, muss die Nummer aktualisiert werden, damit die Datei ordnungsgemäß verteilt wird. Sekundäre Server verwenden diese Seriennummer, um zu verfolgen, ob ihre eigenen Zonendateien auf dem neuesten Stand sind.

  • 3h: Dies stellt das Aktualisierungsintervall (Refresh-Intervall) für die Zone dar. Sekundäre Server warten diese Zeitspanne ab, bevor sie nach Aktualisierungen der Zonendatei suchen.

  • 30m: Dieser Wert stellt das Wiederholungsintervall (Retry-Intervall) der Zone dar. Wenn ein sekundärer Server nach Ablauf des Aktualisierungsintervalls keine Verbindung zum primären Server herstellen kann, wartet er diese Zeitspanne, bevor er den primären Server erneut abfragt.

  • 3w: Dieser Wert stellt die Ablaufzeit (Expiry-Zeit) dar. Wenn ein sekundärer Server über diesen Zeitraum hinweg keine Verbindung zum primären Server herstellen kann, gibt er keine Antworten mehr als “autoritativ” zurück.

  • 1h: Dieser Wert stellt die Zeitspanne dar, für die der Nameserver einen Namensfehler (Name Error) zwischenspeichert, wenn dieser in seiner Zonendatei nicht gefunden wurde.

A- und AAAA-Einträge

Diese Einträge stellen eine Zuordnung zwischen einem Host und einer IP-Adresse her. Hierbei kennzeichnet der “A”-Eintrag die IPv4-Zuordnung zum Host und AAAA die IPv6-Zuordnung.

Dies ist die grundlegende Struktur der A- und AAAA-Einträge:

Im Beispiel des SOA-Eintrags haben wir den Nameserver “ ns1.exampel.com” genannt. Der Nameserver fällt unter die Domain “ example.com”. So würde sein A-Eintrag aussehen:

Beachten Sie, dass wir nicht den vollständigen Namen angeben mussten. Mit nur dem Hostnamen (ohne den FQDN) kann der DNS-Server den Rest mit dem Wert aus $ORIGIN ausfüllen. Wir können jedoch weiterhin den FQDN verwenden:

Hier ist, wie Sie den Webserver als “www” definieren:

Wir sollten auch die Zuordnung zur Basis-Domain einbeziehen. Der Eintrag würde so aussehen:

Alternativ können wir das @ Symbol verwenden, um die Basis-Domain zu bezeichnen (anstelle ihres vollständigen Namens):

Es ist eine gute Praxis, einen Wildcard-Eintrag aufzunehmen, der die Option aktiviert, alles unter dieser Domain aufzulösen, was nicht explizit definiert wurde:

Die gleiche Struktur gilt für AAAA-Records. Der einzige Unterschied sind die IPv6-Adressen.

CNAME-Records

CNAME-Records fungieren als Alias für den kanonischen Namen des Servers (definiert durch einen A- oder AAAA-Record). Sehen Sie sich das folgende Beispiel an:

Hier haben wir “server1” als Alias zur Definition des Namens “www” verwendet. Beachten Sie, dass solche Abkürzungen mit Leistungseinbußen verbunden sind, da der Server zusätzliche Abfragen ausführen muss, um die endgültige Antwort zu erhalten. Je nach Anzahl der Alias-Ebenen kann dies leicht zu erheblichen Leistungseinbußen führen. Es gibt jedoch einen spezifischen Fall, der von CNAME-Aliasing profitiert, beispielsweise die Bereitstellung einer Ressource außerhalb der aktuellen Zone.

MX-Records

MX-Records definieren die Mail-Server für die Domain. Sie helfen dabei, dass E-Mails korrekt am Server ankommen. Im Gegensatz zu anderen Records ordnen MX-Records einen Host nicht direkt zu, da sie für die gesamte Zone gelten. Aus diesem Grund sehen MX-Records in etwa so aus:

Beachten Sie, dass am Anfang des Eintrags kein Hostname steht. Sie werden auch feststellen, dass sich in der Zeile ein zusätzlicher Wert befindet. Es ist die Prioritätsnummer, die bei der Entscheidung hilft, an welchen Server die E-Mail gesendet werden soll (falls mehrere Mail-Server definiert sind). Je niedriger die Nummer, desto höher die Priorität.

Ein MX-Record sollte auf einen Host verweisen, der durch einen A- oder AAAA-Record definiert ist (nicht durch einen CNAME). Wenn zwei Mail-Server konfiguriert sind, würden die Records wie folgt aussehen:

In diesem Beispiel ist “mail1”, gemessen an der Prioritätsnummer, der bevorzugte Server gegenüber “mail2”. Wir können den Code weiter verkürzen, indem wir den vollständigen Domainnamen weglassen:

NS-Records

Diese Records definieren die Nameserver für die jeweilige Zone. Nun stellt sich die offensichtliche Frage: Wenn sich die Zonendatei auf dem Nameserver befindet, warum benötigt sie dann einen Verweis auf sich selbst? Eine Antwort auf diese Frage sind die vielfältigen Caching-Mechanismen des DNS-Systems. Die Zonendatei kann tatsächlich eine zwischengespeicherte Kopie auf anderen Servern sein.

Ähnlich wie die MX-Records gelten die NS-Records für die gesamte Zone. Daher haben sie standardmäßig keinen spezifischen Host. NS-Record-Einträge sehen in etwa so aus:

Es wird empfohlen, zwei Nameserver zu definieren, falls ein Server nicht ordnungsgemäß funktioniert. Darüber hinaus lehnen die meisten DNS-Server eine Zonendatei ab, wenn sie nur einen einzigen Nameserver enthält.

Sie sollten auch die Zuordnung der Hosts mit A- oder AAAA-Records einbeziehen:

PTR-Records

PTR-Records sind das Gegenteil eines klassischen A- oder AAAA-Records. Diese Records werden verwendet, um einen Namen zu definieren, der einer IP-Adresse zugeordnet ist. Diese Records haben eine einzigartige Eigenschaft, da sie an der .arpa -Root beginnen und den Eigentümer der IP-Adresse darstellen. Es sind die RIRs (Regional Internet Registries), die IP-Adressen an Organisationen und Dienstanbieter verteilen. Zu den RIRs gehören APNIC, AFRINIC, LACNIC, RIPE NCC und ARIN.

Ein PTR-Record für beispielsweise 111.222.333.444 würde ungefähr so aussehen:

Werfen Sie im nächsten PTR-Record-Beispiel einen Blick auf den IPv6-DNS-Server von Google 2001:4860:4860::8888:

Wir können das dig-Tool mit dem Flag -x verwenden, um den Reverse-DNS-Namen einer IP-Adresse nachzuschlagen. Sehen Sie sich beispielsweise die Reverse-DNS-IP-Adresse von 8.8.4.4:

Internet-Server verwenden PTR-Records, um Domainnamen in Protokolleinträgen zu verfolgen, fundierte Entscheidungen zur Spam-Behandlung zu treffen und leicht lesbare Informationen über andere Geräte anzuzeigen.

Häufig verwendete E-Mail-Server schlagen den PTR-Record der IP-Adresse nach, von der die E-Mail gesendet wurde. Wenn der PTR-Record leer ist, besteht eine hohe Wahrscheinlichkeit, dass es sich bei der E-Mail um Spam handelt (und sie somit abgelehnt wird). Beachten Sie, dass eine Übereinstimmung zwischen dem FQDN und dem Domainnamen des PTR-Records nicht das Problem ist. Der wichtige Faktor ist, ob ein gültiger PTR-Record mit einem übereinstimmenden und entsprechenden Forward-A-Record verknüpft ist.

Im Allgemeinen haben Netzwerk-Router im Internet PTR-Records, die ihrem physischen Standort entsprechen. Beispielsweise sind “NYC” oder “CHI” gültige Referenzen für Router in New York und Chicago. Diese Technik ist nützlich, wenn Sie ein Traceroute oder MTR durchführen und den Pfad überprüfen, den die Pakete nehmen.

CAA-Records

Diese Records legen die CAs (Certificate Authorities) fest, die SSL/TLS-Zertifikate für Ihre Domain ausstellen dürfen. Seit dem 8. September 2017 müssen alle CAs die CAA-Records überprüfen, bevor sie ein Zertifikat ausstellen. Wenn kein CAA-Record existiert, darf jede CA ein Zertifikat ausstellen. Andernfalls dürfen nur bestimmte CAs Zertifikate ausstellen. CAA-Records können entweder auf einzelne Hosts oder auf eine gesamte Domain angewendet werden.

Hier ist ein Beispiel für einen CAA-Record:

Der CAA-spezifische Teil des Eintrags ist 0 issue "letsencrypt.org". Dieser Teil besteht aus drei Komponenten:

• Flags: Dies ist ein ganzzahliger Wert, der angibt, wie eine CA mit Tags umgehen soll, die sie nicht versteht. Wenn der Flag-Wert auf 0 gesetzt ist, wird der Record ignoriert. Wenn der Wert 1 ist, muss die CA die Ausstellung des Zertifikats verweigern.
• Tags: Dies sind Zeichenketten, die den Zweck eines CAA-Records angeben. Derzeit gehören zu den gültigen Werten issue (Autorisierung einer CA zur Ausstellung von Zertifikaten für eine bestimmte Domain), issuewild (Autorisierung von Wildcard-Zertifikaten) und iodef (Definition einer URL, an die CAs Richtlinienverstöße melden).
• Werte: Dies sind Zeichenketten, die mit dem Tag des Records verknüpft sind. Wenn das Tag issue oder issuewild ist, ist der Wert normalerweise die Domain der CA, der Sie die Erlaubnis erteilen. Wenn das Tag iodef ist, handelt es sich um eine URL eines Kontaktformulars oder einen mailto: Link für E-Mail-Feedback.

Wir können das dig-Tool verwenden, um die CAA-Records abzurufen:

Weitere ausführliche Informationen zu CAA-Records finden Sie unter RFC 6844.

Fazit

Diese Anleitung beschreibt verschiedene DNS-bezogene Begriffe. Sie beschreibt auch, wie alle Komponenten zusammenwirken. Mit diesem gründlichen Überblick sollten Sie ein gutes Verständnis für die Funktionsweise des DNS-Systems haben. Während die Grundidee einfach und leicht zu verstehen ist, werden die Feinheiten sehr schnell komplex. Für unerfahrene Administratoren kann es schwierig sein, diese Konzepte und Strategien anzuwenden.

Sind Sie CloudSigma-Kunde? Dann schauen Sie sich die Verwaltung und Aktualisierung von Reverse-DNS/PTR-Einträgen für Ihre CloudSigma-Infrastruktur.

Viel Spaß beim Computing!