DNS-Einträge für Entwickler – A, CNAME, MX, TXT und die TTL, die Sie 48 Stunden warten ließen

Sie haben einen Domain gekauft, haben sie auf einen bestimmten Ort gerichtet und schauen nun auf einen Browser, der den alten Site weiteranzeigt. Oder Sie haben Ihre MX-Einstellungen falsch konfiguriert und entdeckt, dass E-Mails beginnen, abzustoßen. DNS ist eines jener Dinge, die Entwickler meistens ignorieren, bis es sie beißt – und wenn es das tut, ist der Rückkopplungsprozess langsam und schmerzhaft.

Dies ist kein Tutorial für Menschen, die noch nie von DNS gehört haben. Es ist ein Referenzwerk für Entwickler, die wissen, was eine Domain ist, aber jedes Mal, wenn sie eine neue Aufzeichnungsart benötigen, auf Stack Overflow greifen.

Wie DNS tatsächlich funktioniert (die 30-Sekunden-Version)

Wenn ein Browser eine Auflösung durchführt example.com, fragt er einen rekursiven Resolver (meistens Ihren ISP oder 8.8.8.8). Der Resolver prüft seinen Cache. Wenn ein Treffer im Cache besteht, wird die gespeicherte Antwort zurückgegeben. Wenn nicht, folgt er der DNS-Baumstruktur – von den Root-Nameservers über die TLD-Nameservers (.com) bis zu Ihrem Domain-Authentifizierungs-Nameserver – und speichert das Ergebnis für die Dauer, die der TTL vorschreibt.

Jede DNS-Aufzeichnung hat eine Art, einen Namen, einen Wert und eine TTL. Das ist alles. Die Komplexität entsteht aus dem Wissen, welche Art welche Funktion erfüllt und wie sich die Aufzeichnungen auf nicht offensichtliche Weise beeinflussen.

Die Aufzeichnungsarten, die Sie tatsächlich verwenden werden

A-Aufzeichnung – IP-Adresse für einen Hostnamen

Kopiert einen Hostnamen auf eine IPv4-Adresse. Dies ist die häufigste Aufzeichnung, die Sie berühren werden.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

Das Problem: Sie können mehrere A-Aufzeichnungen für denselben Hostnamen haben. DNS gibt alle dieser Aufzeichnungen zurück, und der Client wählt eine aus (meistens durch Rundum-Rotationsverfahren). Dies ist eine gängige, kostengünstige Lastverteilung – aber wenn einer dieser IPs ausfällt, hat DNS keine Gesundheitsprüfungen. Es wird die fehlerhafte IP weiterhin dienen, bis der TTL abgelaufen ist und Sie sie entfernen.

Für IPv6 ist das Äquivalent eine AAAA-Aufzeichnung. Gleiches Konzept, nur mit einer 128-Bit-Adresse anstatt einer 32-Bit-Adresse.

CNAME-Aufzeichnung – Alias zu einem anderen Hostnamen

Leitet einen Hostnamen auf einen anderen Hostnamen (nicht auf eine IP). Der Resolver folgt der Kette, bis er eine A-Aufzeichnung erreicht.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A – wann man welche verwendet: Wenn Sie auf einen Dienst zeigen, der Ihnen einen Hostnamen gibt (Netlify, Vercel, GitHub Pages, Heroku, die meisten CDNs), verwenden Sie eine CNAME. Wenn Sie eine statische IP haben, verwenden Sie eine A-Aufzeichnung. Einfach.

Die strenge Regel: Sie können keine CNAME auf der Zoneapex (dem reinen Domainnamen – ) platzieren example.comsein, nicht www.example.com. RFC 1034 verbietet dies, weil die Apex SOA- und NS-Aufzeichnungen halten muss, und eine CNAME mit dem gleichen Namen zu einem Konflikt führen würde. Wenn Netlify oder Vercel Ihnen sagen, eine CNAME für Ihre Root-Domain hinzuzufügen, meinen sie eigentlich, dass Sie ihren DNS-Anbieter verwenden, der ANAME oder ALIAS-Aufzeichnungen unterstützt – eine proprietäre Erweiterung, die wie eine CNAME funktioniert, aber auf der Zoneebene auf A-Aufzeichnungen resolvieren.

