Domain auf den Server zeigen lassen: A, AAAA, Wildcard und CAA richtig setzen

Ein frischer Server hat eine Adresse, aber noch keinen Namen. Bevor Zertifikate, Website, Mail oder andere Dienste laufen, muss die eigene Domain auf den Server zeigen. Dafür reichen eine Handvoll DNS-Einträge, doch genau hier entstehen die Fehler, die später schwer zu finden sind: eine vergessene IPv6-Adresse, eine Wildcard, die nicht greift, oder ein CAA-Eintrag, der Let's Encrypt aussperrt. Diese Anleitung zeigt, welche Einträge ein Server im Netz wirklich braucht, wie Sie sie von außen prüfen und wie lange es dauert, bis die Welt die neue Adresse sieht. Alle Zeiten und Fehlermeldungen stammen aus unserem eigenen Test.

Dies ist Teil 3 der Reihe „Server im Netz“. In der Reihe wird ein einzelner VPS mit der Domain sedv-lab.de Schritt für Schritt zum eigenen Standbein im Internet, gemessen von außen. Als Beispiel dient ein netcup-VPS, die Domain liegt im klassischen DNS von netcup.

Voraussetzungen

• Eine eigene Domain, deren DNS Sie selbst pflegen können (bei netcup im CCP oder über die API)
• Ein Server mit öffentlicher IPv4- und IPv6-Adresse
• Das Werkzeug dig auf dem Server oder am eigenen Rechner (Ubuntu: Paket bind9-dnsutils)
• Etwa 30 Minuten, davon gut zehn Minuten Warten

Schritt 1: Den Ist-Stand sichern

Bevor Sie etwas ändern, schreiben Sie auf, was heute in der Zone steht. Geht etwas schief, können Sie so jeden Eintrag zurückholen:

for t in A AAAA MX TXT CAA NS; do dig +noall +answer $t sedv-lab.de @root-dns.netcup.net; done | tee zone-vorher.txt

Fragen Sie dabei direkt einen Nameserver Ihres Anbieters, nicht den Resolver Ihres Routers. Der liefert unter Umständen noch alte Antworten aus seinem Zwischenspeicher. Den Namen Ihrer Nameserver zeigt dig +short NS sedv-lab.de.

Die Schleife erfasst nur die Einträge der Domain selbst. Unternamen wie mail oder www fragen Sie einzeln ab, eine ganze Zone gibt netcup per DNS nicht heraus. Vollständig sichern Sie die Zone mit einem Bildschirmfoto des DNS-Reiters oder über die DNS-API von netcup.

Verifizieren: Die Datei zone-vorher.txt enthält die Einträge der Domain, und Sie haben alle Unternamen aus dem DNS-Reiter zusätzlich notiert.

Schritt 2: Die TTL rechtzeitig senken

Die TTL legt fest, wie lange Resolver eine Antwort zwischenspeichern dürfen. Steht sie auf einem Tag, sehen manche Besucher die alte Adresse bis zu einen Tag lang. Senken Sie die TTL der Zone deshalb mindestens eine alte TTL-Dauer vor dem Umzug auf 300 Sekunden. Bei netcup gilt eine TTL für die ganze Zone, einzelne Einträge haben keine eigene.

Verifizieren: Die zweite Spalte von dig +noall +answer A sedv-lab.de @root-dns.netcup.net zeigt 300.

Schritt 3: Die Adressen des Servers ermitteln

Die IPv4-Adresse steht im SCP unter Netzwerk. Für IPv6 stellt netcup ein ganzes /64-Netz bereit. Welche Adresse daraus Ihr Server tatsächlich nutzt, zeigt er selbst:

ip -4 addr show eth0 scope global
ip -6 addr show eth0 scope global

Heißt die Netzwerkkarte bei Ihnen anders, zeigt ip -br addr alle Namen.

Tragen Sie genau die Adresse ein, die hier unter inet6 mit scope global steht, nicht die Netzadresse mit :: am Ende. Wie IPv6 auf dem netcup-Server eingerichtet wird, erklärt die verlinkte Anleitung unten.

Verifizieren: ping -6 -c2 2606:4700:4700::1111 antwortet, der Server kommt also über IPv6 ins Netz.

Schritt 4: A, AAAA und Wildcard eintragen

Für einen Server, auf dem später mehrere Dienste unter eigenen Namen laufen, haben sich diese Einträge bewährt:

Host	Typ	Ziel	Wofür
@	A	IPv4 des Servers	die Domain selbst
@	AAAA	IPv6 des Servers	die Domain selbst über IPv6
*	A	IPv4 des Servers	jeder andere Name, zum Beispiel www oder status
*	AAAA	IPv6 des Servers	dasselbe über IPv6

Die Wildcard spart Arbeit: Jeder neue Dienst bekommt seinen Namen nur noch im Reverse Proxy, nicht mehr im DNS. Der Preis: Jeder ausgedachte Name zeigt auf Ihren Server. Ihr Proxy sollte unbekannte Namen deshalb ablehnen statt eine Seite auszuliefern, das richten wir in Teil 4 ein. Wer das nicht möchte, legt statt der Wildcard jeden Namen einzeln an.

