Allgemeine DNS-Übersicht

Diese Seite bietet eine Übersicht über das Domain Name System (DNS).

Eine Übersicht über Cloud DNS finden Sie unter Cloud DNS – Übersicht.

Allgemeine DNS-Konzepte

DNS ist eine hierarchische verteilte Datenbank, in der IP-Adressen und andere Daten gespeichert werden und die Abfragen nach Namen ermöglicht.

Anders ausgedrückt ist DNS ein Verzeichnis mit leicht lesbaren Domainnamen, die in numerische IP-Adressen übersetzt werden, die von Computern zur Kommunikation untereinander verwendet werden. Wenn Sie beispielsweise eine URL in einen Browser eingeben, wandelt DNS die URL in eine IP-Adresse eines Webservers um, die diesem Namen zugeordnet ist. Die DNS-Verzeichnisse werden weltweit auf regelmäßig aktualisierten Domainnameservern gespeichert und verteilt.

Die folgenden Konzepte sind für die Arbeit mit DNS nützlich.

DNS-Servertypen

Ein DNS-Server speichert eine Datenbank mit Domainnamen und verarbeitet Domainnamen auf der Grundlage von DNS-Abfragen eines Clients in einem Netzwerk.

Autoritativer Server
Ein autoritativer Server ist ein Server, der die DNS-Namenseinträge wie A, AAAA, CNAME usw. enthält. Ein nicht autoritativer Server erstellt eine Cache-Datei auf der Grundlage vorheriger Abfragen für Domains. Er speichert nicht die ursprünglichen Namenseinträge.
Rekursiver Resolver

Ein rekursiver Resolver ist ein Server, der eine Anfrage zur Auflösung an den autoritativen oder nicht autoritativen Server sendet. Der Begriff des rekursiven Resolvers bezieht sich darauf, dass er jede Abfrage für einen bestimmten Namen ausführt und das Endergebnis zurückgibt. Im Gegensatz dazu gibt ein iterativer Resolver nur einen Verweis auf die nächsten DNS-Server zurück, die die Antwort eventuell liefern können.

Wenn Sie beispielsweise den Namen "google.com." auflösen, muss der rekursive Resolver zuerst bestimmen, wer für "." (die Root-Zone des DNS) autoritativ ist. Anschließend werden die Nameserver danach abgefragt, wer für ".com." autoritativ ist. Schließlich werden diese Nameserver danach abgefragt, wer für "google.com." autoritativ ist, und die RDATA-Daten für den A-Eintrag werden an den Client zurückgegeben.

Im Folgenden finden Sie ein Beispiel für die Anwendung eines rekursiven Resolvers. Wenn Sie dig +trace google.com eingeben, führt der rekursive Resolver die folgende Aktion aus (8.8.8.8/Google Public DNS ist ein solcher Resolver):

dig +trace google.com
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +trace google.com
;; global options: +cmd
.           168383  IN  NS  a.root-servers.net.
.           168383  IN  NS  b.root-servers.net.
.           168383  IN  NS  c.root-servers.net.
.           168383  IN  NS  d.root-servers.net.
.           168383  IN  NS  e.root-servers.net.
.           168383  IN  NS  f.root-servers.net.
.           168383  IN  NS  g.root-servers.net.
.           168383  IN  NS  h.root-servers.net.
.           168383  IN  NS  i.root-servers.net.
.           168383  IN  NS  j.root-servers.net.
.           168383  IN  NS  k.root-servers.net.
.           168383  IN  NS  l.root-servers.net.
.           168383  IN  NS  m.root-servers.net.
.           168383  IN  RRSIG   NS 8 0 518400 20190810170000 20190728160000 59944 .
ITqCp5bSKwoG1P76GpNfDanh4fXxOtHuld5SJzEm9ez0U/K7kpmBm4TE
cw82zuqtZlqiGOuq+90KHJEhD1fdX3FujgDqe3kaY/41LgFIo76RBeMP
CorYg29lKQOBf7pLPiJWewFmnLsRXsvENzxNXl9mynX80EQSS2YlCWpr
47i2j5SFpGDzmxls7LinB4VvwVLhy0FPwBaVc5NVqQoFS5ZkfKXCUz8x
urExPT2OtPJeDiGzrQGmT6vDbYZtJRWWGK5tPIKZQyF/08YSJlrjebNa
1nKZVN8SsO8s7elz6JGmdoM6D/1ByLNFQmKvU55ikaVSnXylqixLbJQI 7LyQoA==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 22 ms

