DNS erklärt: Domain mit dem VPS verbinden

Was ist DNS, und warum Ihre Domain Ihren VPS noch nicht erreicht

DNS (Domain Name System) übersetzt einen Namen wie example.com in eine IP-Adresse (Internet Protocol) wie 203.0.113.10. Ein Browser kann keine Verbindung zu einem Namen herstellen. Er verbindet sich mit einer Adresse. Daher beginnt jeder Seitenaufruf mit einer DNS-Anfrage und einer Antwort. Wenn Sie gerade eine Domain und einen eigenen VPS gekauft haben und keine Inhalte geladen werden, trifft eine von zwei Bedingungen zu: Noch kein Datensatz verknüpft den Namen mit der Adresse Ihres Servers, oder ein solcher Datensatz ist vorhanden und irgendwo auf dem Weg wird noch eine ältere Antwort ausgegeben.

Beide Situationen sind normal. Keine davon bedeutet, dass etwas defekt ist. Die folgenden Abschnitte behandeln die einzelnen Bestandteile in der Reihenfolge, in der Sie ihnen begegnen. Wir beginnen mit dem Punkt, der am meisten Zeit kostet: Welches Control Panel verwaltet Ihre Datensätze tatsächlich?

Alle Prüfungen in diesem Abschnitt verwenden dig. Auf einer frisch installierten Ubuntu- oder Debian-Maschine ist es standardmäßig nicht installiert.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, Nameserver, DNS-Host: Wo bearbeiten Sie welchen Eintrag?

Diese drei Bezeichnungen stehen für unterschiedliche Aufgaben. Eine Verwechslung ist der häufigste Grund dafür, dass eine Änderung keine Wirkung zeigt.

• Der Registrar ist das Unternehmen, bei dem Sie die Domain gekauft haben. Seine wichtige Aufgabe ist die Delegation: Er teilt der Registry Ihrer TLD (Top-Level-Domain, der .com-Teil) mit, welche Nameserver für Ihre Domain autoritativ sind.
• Die autoritativen Nameserver enthalten die tatsächlichen Records Ihrer Zone. Eine Zone umfasst Ihre Domain und die darunterliegenden Namen.
• Der DNS-Host betreibt diese Nameserver. Das kann der Registrar, ein separater Anbieter oder bind9 auf einem von Ihnen betriebenen Server sein.

Sie kaufen die Domain beim Registrar. Sie bearbeiten die DNS-Einträge beim DNS-Host. Wenn Sie Ihre Domain auf die Nameserver eines anderen Anbieters umgestellt haben, zeigt das DNS-Panel des Registrars weiterhin eine Zone an, speichert Ihre Änderungen weiterhin, und niemand im Internet fragt diese Zone jemals ab. Die Records sind vorhanden. Sie werden lediglich nie abgefragt.

Ermitteln Sie, wo die Abfragen tatsächlich ankommen:

dig example.com NS +short
dig +trace example.com

Der erste Befehl gibt die Nameserver aus, die heute für die Domain antworten. Der zweite verfolgt die Kette ausgehend von den Root-Servern und gibt die Weiterleitung aus, die die TLD-Server übermitteln. Das ist die Delegation, die Ihr Registrar steuert. Wenn diese Namen zu einem Anbieter gehören, den Sie nicht erkennen, befindet sich das benötigte Panel bei diesem Anbieter.

Wie eine einzelne Abfrage weitergeleitet wird

Vier Instanzen sind beteiligt. Jede speichert eine Kopie der Informationen, die sie erhält.