Auch: nie eine CNAME auf eine CNAME leiten wenn Sie es vermeiden können. Technisch zulässig, aber jeder Schritt in der Kette ist eine zusätzliche DNS-Auflösung. Wichtiger ist, dass, wenn die mittlere CNAME ausfällt, Ihre Aufzeichnung ebenfalls ausfällt.

MX-Aufzeichnung – Mail-Weiterleitung

Gibt anderen Mail-Servern an, wohin die E-Mails für Ihre Domain weitergeleitet werden sollen. MX-Aufzeichnungen haben eine Prioritätsnummer – niedrigere Zahl = höhere Priorität.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Wenn mail1 nicht verfügbar ist, versuchen die Versendungs-Server mail2. Dies ist ein ordnungsgemäßer Rückfall, nicht eine Lastverteilung – Sie teilen keine Traffic, sondern geben eine Präferenzreihenfolge an.

Der Fehler, den Entwickler machen: MX auf eine IP-Adresse oder eine CNAME zu leiten. MX-Werte müssen auf A-Aufzeichnungen (Hostnamen) zeigen, nicht auf IPs oder CNAMEs. Einige DNS-Anbieter lassen es zu, diese falsche Konfiguration zu speichern, ohne Warnung, und dann funktioniert Ihr E-Mail-System schweigend nicht.

Wenn Sie Google Workspace oder Microsoft 365 einrichten, erhalten Sie eine Reihe von MX-Aufzeichnungen. Ändern Sie die Prioritätszahlen nicht, weil Sie clever sind – das Mail-Weiterleitungsverhalten hängt davon ab, dass sie genau sind.

TXT-Aufzeichnung – beliebige Texte, hauptsächlich zur Bestätigung und E-Mail-Authentifizierung

TXT-Aufzeichnungen speichern freie Textzeichenketten. In der Praxis werden sie für drei Dinge verwendet:

• Domain-Verifikation – Google Search Console, Stripe, GitHub und hunderte anderer Dienste bitten Sie, eine TXT-Aufzeichnung hinzuzufügen, um zu beweisen, dass Sie die Domain besitzen
• SPF (Sender Policy Framework) – gibt an, welche Mail-Server erlaubt sind, E-Mails als Ihre Domain zu versenden
• DKIM und DMARC – E-Mail-Authentifizierungsaufzeichnungen, die Fälschungen verhindern

Eine SPF-Aufzeichnung sieht so aus:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Das sagt: Google und SendGrid sind erlaubt, E-Mails für diese Domain zu versenden; alles andere sollte mit Misstrauen behandelt werden (~all = weiche Ablehnung, -all = starke Ablehnung).

Eine DMARC-Aufzeichnung befindet sich bei _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Das Wichtige: Sie können pro Domain nur eine SPF-TXT-Aufzeichnung haben. Wenn Sie eine zweite hinzufügen (weil ein neuer Dienst Sie dazu auffordert), existieren beide Aufzeichnungen, Mail-Server sehen konfliktierende Richtlinien, und die E-Mail-Authentifizierung bricht zusammen. Fügen Sie sie stattdessen zusammen: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

NS-Aufzeichnung – Nameserver-Delegation

Gibt an, welche Nameserver für Ihre Domain autorisierend sind. Sie legen diese normalerweise bei Ihrem Domain-Registrator fest, nicht direkt in Ihrer DNS-Zone. Wenn Sie von einem DNS-Anbieter zu einem anderen wechseln (z. B. von GoDaddy’s Nameservers zu Cloudflare), ändern Sie die NS-Aufzeichnungen auf dem Registrator-Ebene.

Die NS-Aufzeichnungsverbreitung ist der Grund, warum Domain-Wechsel langsam sind. NS-TTLs sind oft 24–48 Stunden, und Registrator-Änderungen haben ihre eigene Verbreitungsverzögerung zusätzlich dazu.

TTL – die Zahl, die Sie 48 Stunden warten ließen

TTL (Time To Live) ist eine Zahl in Sekunden. Sie sagt den Cache-Resolven, wie lange sie eine Antwort speichern sollen, bevor sie erneut nachfragt. Ein TTL von 300 bedeutet fünf Minuten. Ein TTL von 172800 bedeutet 48 Stunden.