com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            86400   IN  DS  30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400   IN  RRSIG   DS 8 1 86400 20190811170000 20190729160000 59944 .
KXPRdZspxd6hZYRFx3cj7Yp3d6HDzOG5CmoK46ZrrlKnZkCYMPKzyFQ2
15pA+jZ37MbQbhe6+S+C4AHWqv95DDsue85ha3ZmWGhnJxcLnDaL5Twp
Z/W/a+1cTHhhbMZua1riw74mqvzRAF1kVerj7jrvWnOAOZCh69Dr4AFJ
gRN4MAn+wCZDmPQCtkcGVJ9vyNV7Xra45B4ISqEo0xi8CXewp9cc+aW5
TSjFRhj1RM9d3k+3Mrq6AAV8dVgWofYTg6Ihph/SfoIx4TrTrEbgfdsv
MvuLPXvK6Y7oSh5WknbFduw7HQdo1jH3/QR54FORswBJT8VmYD7Zii88 tAjbRQ==
;; Received 1170 bytes from 192.58.128.30#53(j.root-servers.net) in 2 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 -
CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2
86400 20190803044434 20190727033434 17708 com.
rMmiNL7bYvJpB3Bc+WnqS2iiczm2PwxBvJcl7SL/vcTj88GsxM1ycTSV
PsHZHxfrv1dv2C5BCSZ+mzeVBu8upLoeraQy+UVf3VXyt3i3rNGzcXYV
8HSrHcXrRoAJopFim3Ge1xdZ+uERg3cTIcN2tJxxkCeqt/EcUTqtQl8t EAc=
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN NSEC3 1 1 0 -
S84CFH3A62N0FJPC5D9IJ2VJR71OGLV5 NS DS RRSIG
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN RRSIG NSEC3
8 2 86400 20190804045723 20190728034723 17708 com.
jypPsaWVop9rzuf70CFYyiK0hliiJ+YYtkjgb3HVj9ICc57kLmv9DkvG
DddF5GBQpqNEakzyJtya179MAdDT7RhJB4XfmY6fu5I5QTeIjchfP5wt
7gU1AL7cqTmBAo2RWu62vtUytV09+O3KGFq5O+Cwr11dSTfq1yYyw6YW cMI=
;; Received 772 bytes from 192.41.162.30#53(l.gtld-servers.net) in 2 ms

google.com.     300 IN  A   172.217.7.14
;; Received 55 bytes from 216.239.32.10#53(ns1.google.com) in 13 ms

Jeder DNS-Client fragt einen Nameserver ab. Ein rekursiver Resolver fragt andere Nameserver gegebenenfalls bis hin zu einem übergeordneten Nameserver ab. Der NS-Eintrag für eine Zone auf einem übergeordneten Nameserver leitet den Resolver zur nächsten Ebene nach "unten" zu einem anderen Nameserver, bis er schließlich entweder einen Nameserver erreicht, der die Zone zwischenspeichert, oder einen autoritativen Server für die Zone.

Zonen

Öffentliche Zonen
Eine öffentliche Zone ist im Internet sichtbar. Zum Veröffentlichen Ihres Dienstes im Internet können Sie DNS-Einträge in einer öffentlichen Zone erstellen. Beispielsweise haben Sie die Möglichkeit, einen A-Eintrag in einer öffentlichen Zone mit dem Namen example.com. für Ihre öffentliche Website www.example.com. anzulegen.
Private Zonen
Eine private Zone ist eine Zone, die nicht über das öffentliche Internet abgefragt werden kann.
Delegierte Subzonen
Mit DNS können Inhaber einer Zone eine Subdomain mithilfe von NS-Einträgen an einen anderen Nameserver delegieren. Resolver folgen dann diesen Einträgen und senden Abfragen für die Subdomain an den in der Delegierung angegebenen Ziel-Nameserver.
Split-Horizon-DNS
Der Begriff "Split Horizon" beschreibt Situationen, in denen zwei Zonen für dieselbe Domain erstellt werden – eine Zone für das interne Netzwerk und eine Zone für das externe Netzwerk, in der Regel das Internet. Mit dem Split-Horizon-DNS können Sie unterschiedliche Antworten, also unterschiedliche Ressourcendatensätze, für ein und denselben Namen bereitstellen, je nachdem, wer abfragt. So haben Sie beispielsweise die Möglichkeit, die Entwicklungs-/Staging-Version Ihrer Anwendung bereitzustellen, wenn die Abfrage aus dem Entwicklungsnetzwerk stammt, und die Produktions-/öffentliche Version Ihrer Anwendung, wenn die Abfrage aus dem öffentlichen Internet kommt.

Einträge

Ein Eintrag ist eine Zuordnung zwischen einer DNS-Ressource und einem Domainnamen. Jeder einzelne DNS-Eintrag hat einen Typ (Name und Nummer), eine Ablaufzeit (Gültigkeitsdauer TTL) und typspezifische Daten. Einige der am häufigsten verwendeten Eintragstypen sind im Folgenden aufgeführt:

  • A: Adresseintrag, der Hostnamen ihrer IPv4-Adresse zuordnet.
  • AAAA: IPv6-Adresseintrag, der Hostnamen ihrer IPv6-Adresse zuordnet.
  • CNAME: Canonical-Name-Eintrag (kanonischer Name) zur Angabe von Aliasnamen.
  • MX: Mail-Exchange-Eintrag für die Weiterleitung von Anfragen an Mailserver.
  • NS: Nameserver-Eintrag, mit dem eine DNS-Zone an einen autoritativen Server delegiert wird.
  • PTR: Pointer-Eintrag, der einen Namen definiert, der einer IP-Adresse zugeordnet ist.
  • SOA: Start-of-Authority-Eintrag, mit dem der für eine Zone zuständige primäre Nameserver und Administrator festgelegt werden. Jede Zone, die auf einem DNS-Server gehostet wird, muss einen SOA-Eintrag (Start of Authority) haben. Der Eintrag lässt sich nach Bedarf anpassen. Zum Beispiel können Sie für eine datumsbasierte Versionsverwaltung die Seriennummer in eine beliebige Zahl ändern.