1. Der Stub-Resolver auf Ihrem Rechner. Er führt keine Suche durch. Er fragt einen konfigurierten Server und vertraut auf die Antwort. Unter Ubuntu ist /etc/resolv.conf normalerweise ein symbolischer Link auf /run/systemd/resolve/stub-resolv.conf und bezeichnet 127.0.0.53, das als systemd-resolved lokal mit einem eigenen Cache ausgeführt wird.
2. Der rekursive Resolver. Das ist der Resolver Ihres Internetdienstanbieters (Internet Service Provider, ISP), ein öffentlicher Resolver wie 1.1.1.1 oder ein Resolver, den Sie selbst betreiben. Er ermittelt die Antwort tatsächlich.
3. Die Root- und TLD-Server. Der rekursive Resolver fragt einen Root-Server. Dieser kennt Ihre Adresse nicht, antwortet aber mit einer Weiterleitung an die .com-Server. Diese antworten mit einer Weiterleitung an Ihre Nameserver.
4. Der autoritative Nameserver. Er fragt keinen anderen Server. Er antwortet anhand Ihrer Zone und kennzeichnet die Antwort als autoritativ.

dig +trace example.com zeigt diesen Ablauf, weil es direkt beim Root beginnt und jede Weiterleitung ausgibt, statt einen Cache zu fragen. So lässt sich am schnellsten prüfen, ob Delegierung und Zone übereinstimmen.

Die relevanten DNS-Records beim Betrieb eines Servers

• A: ordnet einen Namen einer IPv4-Adresse zu. example.com. A 203.0.113.10. Dieser Record verweist Ihre Domain auf Ihren VPS.
• AAAA: ordnet einen Namen einer IPv6-Adresse zu, beispielsweise 2001:db8::10. Veröffentlichen Sie ihn nur, wenn Ihr Dienst tatsächlich unter dieser Adresse auf Verbindungen wartet. Clients in IPv6-Netzwerken verwenden zuerst die AAAA-Antwort. Eine Adresse, unter der kein Dienst antwortet, führt daher bei jedem Aufruf zu einer Verzögerung.
• CNAME: ein Alias von einem Namen auf einen anderen Namen. www.example.com. CNAME example.com. leitet Besucher von www an das Ziel weiter, auf das die nackte Domain aufgelöst wird. Ein CNAME kann nicht am Apex (der nackten example.com) verwendet werden, weil der Apex eigene SOA- (Start of Authority) und NS-Records enthalten muss und ein CNAME nicht denselben Namen wie ein anderer Record haben darf. Provider bieten dafür Lösungen unter Bezeichnungen wie ALIAS, ANAME oder CNAME flattening an.
• MX: legt fest, an welchen Host Mail für die Domain zugestellt wird. Der Record enthält einen Hostnamen und eine Präferenznummer. Die kleinere Zahl wird zuerst versucht. Ein MX muss auf einen Namen mit einem Adress-Record zeigen. Ein MX auf einen CNAME zu verweisen ist ungültig, und einige sendende Server weisen ihn zurück.
• TXT: Freitext für Nachweise und Richtlinien. Hier befinden sich Mail-Authentifizierungsrecords (SPF, DKIM, DMARC) ebenso wie das ACME- (automatic certificate management environment) Token, mit dem ein Wildcard-Zertifikat ausgestellt wird.
• NS: legt fest, welche Nameserver die Zone bereitstellen. Die Kopie, die bestimmt, wo Anfragen aus dem Internet gestellt werden, liegt in der übergeordneten Zone und stammt aus der Delegation Ihres Registrars, nicht aus der Kopie innerhalb Ihrer eigenen Zone.

Zwei Details sorgen für mehr Verwirrung als die Record-Typen selbst. Ein Name mit einem abschließenden Punkt ist absolut. www.example.com. bedeutet also genau diesen Namen und nichts Weiteres. Die meisten Verwaltungsoberflächen erwarten einen relativen Namen und hängen die Domain automatisch an. Wenn Sie www.example.com in das Namensfeld eingeben, erhalten Sie daher www.example.com.example.com. Dieser Name wird für niemanden aufgelöst. Das andere Detail ist @. In fast jeder Verwaltungsoberfläche bezeichnet dies den Apex: die Domain selbst, ohne Subdomain.

