dns-eintraege

DNS-Einträge

Kurz: Datensätze in einer DNS-Zone, die Domains bestimmte Informationen zuordnen — am bekanntesten IP-Adressen, aber auch Mailserver, Textinformationen oder Aliase.

Genauer: Jeder DNS-Eintrag hat einen Typ (z. B. A, AAAA, CNAME, MX, TXT, NS), einen Namen, einen Wert und eine TTL. Eine Domain kann beliebig viele Einträge unterschiedlichen Typs besitzen; welche Nameserver für eine Domain autoritativ sind, wird wiederum über NS-Einträge festgelegt.

Im Detail

Die wichtigsten Eintragstypen

• A — Domain → IPv4-Adresse, der mit Abstand häufigste Eintragstyp
• AAAA — Domain → IPv6-Adresse, das moderne Gegenstück zu A
• CNAME — Domain → anderer Domainname (Alias); darf laut Standard nicht neben anderen Eintragstypen auf demselben Namen existieren
• MX — Domain → zuständiger Mailserver, mit einer Prioritätszahl bei mehreren Einträgen
• TXT — beliebiger Freitext, z. B. zur Domainverifizierung oder für SPF/DKIM/DMARC (E-Mail-Fälschungsschutz)
• NS — Domain → autoritativer Nameserver, legt fest, wer überhaupt “das letzte Wort” über die Zone hat
• Weitere, seltenere Typen: SRV (Service-Records für bestimmte Protokolle wie SIP/XMPP), CAA (legt fest, welche Zertifizierungsstellen SSL-Zertifikate ausstellen dürfen), PTR (Reverse-DNS, IP → Domain statt umgekehrt)

Der komplette Auflösungsweg

Eine typische Abfrage läuft so ab: Ein Client fragt seinen DNS-Resolver (oft der vom Internetanbieter oder ein öffentlicher wie 1.1.1.1/8.8.8.8) nach emzett-digital.com. Ist die Antwort nicht bereits im Cache des Resolvers, fragt dieser zunächst einen der 13 Root-Server-Cluster (die oberste Ebene der DNS-Hierarchie weltweit), der ihn an den .com-TLD-Server verweist. Dieser wiederum verweist auf die per NS-Eintrag benannten autoritativen Nameserver der Domain, die schließlich den passenden A-Eintrag zurückliefern. Dieser gesamte Weg wird als “rekursive Auflösung” bezeichnet, weil der Resolver stellvertretend für den Client die komplette Kette durchläuft, statt dem Client jeden einzelnen Zwischenschritt selbst zu überlassen (was theoretisch auch möglich wäre — “iterative Auflösung”).

In der Praxis läuft dieser komplette Weg dank Caching meist nur einmal pro Resolver: Alle folgenden Anfragen (von beliebigen Clients, die denselben Resolver nutzen) werden bis zum Ablauf der jeweiligen TTL direkt aus dem Cache beantwortet, ohne erneut die komplette Kette durchlaufen zu müssen. Das ist auch der Grund, warum DNS-Änderungen nicht sofort überall wirken — sie müssen sich erst durch alle Caches “durchziehen”, was bis zum Ablauf der ursprünglichen TTL dauern kann.

Zonendateien und Verwaltung

Alle Einträge für eine Domain zusammen bilden ihre “Zone”, verwaltet über eine Zonendatei beim jeweiligen DNS-Provider (z. B. Cloudflare, Vercel DNS, dem Registrar selbst). Eine Zonendatei folgt einem standardisierten Textformat mit einem SOA-Eintrag (Start of Authority, enthält Metadaten wie den primären Nameserver und eine Seriennummer für Synchronisation) gefolgt von den eigentlichen Ressourcen-Einträgen. Änderungen an einer Zone werden über die Weboberfläche oder API des Providers vorgenommen und propagieren dann — je nach TTL der geänderten Einträge — innerhalb von Sekunden bis Stunden zu allen Resolvern weltweit.

Häufige Fallstricke

Ein klassischer Fehler ist, einen CNAME-Eintrag auf denselben Namen zu legen, unter dem bereits ein A- oder MX-Eintrag existiert — das verstößt gegen RFC 1034 und führt zu unvorhersehbarem Verhalten je nach Resolver. Ebenso vergessen viele, die TTL vor einer geplanten DNS-Migration rechtzeitig herunterzusetzen, wodurch die eigentliche Umstellung dann Stunden statt Minuten braucht, bis sie überall sichtbar ist.

Siehe auch: A-Eintrag, AAAA-Eintrag, CNAME, MX-Eintrag, TXT-Eintrag, NS-Eintrag, TTL