„Die Domain zeigt ins Leere“, „SSL geht nicht“, „E-Mails kommen nicht an“: Solche Probleme wirken oft wie Server- oder Code-Themen. In der Praxis steckt aber häufig DNS dahinter (das „Telefonbuch“ des Internets). Wer als Webentwickler die Grundlagen versteht, kann Fehler schneller eingrenzen, sauberer deployen und Support-Anfragen deutlich entspannen.
Was DNS eigentlich macht (und was nicht)
DNS (Domain Name System) übersetzt Namen wie Domain in technische Ziele, meist IP-Adressen. Der Browser fragt also nicht „konsolutions.de“, sondern: „Welche IP gehört zu diesem Namen?“ Erst danach läuft HTTP/HTTPS.
Wichtig: DNS entscheidet nicht, ob der Webserver korrekt konfiguriert ist. DNS sorgt nur dafür, dass Anfragen beim richtigen Ziel ankommen. Ob dort dann die richtige Website, das richtige Zertifikat oder die richtige App läuft, ist eine zweite Ebene.
Namensauflösung in kurz
Vereinfacht läuft eine Auflösung so ab:
- Ein Client (Browser, App, Server) fragt einen Resolver (meist vom Provider, im Unternehmen oder öffentlich).
- Der Resolver holt sich bei autoritativen Nameservern die passende Antwort für die Domain.
- Das Ergebnis wird für eine gewisse Zeit zwischengespeichert (Cache).
Dieser Cache ist später beim Debuggen entscheidend: Eine „falsche“ DNS-Antwort kann vom Cache kommen, obwohl der Eintrag im DNS-Panel schon korrigiert wurde.
Diese DNS-Records sind im Web-Alltag am wichtigsten
DNS besteht aus Einträgen (Records), die unterschiedliche Aufgaben haben. Für typische Webprojekte reichen oft wenige Record-Typen – wenn sie sauber gesetzt sind.
A- und AAAA-Record: Name → IP
Ein A-Record zeigt auf eine IPv4-Adresse, ein AAAA-Record auf eine IPv6-Adresse. Wenn ein Anbieter IPv6 aktiv hat, kann ein falscher AAAA-Record dazu führen, dass Nutzer über IPv6 eine andere (oder nicht funktionierende) Infrastruktur erreichen.
- A: IP-Adresse (IPv4) für „example.com“ oder „www.example.com“
- AAAA: IPv6-Ziel (nur setzen, wenn es wirklich funktioniert)
CNAME-Record: Alias auf einen anderen Namen
Ein CNAME ist ein Alias: „www.example.com“ zeigt nicht direkt auf eine IP, sondern auf einen anderen Hostnamen (z. B. „project.hosting-provider.com“). Das ist praktisch, weil sich IPs beim Anbieter ändern können, ohne dass die eigene Zone angepasst werden muss.
Typischer Fall: „www“ als CNAME auf das Ziel des Hosters. Vorsicht: Ein CNAME am Zonen-Root („example.com“) ist bei klassischem DNS problematisch, weil dort auch andere Records (z. B. MX für Mail) existieren müssen. Viele Anbieter lösen das mit speziellen „ALIAS/ANAME“-Features – das ist dann kein Standard-CNAME, sondern eine Provider-Funktion.
MX-Record: Mailzustellung
MX bestimmt, welche Mailserver E-Mails für eine Domain annehmen. Schon ein kleiner Tippfehler oder ein vergessener Punkt im Ziel kann dazu führen, dass Zustellung scheitert oder bei einem alten Anbieter landet.
Wichtig im Projektalltag: Webserver und E-Mail laufen oft bei unterschiedlichen Anbietern. Dann müssen A/AAAA/CNAME und MX getrennt korrekt gepflegt werden.
TXT-Record: Verifikation und Richtlinien
TXT ist der „Allzweck“-Record: Verifikationen (z. B. für Hosting, CDN, Google-Dienste), aber auch E-Mail-Sicherheitsregeln wie SPF oder DKIM werden meist als TXT gesetzt. Gerade hier passieren oft Konflikte, weil mehrere Tools Einträge hinzufügen wollen.
NS-Record: Wer ist zuständig?
NS-Records delegieren eine Zone an Nameserver. Das ist ein häufiger Stolperstein beim Providerwechsel: Die Zone kann im neuen DNS-Panel perfekt gepflegt sein – wenn die Domain aber noch auf die alten Nameserver zeigt, sieht „das Internet“ weiterhin die alte Zone.
Warum DNS-Änderungen Zeit brauchen: TTL, Cache und „Propagation“
Wenn DNS geändert wird, erwarten viele sofortige Wirkung. In Wirklichkeit gilt: Antworten werden zwischengespeichert. Die Gültigkeitsdauer heißt TTL (Time To Live) und steht an jedem Record.
Praktisch bedeutet das:
- Ein Client kann noch die alte Antwort sehen, bis sein Cache abläuft.
- Auch Resolvers zwischenspeichern Ergebnisse und liefern sie weiter.
- „Propagation“ ist kein magischer globaler Prozess, sondern die Summe aus Caches, die nach und nach ablaufen.
Für Releases und Umzüge lohnt sich daher Planung: TTL vorher absenken (rechtzeitig), dann umstellen, danach TTL wieder erhöhen. So minimiert sich die Zeit, in der Nutzer unterschiedliche Ziele sehen.
Debugging: ein pragmatischer Ablauf, der fast immer hilft
DNS-Probleme fühlen sich diffus an, lassen sich aber meist mit einem klaren Ablauf eingrenzen. Das Ziel ist, drei Fragen zu beantworten: Welche Antwort kommt zurück? Von wem kommt sie? Passt sie zum gewünschten Setup?
Schrittweise prüfen (ohne Tool-Zirkus)
- Record prüfen: Welche Einträge sind im DNS-Panel wirklich gesetzt (A/AAAA/CNAME/MX/TXT)?
- Autoritativen Stand prüfen: Beim DNS-Provider nachsehen, ob die Zone dort korrekt ist (nicht nur im Registrar).
- Nameserver prüfen: Zeigt die Domain auf die richtigen NS? (Sonst ist die falsche Zone aktiv.)
- Antwort vergleichen: Einmal über den eigenen Resolver (Standard) und einmal über einen unabhängigen Resolver abfragen. Unterschiede sind ein starker Hinweis auf Cache oder unterschiedliche Zonen.
- IPv6 nicht vergessen: Falls AAAA existiert, testen, ob das Ziel tatsächlich erreichbar ist.
- Webserver-Ebene abgrenzen: Wenn DNS korrekt ist, aber die Seite falsch ist: Virtual Hosts/Host-Header/Reverse Proxy prüfen.
Typische Symptome und was sie bedeuten
| Symptom | Häufige Ursache | Erster Check |
|---|---|---|
| Manche Nutzer sehen die neue Seite, andere nicht | Cache/TTL, alte Resolver-Antwort | Antwort über verschiedene Resolver vergleichen |
| „www“ geht, Root-Domain nicht (oder umgekehrt) | A/CNAME nur für einen Host gesetzt | Records für „@“ und „www“ prüfen |
| HTTPS-Zertifikat passt nicht zur Domain | DNS zeigt auf falschen Server/Proxy | IP und Zielsystem gegenprüfen |
| E-Mails kommen nicht an | MX falsch oder fehlt; TXT/SPF fehlerhaft | MX/TXT in der aktiven Zone prüfen |
| Nur über Mobilfunk erreichbar / nur im Büro nicht | Resolver/Cache im Netzwerk, split DNS | Abfrage im anderen Netz vergleichen |
Entscheidungshilfe für gängige Setups
Je nach Hosting-Setup ergeben sich unterschiedliche „richtige“ Records. Diese kleine Auswahl hilft, schnell das passende Muster zu finden.
- Wenn die Website auf einen festen Server zeigt:
- A (und optional AAAA) auf die Server-IP setzen.
- „www“ entweder ebenfalls als A/AAAA oder als CNAME auf die Root-Domain.
- Wenn ein Hosting/CDN einen Ziel-Hostnamen vorgibt:
- „www“ als CNAME auf den Provider-Hostnamen setzen.
- Für die Root-Domain prüfen, ob der Anbieter ALIAS/ANAME unterstützt; sonst A/AAAA auf die bereitgestellte IP nutzen.
- Wenn E-Mail bei einem anderen Anbieter liegt:
- MX nur für den Mailanbieter setzen (nicht beim Webhoster „mitlaufen lassen“).
- TXT für SPF/DKIM/Verifikation sauber bündeln (Konflikte vermeiden).
Häufige Fehler, die in Projekten immer wieder passieren
Falscher Ort: Registrar vs. DNS-Provider
Viele Domains werden beim Registrar gekauft, die DNS-Zone liegt aber bei einem anderen Provider (z. B. Cloud-DNS, Hoster, CDN). Dann muss klar sein: Die Records müssen dort gepflegt werden, wo die autoritativen Nameserver stehen. Sonst wirken Änderungen „ignoriert“, obwohl sie nur an der falschen Stelle gemacht wurden.
„www“ wird vergessen oder doppelt konfiguriert
Oft wird nur die Root-Domain eingerichtet. Nutzer rufen aber „www“ auf (oder umgekehrt). Deshalb gehören Root und „www“ fast immer gemeinsam betrachtet – inklusive Redirect auf eine kanonische Variante (das ist dann Webserver/Anwendung, nicht DNS).
IPv6 zeigt auf ein altes Ziel
Ein altes AAAA kann lange unbemerkt bleiben, bis ein Teil der Nutzer über IPv6 auf einen nicht mehr existierenden Server geht. Wenn IPv6 nicht aktiv betreut wird, ist es oft besser, AAAA zu entfernen, statt ihn „irgendwie“ stehen zu lassen.
TXT-Records kollidieren bei E-Mail und Verifikationen
SPF (Teil von Mail-Richtlinien) liegt häufig als TXT vor und wird von mehreren Tools erweitert. Problematisch wird es, wenn mehrere SPF-Einträge existieren oder ein Verifikations-Record versehentlich überschrieben wird. In Projekten hilft eine einfache Regel: TXT-Einträge dokumentieren, Namen klar halten und Änderungen über ein kurzes Review laufen lassen.
Praxisbox: in 10 Minuten zu einer sauberen DNS-Konfiguration
- Klare Zieldefinition: Welche Systeme sind zuständig (Web, API, Mail, CDN)?
- Nameserver festziehen: Sind die NS auf die gewünschte Zone delegiert?
- Root + „www“ gemeinsam planen: Ein Ziel definieren, das andere konsequent darauf ausrichten.
- TTL vor Umzug reduzieren und erst nach Stabilität wieder erhöhen.
- IPv6 bewusst entscheiden: AAAA nur setzen, wenn das Ziel getestet ist.
- Mail getrennt halten: MX/TXT für Mailanbieter prüfen, bevor Web-Records angepasst werden.
Wie DNS-Themen mit anderen Web-Bausteinen zusammenhängen
DNS ist selten isoliert. Häufige Kombinationen:
- DNS korrekt, aber Browser meckert: Dann liegt es oft an Zertifikat/HTTPS oder an einem Proxy. Hilfreich sind Grundlagen zu Web-Schutzmechanismen wie in HTTP Security Headers oder zu strikteren Richtlinien wie in CSP richtig umsetzen.
- API hinter Subdomain: „api.example.com“ bekommt meist eigene Records. Wenn Requests „hängen“, ist das nicht DNS, sondern eher Timeout/Client-Handling – dazu passt API-Timeouts sinnvoll setzen.
- Mehrere Umgebungen (staging, preview): Hier lohnt ein klares Namensschema und kurze TTLs, damit Teams nicht gegen alte Caches arbeiten.
Woran sich ein guter DNS-Stand in Teams erkennen lässt
In professionellen Projekten ist DNS kein „Einmal-Klick-im-Panel“, sondern ein gepflegter Teil der Infrastruktur: Records sind nachvollziehbar benannt, Zuständigkeiten sind klar, und Änderungen laufen kontrolliert. Das reduziert Ausfälle – gerade bei Domain-Umzügen, CDN-Wechseln oder wenn Mail vom Webhosting entkoppelt wird.