Vergessen Sie den AAAA-Eintrag nicht. Let's Encrypt verbindet sich laut eigener Doku immer zuerst über IPv6, wenn es einen AAAA-Eintrag gibt. Auf IPv4 weicht es nur aus, wenn die IPv6-Verbindung auf Netzebene scheitert, etwa durch einen Timeout. Laut Doku lässt ein AAAA-Eintrag auf einen falschen Server, der antwortet, die Prüfung deshalb fehlschlagen. Die Doku beschreibt diesen Rückfall für die Prüfung per HTTP.

Verifizieren: Nach der nächsten Veröffentlichung liefern dig +short A sedv-lab.de @root-dns.netcup.net und dig +short AAAA sedv-lab.de @root-dns.netcup.net die Adressen des Servers.

Schritt 5: CAA festlegen

CAA-Einträge legen fest, welche Zertifizierungsstellen für Ihre Domain Zertifikate ausstellen dürfen. Ohne CAA darf es jede. Mit diesen drei Einträgen nur noch Let's Encrypt:

@  CAA  0 issue "letsencrypt.org"
@  CAA  0 issuewild "letsencrypt.org"
@  CAA  0 iodef "mailto:admin@sedv-lab.de"

issue gilt für normale Zertifikate und, solange kein issuewild existiert, auch für Wildcards. issuewild regelt Wildcard-Zertifikate getrennt. iodef nennt eine Adresse für Meldungen über abgelehnte Anträge. Die CAA-Seite von Let's Encrypt erwähnt iodef nicht, und RFC 8659 verpflichtet keine Zertifizierungsstelle zum Senden. Rechnen Sie also nicht mit Mails an diese Adresse. Die Zertifizierungsstelle sucht den CAA-Eintrag, der dem angefragten Namen am nächsten liegt: erst www.sedv-lab.de, dann sedv-lab.de. Ein CAA-Eintrag an einem Unternamen überstimmt also den an der Domain.

Verifizieren: dig +short CAA sedv-lab.de @root-dns.netcup.net zeigt die drei Zeilen.

Schritt 6: Warten und von außen prüfen

netcup übernimmt Änderungen nicht sofort, sondern veröffentlicht sie gebündelt. Die netcup-Hilfe spricht von einer Aktualisierung „im Regelfall innerhalb von ca. 10 Minuten“. Wir haben die Änderung um 14:43:33 gespeichert und ab dann etwa alle zehn Sekunden an sechs Servern nachgefragt. Zwei Minuten später kamen noch die Testnamen für Schritt 7 und die Fehlertabelle dazu.

root-dns.netcup.net lieferte die neue Adresse nach 7:40 Minuten, second-dns und third-dns folgten etwa eine und zwei Minuten später. Die öffentlichen Resolver durften die alte Adresse noch bis zu 300 Sekunden speichern und fragen danach einen der drei netcup-Server, die unterschiedlich weit waren. Alle drei Resolver antworteten deshalb mehrere Minuten lang abwechselnd alt und neu, für die Domain wie für einen zufälligen Unternamen. Vermutlich trägt dazu bei, dass hinter jeder dieser Adressen viele Server mit eigenem Zwischenspeicher stehen. Nach 11:07 Minuten hatte jeder der sechs Server mindestens einmal neu geantwortet, nach 11:39 Minuten lieferten alle sechs in derselben Runde die neue Adresse und die CAA-Einträge.

Diese Schleife zeigt auf einen Blick, was jeder Server gerade für die Domain liefert. Setzen Sie Ihre Domain ein und wiederholen Sie sie, bis alle Zeilen stimmen:

for ns in root-dns.netcup.net second-dns.netcup.net third-dns.netcup.net 1.1.1.1 8.8.8.8 9.9.9.9; do
  printf "%-24s %s\n" "$ns" "$(dig +short A sedv-lab.de @$ns)"
done

Zeigen alle Zeilen die neue Adresse, lohnt ein Test aus Sicht der Besucher. Wir nutzen dafür den Website-Test von internet.nl. Er prüft unter anderem, ob Nameserver und Webserver über IPv6 erreichbar sind und dieselbe Website liefern:

Das rote Kreuz bei DNSSEC heißt: Die Zone ist nicht signiert. Unsere Versuche, DNSSEC für unsere Testdomains einzuschalten, scheiterten im CCP mit der Meldung „DNSSEC konnte nicht aktiviert werden“ und über die API mit „DNSSEC could not be enabled“. Wie DNSSEC bei netcup im Normalfall aktiviert wird, beschreibt die verlinkte Anleitung.

Verifizieren: Alle Zeilen der Schleife zeigen Ihre IP, und dig +short CAA sedv-lab.de @9.9.9.9 liefert die CAA-Einträge.

Schritt 7: Die Wildcard-Falle kennen