Auf einen A-Record für Ihren VPS zeigen

Ermitteln Sie zuerst die Adresse, unter der Ihr Server im Internet sichtbar ist:

curl -4 https://ifconfig.me
ip -brief -4 address show

Erstellen Sie anschließend bei Ihrem DNS-Host einen Record: Typ A, Name @, Wert diese Adresse, TTL (Time to Live) 300. Fügen Sie einen zweiten Record für www hinzu: entweder einen weiteren A mit derselben Adresse oder einen CNAME, der auf die Apex-Domain zeigt.

Prüfen Sie nun die Auflösung, möglichst von Ihrem Laptop und nicht vom Server selbst:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Der erste Befehl verwendet den normalen Netzwerkpfad Ihres Rechners einschließlich Caches. Der zweite umgeht den lokalen Cache und fragt einen öffentlichen rekursiven Resolver ab. Der dritte fragt Ihren autoritativen Nameserver direkt ab. Seine Antwort entspricht daher dem aktuellen Stand, ohne Cache im Pfad. Wenn der dritte Befehl Ihre Adresse zurückgibt und der erste nicht, ist DNS korrekt konfiguriert. Sie warten dann auf eine zwischengespeicherte Kopie der alten Antwort.

Namensauflösung funktioniert, aber die Verbindung wird nicht hergestellt

Eine erfolgreiche Namensauflösung belegt, dass DNS funktioniert. Sie sagt nichts über Ihren Webserver aus. Sobald dig die richtige Adresse zurückgibt, testen Sie die Verbindung:

curl -I http://example.com

curl: (6) Could not resolve host: example.com ist ein DNS-Problem. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused ist kein DNS-Problem: Der Name wurde aufgelöst und das Paket ist angekommen. Das Problem besteht also darin, dass an diesem Port kein Prozess auf Verbindungen wartete. Eine Anfrage, die hängt und anschließend mit einem Timeout abbricht, bedeutet normalerweise, dass eine Firewall das Paket stillschweigend verworfen hat, anstatt die Verbindung abzulehnen. Ab diesem Punkt ist DNS nicht mehr relevant. Stattdessen geht es um Ports und wartende Sockets sowie die ufw-Firewallregeln auf Ihrem VPS. Sobald die Verbindung hergestellt ist, übernimmt HTTP den weiteren Seitenaufbau.

Warum der Browser weiterhin den alten Host anzeigt

Nichts wird propagiert. Kein Server übermittelt Ihre Änderung aktiv an andere Systeme. Ihr autoritativer Nameserver enthält den neuen Wert sofort nach dem Speichern. Jede gecachte Kopie der vorherigen Antwort bleibt jedoch so lange gültig, bis ihr eigener Timer abläuft. Dieser Timer ist die TTL in Sekunden, die der Datensatz beim Ausliefern enthielt.

Kopien befinden sich an mehr Stellen, als viele erwarten: im kurzen Cache des Browsers, im Stub-Resolver des Rechners, im rekursiven Resolver des Netzwerks und in jedem Resolver, den ein VPN auf dem Client installiert. Jeder dieser Resolver behält seine Kopie bis zu der empfangenen TTL. Zwei Personen in zwei Netzwerken können stundenlang unterschiedliche Antworten sehen. Beide Rechner verhalten sich dabei korrekt.

Beobachten Sie den Countdown bei einem Caching-Resolver:

dig @1.1.1.1 example.com +noall +answer

Führen Sie den Befehl zweimal im Abstand von einigen Sekunden aus. Die TTL in der Antwort wird kleiner. Sobald sie null erreicht, verwirft der Resolver den Datensatz und fragt Ihren Nameserver erneut.

Es gibt noch einen zweiten Cache, den fast niemand berücksichtigt: negative Antworten. Wenn ein Resolver die Information erhält, dass ein Name nicht existiert, cached er auch diesen NXDOMAIN-Status. Maßgeblich ist dabei die im letzten Feld des SOA-Datensatzes Ihrer Zone festgelegte Zeit.

