Eine Website kann technisch einwandfrei laufen und trotzdem nicht erreichbar sein, wenn ein einziger DNS-Eintrag auf das falsche Ziel zeigt. In diesem Beitrag erkläre ich, wie DNS-Records funktionieren, welche Typen im Hosting wichtig sind und wie du Änderungen in DevOps-Prozessen sicher prüfst, ohne dich auf die oft missverstandene „Propagation“ zu verlassen.
DNS-Einträge verbinden Domains mit Websites, Diensten und E-Mail-Systemen
- A und AAAA verknüpfen einen Hostnamen mit einer IPv4- beziehungsweise IPv6-Adresse.
- CNAME dient als Alias, während MX den zuständigen Mailserver festlegt.
- TTL-Werte bestimmen, wie lange Resolver eine Antwort zwischenspeichern.
- TXT, CAA und DNSSEC helfen bei E-Mail-Sicherheit, Zertifikaten und der Absicherung von Antworten.
- Fehler lassen sich mit dig, nslookup und autoritativen Abfragen meist schnell eingrenzen.
Was ein DNS-Record tatsächlich macht
Das Domain Name System übersetzt Namen wie beispiel.de in technische Informationen. Ein DNS-Record ist dabei eine Anweisung innerhalb einer DNS-Zone. Sie legt etwa fest, welche IP-Adresse zu einer Domain gehört, welcher Server E-Mails annimmt oder welche Zertifizierungsstellen für ein TLS-Zertifikat zugelassen sind.
Beim Aufruf einer Website fragt das Gerät zunächst einen rekursiven DNS-Resolver. Dieser prüft seinen Cache und fragt bei Bedarf die autoritativen Nameserver der Domain. Erst danach erhält der Browser beispielsweise eine IPv4-Adresse und kann eine Verbindung zum Webserver aufbauen.
Ein Eintrag besteht typischerweise aus einem Namen, einer TTL, einem Typ und einem Wert. Die TTL wird in Sekunden angegeben. Ein Wert von 3600 bedeutet also, dass ein Resolver die Antwort grundsätzlich bis zu einer Stunde zwischenspeichern darf.
Die DNS-Auflösung entscheidet jedoch nicht allein darüber, ob eine Website funktioniert. Der Webserver muss die Domain ebenfalls kennen, die Firewall muss den Datenverkehr zulassen und das TLS-Zertifikat muss zum Hostnamen passen. DNS ist deshalb häufig der erste Prüfpunkt, aber selten die einzige mögliche Fehlerquelle.
Die wichtigsten Typen im Hosting
Für die meisten Websites brauchst du nur wenige Record-Typen regelmäßig. Trotzdem lohnt es sich, ihre Aufgaben sauber zu unterscheiden, weil ein falscher Eintrag oft nicht sofort auffällt und erst beim Wechsel des Hosters Probleme verursacht.
| Typ | Aufgabe | Typisches Beispiel |
|---|---|---|
| A | Verweist auf eine IPv4-Adresse. | @ → 192.0.2.10 |
| AAAA | Verweist auf eine IPv6-Adresse. | @ → 2001:db8::10 |
| CNAME | Verweist auf einen anderen Hostnamen. | www → beispiel.de |
| MX | Legt Mailserver und deren Priorität fest. | @ → 10 mail.beispiel.de |
| TXT | Speichert Text- und Verifizierungswerte. | SPF, DKIM, Domainprüfung |
| NS | Gibt die autoritativen Nameserver einer Zone an. | ns1.provider.example |
| CAA | Beschränkt zulässige Zertifizierungsstellen. | Nur der gewünschte CA-Anbieter |
A und AAAA für Webserver
Ein A-Record zeigt auf eine IPv4-Adresse. Für IPv6 wird ein AAAA-Record verwendet. Wenn dein Hoster beide Protokolle unterstützt, sollten beide Einträge korrekt eingerichtet sein. Ein veralteter AAAA-Record kann dazu führen, dass manche Besucher die Website nicht erreichen, obwohl der A-Record noch stimmt.
Für die Hauptdomain steht im Verwaltungsmenü oft @. Damit ist die sogenannte Zone-Apex gemeint, also beispiel.de selbst. Für www kannst du je nach Anbieter einen eigenen A-Record oder einen CNAME auf die Hauptdomain verwenden.
CNAME als flexibler Alias
Ein CNAME liefert keine IP-Adresse, sondern verweist auf einen anderen Namen. Das ist praktisch bei SaaS-Diensten, CDN-Anbietern und Plattformen, deren Infrastruktur sich gelegentlich ändert. Du pflegst dann nicht mehrere wechselnde IP-Adressen selbst.
Ein wichtiger Stolperstein ist die Kombination mit anderen Einträgen. Ein Hostname mit CNAME darf nach den üblichen DNS-Regeln nicht gleichzeitig eigene A-, MX- oder TXT-Daten tragen. Manche DNS-Anbieter bieten am Zonen-Apex spezielle Alias- oder Flattening-Funktionen an. Das ist eine Anbieterfunktion und kein allgemeines Verhalten eines klassischen CNAME.
MX und TXT für E-Mail
MX-Records bestimmen, wohin E-Mails für eine Domain zugestellt werden. Die Zahl vor dem Mailserver ist die Priorität, wobei die kleinere Zahl bevorzugt wird. Der im MX genannte Hostname sollte direkt auf A- oder AAAA-Records zeigen und nicht auf einen CNAME.
TXT-Records wirken unscheinbar, sind aber für die E-Mail-Zustellung besonders wichtig. SPF beschreibt erlaubte Absender, DKIM veröffentlicht einen öffentlichen Schlüssel und DMARC legt fest, wie Empfänger mit nicht authentifizierten Nachrichten umgehen sollen. Diese drei Mechanismen gehören zusammen, ersetzen aber keine saubere Konfiguration des Maildienstes.
So richtest du DNS im Hosting sauber ein
Bevor ich einen Eintrag ändere, notiere ich mir immer den aktuellen Zustand der Zone. Dazu gehören mindestens A-, AAAA-, CNAME-, MX- und TXT-Einträge. Gerade bei einem Hosterwechsel wird häufig nur die Website betrachtet, während Mailserver, DKIM-Schlüssel oder Subdomains unbemerkt zurückbleiben.
Ein typisches Setup für eine Website
@ A 192.0.2.10
www CNAME @
api CNAME service.example.net.
@ MX 10 mail.beispiel.de.
@ TXT "v=spf1 include:mailanbieter.example ~all"Das Beispiel verbindet die Hauptdomain mit einem Webserver, führt www über einen Alias dorthin und legt einen separaten Hostnamen für eine API an. Die konkreten Werte müssen immer vom jeweiligen Hosting- oder Mailanbieter stammen. Beispielwerte dürfen nicht einfach in einer produktiven Zone übernommen werden.
Bei der Eingabe eines Zielnamens ist die Schreibweise entscheidend. Manche Oberflächen ergänzen automatisch die eigene Domain. Wird dort versehentlich mail.beispiel.de eingetragen, kann daraus intern mail.beispiel.de.beispiel.de werden. Ein abschließender Punkt wie bei mail.beispiel.de. kennzeichnet einen vollständig qualifizierten Namen, wird aber nicht von jedem Panel gleich behandelt.
TTL sinnvoll wählen
Für stabile Systeme sind 3600 Sekunden ein vernünftiger Ausgangspunkt. Vor einer geplanten Migration reduziere ich die TTL häufig ein bis zwei Tage vorher auf 300 oder 600 Sekunden. Das beschleunigt spätere Änderungen, entfernt aber keine bereits gespeicherten Antworten mit der alten, längeren TTL.
Eine niedrige TTL ist nicht automatisch besser. Sie erzeugt mehr DNS-Abfragen und bringt keinen Vorteil, wenn die Anwendung selbst weiterhin auf dieselbe Infrastruktur zeigt. Nach einer abgeschlossenen Migration kann die TTL wieder auf 3600 oder 86400 Sekunden steigen, sofern schnelle Umschaltungen nicht regelmäßig nötig sind.
DNS-Änderungen in DevOps und Infrastrukturprozessen
DNS gehört für mich zur Infrastruktur und nicht in eine lose Liste manueller Klicks. Sobald mehrere Umgebungen, Teams oder Dienste beteiligt sind, sollten Einträge nachvollziehbar versioniert und über einen kontrollierten Prozess geändert werden. Viele DNS-Provider stellen dafür APIs oder Terraform-Provider bereit.
Ein sinnvolles Muster trennt die Umgebungen klar. staging.beispiel.de, api.beispiel.de und internal.beispiel.de sollten nicht versehentlich auf dieselben Ziele zeigen. Besonders riskant ist es, Produktionswerte in einer Testpipeline zu verwenden, weil ein scheinbar harmloser Deploy dann die öffentliche Zone verändern kann.
Blue-Green-Deployments und Traffic-Steuerung
Bei einem Blue-Green-Deployment laufen alte und neue Version zunächst parallel. Ein DNS-Wechsel kann den Datenverkehr auf die neue Umgebung lenken, ist aber kein perfekter Sofortschalter. Resolver und lokale Betriebssysteme behalten Antworten bis zum Ablauf der TTL im Cache.
Für wirklich schnelle Umschaltungen sind Load Balancer, Reverse Proxies oder ein CDN meist geeigneter. DNS eignet sich gut für grobe Zieländerungen, aber weniger für eine sekundengenaue Steuerung einzelner Requests. Diese Einschränkung wird in der Praxis oft unterschätzt.
Lesen Sie auch: Website umziehen ohne Ausfälle - der sichere Migrationsplan
DNS als Code braucht Sicherheitsregeln
Automatisierte Änderungen sollten nur die benötigten Zonen und Record-Typen bearbeiten dürfen. Ich empfehle Least-Privilege-Zugriffe, einen Review-Prozess für Produktionsänderungen und Protokolle, aus denen Name, alter Wert, neuer Wert und Zeitpunkt hervorgehen.
Wildcards wie *.beispiel.de sind bequem, können aber Tippfehler und vergessene Subdomains auf eine funktionierende Anwendung lenken. Für interne Dienste sind getrennte Zonen oder private DNS-Namespaces oft sauberer als eine öffentliche Wildcard. Automatisierung erhöht die Geschwindigkeit, ersetzt aber keine Prüfung der Reichweite.
DNS-Sicherheit und typische Fehlkonfigurationen
DNSSEC signiert DNS-Daten kryptografisch, damit Resolver manipulierte Antworten erkennen können. Es verschlüsselt DNS-Abfragen nicht und schützt auch keinen kompromittierten Webserver. Wenn DNSSEC aktiviert wird, müssen die Schlüssel- und Delegationsdaten korrekt zusammenpassen, sonst kann eine Domain absichtlich oder versehentlich nicht mehr aufgelöst werden.
CAA-Records begrenzen, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. Das ist eine sinnvolle zusätzliche Kontrolle, funktioniert aber nur dann zuverlässig, wenn auch Erneuerungen, Subdomains und verwendete Zertifikatsdienste berücksichtigt werden.
Die häufigsten Fehler sehe ich bei diesen Punkten:
- Ein alter AAAA-Record zeigt auf einen nicht mehr erreichbaren IPv6-Server.
- Ein CNAME steht am falschen Ort oder wird mit anderen Records auf demselben Namen kombiniert.
- Der MX-Record verweist auf einen Hostnamen, für den kein A- oder AAAA-Record existiert.
- SPF wurde mehrfach als TXT-Record angelegt, obwohl eine Domain nur eine zusammengeführte SPF-Richtlinie verwenden sollte.
- Beim Wechsel der Nameserver wurden individuelle DKIM-, DMARC- oder Verifizierungs-Records nicht übertragen.
- Ein DNSSEC-DS-Record beim Registrar passt nicht mehr zum aktiven Schlüssel der DNS-Zone.
Ein gutes Sicherheitsniveau entsteht nicht durch möglichst viele Einträge. Entscheidend sind korrekte Delegation, minimale Berechtigungen und regelmäßige Kontrolle. Unbenutzte Subdomains sollten gelöscht oder bewusst auf ein ungefährliches Ziel gesetzt werden.
So findest du DNS-Fehler systematisch
Beginne mit einer konkreten Frage. Soll die Hauptdomain auf eine IPv4-Adresse zeigen, soll die Mailzustellung funktionieren oder fehlt nur die Verifizierung eines Drittanbieters? Diese Eingrenzung verhindert, dass du eine funktionierende Zone durch planlose Änderungen verschlimmbesserst.
Mit dig lassen sich einzelne Record-Typen direkt prüfen:
dig beispiel.de A
dig beispiel.de AAAA
dig beispiel.de MX
dig beispiel.de TXT
dig www.beispiel.de CNAMEFür einen schnellen Überblick genügt oft die Kurzform:
dig +short beispiel.de A
dig +short beispiel.de MXWenn du verschiedene Resolver vergleichen möchtest, kannst du gezielt öffentliche Resolver abfragen. Stimmen die Antworten nicht überein, liegt das häufig an unterschiedlichen Cache-Zuständen. Entscheidend ist zusätzlich eine Abfrage der autoritativen Nameserver, denn dort liegt die tatsächlich veröffentlichte Zonendatei.
„DNS-Propagation“ bedeutet nicht, dass eine Änderung eine feste Anzahl von Stunden benötigt. Alte Antworten verschwinden, sobald ihre jeweilige TTL abläuft. Praktisch können zusätzlich lokale Caches, Browser, Unternehmensnetzwerke und vorgeschaltete Dienste eine Rolle spielen. Bei kritischen Änderungen prüfe ich deshalb mehrere Standorte und nicht nur den eigenen Rechner.
Ein weiterer Klassiker ist die Verwechslung von DNS- und Webserverproblemen. Liefert dig die erwartete IP-Adresse, aber der Browser zeigt einen Fehler, solltest du als Nächstes TLS-Zertifikat, HTTP-Host-Konfiguration, Firewall und Routing untersuchen. DNS ist dann wahrscheinlich bereits korrekt.
Die kleine Prüfung vor dem nächsten DNS-Wechsel
Vor einer Änderung sollten Ziel, Record-Typ, TTL und Rückfallplan feststehen. Sichere die aktuelle Zone, prüfe abhängige Dienste und dokumentiere, ob die Änderung nur die Website oder auch E-Mail, APIs, Monitoring und Zertifikatsausstellung betrifft.
Nach dem Wechsel kontrollierst du A und AAAA, testest die wichtigsten Subdomains, sendest eine Testmail und beobachtest Logs sowie Zertifikatswarnungen. Wer DNS als versionierte Infrastruktur behandelt und Änderungen mit kleinen, überprüfbaren Schritten ausrollt, vermeidet die meisten Ausfälle schon bevor sie sichtbar werden.