Eine Wildcard gilt nur für Namen, die in der Zone sonst gar nicht vorkommen. Im Test haben wir für caa-test nur einen CAA-Eintrag angelegt. Danach liefert caa-test.sedv-lab.de keine Adresse mehr:

$ dig +noall +comments A caa-test.sedv-lab.de @root-dns.netcup.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36030
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Der Name existiert, hat aber keinen A-Eintrag, und die Wildcard springt nicht ein. Genau das meldete auch Let's Encrypt, als Caddy ein Zertifikat für diesen Namen holen wollte. Wer einem Namen einen eigenen Eintrag gibt, muss ihm also auch A und AAAA geben.

Verifizieren: Für jeden Namen mit eigenen Einträgen liefert dig +short A name.sedv-lab.de eine Adresse.

Typische Fehler

Alle Meldungen stammen aus unserem Test mit dem Testsystem von Let's Encrypt.

Meldung	Ursache und Lösung
urn:ietf:params:acme:error:caa ... CAA record for caa-sperre.sedv-lab.de prevents issuance	Am Namen steht ein CAA-Eintrag für eine andere Zertifizierungsstelle (im Test sectigo.com). Er überstimmt den Eintrag an der Domain. Eintrag löschen oder letsencrypt.org ergänzen.
urn:ietf:params:acme:error:dns ... no valid A records found for caa-test.sedv-lab.de; no valid AAAA records found ...	Die Wildcard-Falle aus Schritt 7. A und AAAA für den Namen eintragen. Im Test stand dort zusätzlich CAA für Sectigo, den müssten Sie dann ebenfalls entfernen.
Besucher sehen noch die alte Seite	Zwischenspeicher der Resolver. Bis zur alten TTL plus Veröffentlichungszeit warten, vorher die TTL senken.
Zertifikat klappt, obwohl der AAAA-Eintrag falsch ist	Im Test zeigte v6falsch auf eine nicht erreichbare IPv6-Adresse, und Let's Encrypt stellte trotzdem aus. In unserem Test lief die Prüfung per tls-alpn-01, und alle Prüfverbindungen kamen über IPv4. Besucher, die nur IPv6 haben, erreichen die Seite nicht, andere warten beim Verbindungsaufbau, bis ihr Gerät auf IPv4 ausweicht. AAAA korrigieren.

Häufige Fragen

Brauche ich einen www-Eintrag?

Mit der Wildcard nicht, www zeigt dann automatisch auf den Server. Ohne Wildcard legen Sie www als CNAME auf die Domain oder mit eigenen A- und AAAA-Einträgen an. Die Umleitung von www auf die Domain erledigt der Webserver.

Wie lange dauert es bei netcup?

Im Test vergingen 7:40 Minuten bis zum ersten netcup-Nameserver und 11:39 Minuten, bis alle sechs geprüften Server gleichzeitig die neue Adresse lieferten. Rechnen Sie mit rund einer Viertelstunde: Der letzte netcup-Server war nach 9:29 Minuten neu, Resolver dürfen alte Antworten danach noch bis zu 300 Sekunden behalten.

Muss ich die Mail-Einträge anfassen?

Nur, wenn auch Mail auf den neuen Server umzieht. MX, SPF und DKIM betreffen nur Mail und bleiben sonst stehen, sofern Ihr SPF-Eintrag nicht mit a auf die Domain verweist. Den Mailserver richten wir in einem eigenen Teil der Reihe ein.

Ist eine Wildcard ein Sicherheitsrisiko?

Sie verrät nichts und öffnet keinen Port. Sie bewirkt nur, dass jeder Name bei Ihrem Server ankommt. Entscheidend ist, dass der Webserver nur bekannte Namen bedient. Wildcard-Zertifikate sind ein eigenes Thema, die Anleitung dazu ist unten verlinkt.

Fazit

Vier Adresseinträge und drei CAA-Einträge reichen, damit die eigene Domain sauber auf den Server zeigt, über IPv4 und IPv6 und nur mit Zertifikaten der gewünschten Stelle. Die Fehler stecken im Detail: ein vergessener AAAA-Eintrag, eine Wildcard, die bei Namen mit eigenen Einträgen nicht mehr greift, und ein CAA-Eintrag am Unternamen, der den an der Domain überstimmt. Planen Sie bei netcup rund eine Viertelstunde ein und prüfen Sie von außen, bevor Sie Zertifikate anfordern. Im nächsten Teil bekommt sedv-lab.de mit Caddy HTTPS und die Bestnote bei SSL Labs.

Weiterführende Anleitungen und Quellen

• IPv6 auf dem netcup-Server einrichten und prüfen
• DNSSEC bei netcup aktivieren
• Wildcard-Zertifikat mit Traefik und Caddy über die netcup-DNS-API
• Externe Domains und Nameserver bei netcup
• Docker und Docker Compose auf Linux installieren
• netcup: DNS-Einstellungen
• Let's Encrypt: CAA
• Let's Encrypt: IPv6-Unterstützung
• RFC 8659: DNS Certification Authority Authorization
• internet.nl: Website-Test