dig example.com SOA +short

Die letzte Zahl in dieser Zeile ist die negative TTL, häufig 3600. Wenn Sie staging.example.com abfragen, bevor Sie den Datensatz anlegen, kann der Eintrag nach dem Anlegen noch eine volle Stunde lang verborgen bleiben. Legen Sie den Datensatz zuerst an und fragen Sie ihn anschließend ab.

Das Ändern von Nameservern dauert länger als das Ändern eines Datensatzes. Der Grund ist technisch bedingt. Die Delegierungsdatensätze in der Zone .com werden mit einer TTL von 172800 Sekunden ausgeliefert, also mit zwei Tagen. Ein Resolver, der Ihre alten Nameserver gecached hat, kann deshalb so lange weiterhin diese Nameserver abfragen. Daher stammt der Hinweis, bis zu 48 Stunden einzuplanen. Er gilt für Änderungen an Nameservern, nicht für gewöhnliche Änderungen an Datensätzen.

Planen Sie eine Migration anhand der TTL, statt gegen sie zu arbeiten:

1. Setzen Sie die TTL des Datensatzes auf 300 und speichern Sie die Änderung.
2. Warten Sie länger als die alte TTL, damit jede gecachte Kopie mit dem alten Wert abgelaufen ist.
3. Ändern Sie die Adresse.
4. Sobald der Netzwerkverkehr umgeleitet wurde, setzen Sie die TTL wieder auf 3600 oder höher. Eine niedrige TTL führt dazu, dass jeder Resolver Ihre Nameserver deutlich häufiger abfragt.

So löschen Sie die auf Ihrem eigenen Rechner gespeicherten Daten:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics gibt einen Cache-Abschnitt mit Zählern für Treffer und Fehlschläge aus. Direkt nach dem Leeren wird die nächste Abfrage daher als Fehlschlag angezeigt. Browser verwenden einen separaten Cache. Chrome kann deshalb noch eine alte Antwort verwenden, nachdem der System-Cache bereits leer ist. Leeren Sie diesen Cache bei chrome://net-internals/#dns. Prüfen Sie auch /etc/hosts. Eine dort verbliebene Zeile hat auf diesem Rechner Vorrang vor DNS, und zwar nur auf diesem Rechner. getent hosts example.com zeigt die Antwort an, die das System tatsächlich verwendet, einschließlich /etc/hosts.

Wildcard-Zertifikate werden mit einem TXT-Record validiert

Eine CA (Certificate Authority) prüft die Kontrolle über einen Namen, bevor sie ein Zertifikat ausstellt. Bei der HTTP-01-Challenge wird eine Datei über Port 80 unter genau diesem Hostnamen bereitgestellt. Das funktioniert gut für einen einzelnen Namen. Ein Wildcard-Zertifikat gilt für *.example.com, also für eine offene Menge von Hostnamen, von denen die CA keine Datei abrufen kann. Deshalb stellt Let's Encrypt Wildcard-Zertifikate nur über die DNS-01-Challenge aus. Sie veröffentlichen unter _acme-challenge.example.com einen TXT-Record mit einem Token, den Ihnen die CA bereitstellt. Die Kontrolle über die Zone dient als Nachweis.

Dadurch wird Ihr DNS-Host Teil der Zertifikatserneuerung. Certbot muss diesen TXT-Record bei jeder Erneuerung selbstständig anlegen und löschen. Dafür benötigt es eine API und ein passendes Plugin für Ihren Provider. Wenn die Validierung fehlschlägt, lautet die typische Meldung DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Das bedeutet, dass die CA die Abfrage durchgeführt hat, bevor der Record sichtbar war. Entweder wurde er nie gespeichert oder eine negative Antwort war noch im Cache. Die vollständige Vorgehensweise finden Sie in der Anleitung zu Wildcard-Zertifikaten mit der DNS-01-Challenge.