Wenn Sie eine DNS-Aufzeichnung ändern, wird die alte Antwort überall noch für bis zu die alte TTLgespeichert. Wenn Ihre A-Aufzeichnung einen TTL von 48 Stunden hatte und Sie gerade die IP geändert haben, werden einige Benutzer bis zu zwei Tage lang die alte Server erreichen – und es gibt nichts, was Sie tun können, sobald die Änderung vorgenommen wurde.

Die Lösung ist, den TTL vor der Änderung zu senken. Standardverfahren bei geplanten Wechseln:

1. Senken Sie den TTL auf 300 (5 Minuten) mindestens 48 Stunden vor dem Wechsel – Sie müssen zuerst warten, bis der alte hohe TTL abgelaufen ist
2. Führen Sie die DNS-Änderung durch
3. Warten Sie 5–10 Minuten auf die Ausbreitung
4. Heben Sie den TTL wieder auf einen sinnvollen Wert (3600–86400) auf, sobald Sie sicherstellen, dass die neue Konfiguration funktioniert

Wenn Sie Schritt 1 vergessen und direkt zu Schritt 2 mit einem hohen TTL gehen, sind Sie gefangen. Sie können den TTL jetztsenken, aber das verkürzt nur die Wartezeit für Resolven, die es noch nicht gespeichert haben. Jeder, der die Aufzeichnung bereits gespeichert hat, muss den ursprünglichen TTL warten.

Schnelle Referenz

Aufzeichnung	Leitet auf	Gewöhnlicher Gebrauch	Gefährdung
A	IPv4-Adresse	Hostname → Server-IP	Keine Gesundheitsprüfungen – fehlerhafte IPs bleiben in der Rotation, bis der TTL abgelaufen ist
AAAA	IPv6-Adresse	Hostname → IPv6-Server	Einfach zu vergessen, eine A-Aufzeichnung neben der A-Aufzeichnung hinzuzufügen, um Dual-Stack-Unterstützung zu erhalten
CNAME	Ein weiterer Hostnamen	Aliases, CDN/PaaS-Weiterleitung	Kann nicht auf der Zoneapex verwendet werden; MX/NS können keine CNAME leiten
MX	Hostname (A-Aufzeichnung)	E-Mail-Weiterleitung	Der Wert muss ein Hostnamen sein, nicht eine IP; Prioritätszahlen sind wichtig
TXT	Freier Text	SPF, DKIM, DMARC, Domain-Verifikation	Nur eine SPF-Aufzeichnung pro Domain erlaubt – fügen Sie sie nicht hinzu, sondern fügen Sie sie zusammen
NS	Nameserver-Hostname	DNS-Delegation	Änderungen erfolgen über den Registrator und breiten sich langsam aus
CAA	CA-Domain	Welche CAs SSL-Zertifikate für Ihre Domain ausstellen dürfen	Leicht, sich selbst auszuschalten, wenn Sie die Konfiguration falsch machen

Dinge, die Ihnen Zeit sparen werden

Verwenden Sie dig direkt, nicht über ein Webtool. dig @8.8.8.8 example.com A umgeht Ihren lokalen Resolver und zeigt genau, was Google’s DNS sieht. Fügen Sie +short für nur die Antwort hinzu. Fügen Sie +trace zur vollständigen Auflösungskette hinzu.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Prüfen Sie den TTL vor jeder Migration. Führen Sie dig example.com A aus und schauen Sie sich die Zahl in der dritten Spalte der Antwortabschnitt an. Das ist die Zeit (in Sekunden), die Sie warten könnten, wenn Sie die Aufzeichnung jetzt ohne Voraussetzung des TTL-Abstiegs ändern.

Cloudflare’s proxied Records zeigen nicht Ihre echte IP. Wenn Sie Cloudflare’s orangene Wolke auf eine Aufzeichnung aktivieren, ist die A-Aufzeichnung, die der Welt angezeigt wird, die IP von Cloudflare, nicht Ihre eigene. Dies ist normalerweise das, was Sie wollen, um DDoS-Schutz zu erhalten – aber es bedeutet, dig wird Ihre Server-IP nicht anzeigen, und Werkzeuge, die direkt Ihre IP erkunden, funktionieren nicht wie erwartet.

Das könnte Ihnen auch gefallen