Datensätze

Einträge mit dem gleichen Namen und mit dem gleichen Typ, aber mit unterschiedlichen Datenwerten werden Datensätze genannt.

Wenn beim Erstellen eines Eintrags ein Satz mit dem gleichen Namen und Typ vorhanden ist, wird der Eintrag diesem übereinstimmenden Satz hinzugefügt. Ist kein übereinstimmender Eintrag vorhanden, wird ein neuer Eintrag erstellt und der Liste mit Datensätzen hinzugefügt.

Im Folgenden finden Sie ein Beispiel für einen Datensatz mit mehr als einem Eintrag mit dem gleichen Namen und Typ:

DNS-Name Typ TTL (Sekunden) Daten
db-01.dev.gcp.example.com A 50 10.128.1.35
db-01.dev.gcp.example.com A 50 10.128.1.10

Eine Liste der unterstützten Eintragstypen in Cloud DNS finden Sie unter Unterstützte DNS-Eintragstypen.

Delegierung von Subdomains

Achten Sie beim Erstellen von Einträgen darauf, dass die NS- und SOA-Einträge übereinstimmen. Unterschiedliche NS- und SOA-Einträge können dazu führen, dass einige Resolver die Delegierung als ungültig ablehnen und Antworten vom Typ "KEINE DATEN" auf Abfragen nicht im Cache speichern. Dies kann zu einer großen unerwarteten Anzahl an Abfragen Ihrer öffentlichen verwalteten Zonen durch rekursive Resolver von Drittanbietern führen, wenn Resolver Ihre öffentlichen verwalteten Zonen nach Einträgen abfragen, die nicht vorhanden sind.

Beispiel: Angenommen, es gibt die beiden Subdomains example.com und subdomain.example.com. Die NS- und SOA-Einträge für subdomain.example.com stimmen nicht überein und keine Zone enthält AAAA-Einträge. Wenn einige rekursive Resolver von Drittanbietern subdomain.example.com für einen AAAA-Eintrag abfragen und daraufhin eine Antwort vom Typ "KEINE DATEN" erhalten und die Resolver gleichzeitig eine ungültige Delegierung von subdomain.example.com ermitteln, wird das Fehlen von AAAA-Einträgen in dieser Zone nicht zwischengespeichert. Im Ergebnis werden die Abfragen dann wiederholt. Alle Cloud Console-Nameserver werden nacheinander nach diesen Informationen abgefragt.

Registrator

Ein Domainnamenregistrator ist eine Organisation, die die Reservierung von Internetdomainnamen für öffentliche Zonen verwaltet. Ein Registrator muss von einer Registry für generische Top-Level-Domains (gTLD) oder einer Registry für länderspezifische Top-Level-Domains (ccTLD) akkreditiert sein. Auf diese Weise vereinbaren Nameserver auf einer höheren Ebene SOA-Einträge und aktualisieren NS-Einträge für die Zone, um Anfragen an Caching- oder autoritative Nameserver weiterzuleiten.

SOA-Seriennummer

Die SOA-Seriennummer ist eine Versionsnummer für eine DNS-Zone. Damit alle Nameserver die aktuelle Version einer Zone kennen, müssen sie dieselbe SOA-Seriennummer haben. Die Seriennummern von SOA-Einträgen, die in verwalteten DNS-Zonen erstellt wurden, werden mit jeder transaktionalen Änderung der Datensätze einer Zone monoton erhöht. Allerdings können Sie die Seriennummer eines SOA-Eintrags in eine beliebige Zahl ändern, einschließlich eines Datums im Format ISO 8601, wie in RFC 1912 empfohlen.

DNSSEC

Die Domain Name System Security Extension (DNSSEC) behebt Sicherheitslücken in Bezug auf DNS-Daten. Dies ist eine Zusammenstellung von IETF-Spezifikationen zur Authentifizierung von DNS-Daten, für die authentifizierte Abwesenheitsbestätigung und für die Datenintegrität für DNS-Clients (Resolver). Kurz gesagt bietet DNSSEC eine Möglichkeit, per Software den Ursprung von DNS-Daten zu prüfen und zu bestätigen, dass sie bei der Übertragung nicht geändert wurden.

Weitere Informationen zu DNSSEC finden Sie unter RFC 4033.

Eine Liste weiterer grundlegender DNS-Begriffe finden Sie unter RFC 7719.