Wenn ein VPN den Resolver übernimmt

Ein VPN-(Virtual-Private-Network-)Client ersetzt normalerweise den System-Resolver, solange die Verbindung besteht. Andernfalls würden DNS-Abfragen an das lokale Netzwerk übermittelt. Dadurch könnte dieses Netzwerk den Namen jeder von Ihnen besuchten Website sehen. Dieses Verhalten ist korrekt. Es kann jedoch in zwei Richtungen fehlschlagen.

Wenn der Tunnel aufgebaut wird und Namen nicht mehr aufgelöst werden, während IP-Adressen weiterhin erreichbar sind, ist der vom Client installierte Resolver aus dem Tunnel heraus nicht erreichbar. ping 1.1.1.1 ist erfolgreich, und curl https://example.com gibt curl: (6) Could not resolve host: example.com zurück. Wenn der Tunnel dagegen aufgebaut wird und Abfragen weiterhin an das Netzwerk gesendet werden, mit dem Sie gerade verbunden sind, wird Ihr Netzwerkverkehr durch den Tunnel geleitet, während der lokale Resolver weiterhin jeden von Ihnen abgefragten Namen sieht.

resolvectl status

Damit wird der für jede Verbindung verwendete Resolver ausgegeben. So können Sie sehen, welchen Resolver der Tunnel installiert hat und ob es der gewünschte Resolver ist. Ein WireGuard-Tunnel legt diesen über die Zeile DNS = in der Client-Konfiguration fest. Der Artikel DNS reparieren, wenn WireGuard den Resolver übernimmt beschreibt die Fälle mit systemd-resolved und resolvconf ausführlich.

Die Antwortcodes und was sie jeweils aussagen

• NXDOMAIN: Ein autoritativer Server teilt mit, dass der Name nicht existiert. Prüfen Sie die Schreibweise, ein doppelt angegebenes Domain-Suffix und ob Sie die Zone bearbeitet haben, auf die Ihre Delegation verweist.
• NOERROR mit einem leeren ANSWER SECTION: Der Name existiert, enthält aber keinen Record des abgefragten Typs. Eine Abfrage nach AAAA, wenn nur ein A existiert, führt genau dazu.
• SERVFAIL: Der Resolver hat die Abfrage versucht, konnte aber keine Antwort erzeugen. Die beiden üblichen Ursachen sind autoritative Server, die nicht antworten, und eine fehlgeschlagene DNSSEC-Validierung (domain name system security extensions). Testen Sie mit dig @1.1.1.1 example.com A +cd, wodurch die Validierung deaktiviert wird. Wenn damit eine Antwort mit +cd und SERVFAIL zurückkommt, liegt das Problem bei den Signaturen. Das passiert nach einem Nameserver-Wechsel, wenn der Parent weiterhin den alten DS-Record (delegation signer) veröffentlicht.
• REFUSED: Der abgefragte Server beantwortet diese Frage nicht. Meistens wurde dig auf einen autoritativen Server für eine Domain verwiesen, die dieser Server nicht bedient.
• ;; connection timed out; no servers could be reached: dig hat keinen Resolver erreicht. Das ist ein Netzwerk- oder Resolver-Problem auf Ihrer Seite. Die Domain ist daher nicht die Ursache.

ping: example.com: Temporary failure in name resolution bezeichnet dieselbe Fehlerklasse, die von glibc statt von dig gemeldet wird.

Sollten Sie Nameserver auf Ihrem eigenen VPS betreiben?

Das ist möglich. bind9, knot oder nsd stellt Ihre Zone direkt auf dem Server bereit. Außerdem lernen Sie dabei mehr über DNS als mit jedem Control Panel. Die Einwände sind praktischer Natur. Eine Domain sollte mindestens zwei Nameserver in getrennten Netzwerken haben. Ein einzelner VPS wird daher für alle Dienste der Domain zu einem Ausfallpunkt, einschließlich des Mail-Dienstes. Nameserver, deren Namen innerhalb der von ihnen bereitgestellten Domain liegen, benötigen beim Registrar Glue Records. Dabei wird die Adresse von ns1.example.com in der übergeordneten Zone hinterlegt. Andernfalls kann die Abfrage nicht gestartet werden. Wenn ein Resolver Ihren Nameserver nicht erreichen kann, weicht er nicht auf Ihre Website aus. Die gesamte Domain ist für diesen Benutzer nicht erreichbar. Für die meisten Benutzer ist gehostetes DNS mit einer API die risikoärmere Wahl. Einen Caching-Resolver auf Ihrem VPS für Ihre eigenen Rechner zu betreiben, ist eine andere Aufgabe und eine deutlich geringere Verpflichtung.

FAQ

Warum wurde meine DNS-Änderung noch nicht übernommen?

Es wird nichts propagiert. Ihre autoritativen Nameserver enthalten den neuen Wert sofort nach dem Speichern. Jeder Resolver, der die Domain bereits abgefragt hat, behält seine zwischengespeicherte Kopie, bis die empfangene TTL abläuft. Fragen Sie den autoritativen Server direkt mit dig @ns1.your-dns-host.net example.com A +short ab. Wenn dieser die neue Adresse zurückgibt, ist die Änderung aktiv. Alles Weitere ist Caching. Wenn Sie statt Records die Nameserver geändert haben, müssen Sie mit einer deutlich längeren Dauer rechnen, weil TLD-Delegierungen mit einer TTL von zwei Tagen verteilt werden.

Wie finde ich heraus, welche Nameserver meine Domain tatsächlich verwendet?

dig example.com NS +short gibt die Nameserver aus, die derzeit für die Domain antworten. dig +trace example.com zeigt die Weiterleitungskette ab dem Root einschließlich der Delegierung, die die TLD-Server ausgeben. Wenn diese Namen nicht dem Anbieter entsprechen, in dessen Panel Sie die Änderungen vorgenommen haben, liegt dort der Fehler. Bearbeiten Sie entweder die Records bei dem in der Delegierung genannten Anbieter oder ändern Sie die Delegierung bei Ihrem Registrar, sodass sie auf den gewünschten Anbieter zeigt.

Meine Domain wird aufgelöst, aber die Website lädt weiterhin nicht. Was muss ich jetzt tun?

DNS ist abgeschlossen, sobald dig example.com A +short die Adresse Ihres Servers zurückgibt. Danach liegt das Problem bei der Verbindung. Wenn curl -I http://example.com Connection refused zurückgibt, lauscht auf diesem Port kein Dienst. Eine Anfrage, die bis zum Timeout hängen bleibt, bedeutet, dass eine Firewall das Paket verworfen hat. Prüfen Sie, ob Ihr Webserver läuft und an die öffentliche Adresse gebunden ist. Prüfen Sie anschließend die Firewall auf dem Server und die separate Netzwerk-Firewall im Control Panel Ihres Anbieters.

Warum kann ich keine CNAME-Record für meine Root-Domain anlegen?

Ein CNAME gibt an, dass ein Name ein Alias für einen anderen Namen ist. Ein Name mit einem CNAME darf keine weiteren Records enthalten. Ihre Root-Domain muss SOA- und NS-Records enthalten, damit sie als Zone existieren kann. Deshalb kann sie nicht zusätzlich ein CNAME sein. Verwenden Sie am Root einen A-Record mit der Adresse. Alternativ können Sie die Provider-Funktion verwenden, die als ALIAS, ANAME oder CNAME flattening angeboten wird. Sie speichert einen Namen und beantwortet Abfragen mit der Adresse, auf die dieser Name aktuell aufgelöst wird.