DNS-Einträge erklärt: von DNS über A-Record bis MX

Sie befinden sich: Home > News Archiv > Webmaster > DNS-Einträge erklärt...

Eine falsche Signatur legte am 5. Mai 2026 das halbe deutsche Netz lahm. DNS-Einträge entscheiden über Erreichbarkeit, Mail und Zertifikate. Welche Sie brauchen, wie die TTL-Strategie wirkt und woran Umzüge scheitern.

Am Abend des 5. Mai 2026 war ein großer Teil des deutschen Internets weg. Amazon.de, DHL, Steam, Web.de, eBay, das Ticketsystem der Bahn: rund drei Stunden lang nicht erreichbar. Kein Angriff, kein Serverausfall. Eine einzige fehlerhafte Signatur in der .de-Zone hat gereicht. Wer versteht, wie DNS-Einträge arbeiten, versteht auch, warum so etwas möglich ist und was er an der eigenen Zone besser macht.

Domain Name System: was bei einer Abfrage im DNS passiert

Das Domain Name System übersetzt Domainnamen in IP-Adressen. Aus www.example.de wird eine IPv4-Adresse wie 185.12.34.56 oder eine IPv6-Adresse wie 2001:db8::1. Der Vergleich mit dem Telefonbuch trifft es gut: Sie merken sich den Namen, das System schlägt die Nummer nach. Die Arbeit erledigen DNS-Server, und was die ausliefern, sind Ihre DNS-Einträge.

Ist nichts zwischengespeichert, läuft die Anfrage über sechs Stationen. Zuerst der Browser-Cache, dann der Cache des Betriebssystems. Danach übernimmt der rekursive Resolver, meist der Ihres Providers, manchmal ein öffentlicher wie 8.8.8.8 von Google, 1.1.1.1 von Cloudflare oder 9.9.9.9 von Quad9. Der fragt bei einem der 13 Root-Server-Adressen nach, wird an den TLD-Server für .de weitergereicht und landet schließlich beim Nameserver der Domain. Dieser DNS-Server ist autoritativ für die Zone, er hält die echten Werte und antwortet verbindlich.

Diese ganze Kette läuft nur beim ersten Mal ab. Danach hat der Resolver die Antwort im Cache, und genau das macht DNS trotz weltweiter Verteilung schnell.

Daraus folgt der wichtigste Satz dieses Artikels: Propagation gibt es nicht. DNS-Einträge werden nicht ins Netz gepusht. Aktualisiert wird sofort nur der autoritative DNS-Server. Alle anderen halten die alte Antwort so lange, wie deren Gültigkeitsdauer es erlaubt. Deshalb sieht ein Kollege die neue Seite sofort und Sie noch stundenlang die alte. Die berüchtigten 24 bis 48 Stunden sind kein Naturgesetz, sondern der schlechteste Fall ohne Vorbereitung.

Wer Ihre DNS-Einträge verwalten darf: fünf Rollen

Bevor Sie einen einzigen Eintrag anfassen: Klären Sie, wer Ihre DNS-Einträge überhaupt verwalten darf und wer nur die Domain hält. Hier entstehen die meisten Missverständnisse, besonders im Gespräch mit dem Support.

Rolle	Aufgabe	Beispiel
Registry	betreibt die zentrale Datenbank einer Endung	DENIC für .de
Registrar	verkauft und verwaltet die Domain gegenüber der Registry	IONOS, united-domains, netcup
DNS-Hoster	betreibt die autoritativen Nameserver, verwaltet die Zone	oft der Registrar, kann aber Cloudflare sein
Webhoster	stellt den Server für die Website bereit	Hetzner, All-Inkl
Mail-Hoster	betreibt die Mailserver der Domain	Microsoft 365, Google Workspace, mailbox.org

Diese fünf müssen nicht dieselbe Firma sein, und in der Praxis sind sie es selten. Die Domain kann bei united-domains liegen, die Zone bei DENIC-fähigen Nameservern eines anderen Anbieters, die Website bei Hetzner und die Mail bei Microsoft. Diese Trennung ist der Grund, warum sich Dinge einzeln umziehen lassen. Sie ist aber auch der Grund, warum nach einem Umzug plötzlich die Mails fehlen.

Typen von DNS-Einträgen: A-Record, AAAA-Record, CNAME, MX

Fachlich heißen sie Resource Records, im Alltag sagt jeder DNS-Records oder eben DNS-Einträge. Ein einzelner DNS-Eintrag besteht aus vier Teilen: Name oder Host (@ steht für die Domain selbst, sonst www oder eine andere Subdomain), Typ, Wert und die TTL, ausgeschrieben Time to Live. Bei MX und SRV kommt eine Priorität dazu. Jeder Eintrag gilt für genau eine Domain oder Subdomain. Ein Record darf dabei mehrfach vorkommen: Mehrere A-Records auf denselben Namen verteilen die Anfragen reihum auf mehrere Server.

Typ	Wofür	Häufiger Fehler
A	Name auf IPv4	alter A-Record nach Serverwechsel vergessen
AAAA	Name auf IPv6	zeigt auf den alten Server, IPv6-Besucher landen woanders
CNAME	Alias auf einen anderen Namen	auf der Domain selbst gesetzt, das ist verboten
MX	Mailserver mit Priorität	zeigt auf eine IP oder auf einen CNAME
TXT	Freitext, Verifizierung, Mail-Authentifizierung	mehrere widersprüchliche SPF-Einträge
NS	delegiert die Zone an Nameserver	unvollständig nach dem Umzug
SOA	Verwaltungsdaten der Zone	wird automatisch gepflegt
SRV	Dienst mit Port und Protokoll	falscher Port oder falsche Priorität
CAA	erlaubte Zertifizierungsstelle	blockiert die eigene CA, Zertifikat schlägt fehl
PTR	Rückwärtsauflösung von IP auf Name	fehlt oder passt nicht, Mails werden abgelehnt

Zwei Kürzel lohnen die Auflösung. SOA steht für Start of Authority und markiert den Anfang jeder Zone, mit primärem DNS-Server, Kontaktadresse, Seriennummer und Zeitgebern. Und AAAA ist schlicht der vierfach lange Bruder des A-Records, weil eine IPv6-Adresse viermal so viel Platz braucht. Ein AAAA-Record ist heute kein Extra mehr, sondern Grundausstattung.

Drei Regeln davon kosten in der Praxis am meisten Zeit.

Der CNAME darf nicht auf die Domain selbst. Die Wurzel Ihrer Zone muss zwingend SOA- und NS-Einträge tragen, und ein CNAME duldet laut Standard keine anderen Einträge neben sich. Für example.de brauchen Sie also A und AAAA, ein CNAME-Eintrag funktioniert nur für Subdomains wie www oder shop. Manche Anbieter umgehen das mit ALIAS, ANAME oder CNAME-Flattening: Der Server löst das Ziel selbst auf und liefert dem Besucher normale A-Antworten. Cloudflare hat das Flattening bekannt gemacht. Bei den fünf großen deutschen Hostern IONOS, STRATO, Hetzner, All-Inkl und netcup gibt es das nativ bei keinem einzigen.

Der MX zeigt auf einen Hostnamen, nie auf eine IP und nie auf einen CNAME. RFC 5321 verbietet beides. Das gilt auch dann, wenn Ihr Anbieter Flattening kann: Flattening löst die Apex-Frage, nicht die MX-Frage.

A und MX dürfen auseinanderlaufen. Website bei Hetzner, Mail bei Microsoft 365, das ist kein Fehler, sondern der Normalfall. Wer das nicht weiß, zieht beim Hosterwechsel den MX mit um und wundert sich, warum keine Mail mehr ankommt.

Der PTR ist der einzige Eintrag in dieser Liste, den Sie nicht in Ihrer eigenen Zone setzen. Er gehört dem Inhaber der IP-Adresse, also Ihrem Hoster. Stimmen Hin- und Rückrichtung nicht überein, lehnen viele Empfänger Ihre Mails ab. Mehr dazu im Ratgeber zur E-Mail-Zustellbarkeit.

SPF, DKIM und DMARC richtig konfiguriert

Drei Einträge entscheiden darüber, ob Ihre Mails im Posteingang landen oder im Spam, und alle drei sind technisch schlicht ein TXT-Record. SPF listet die Server, die für Ihre Domain senden dürfen. DKIM hinterlegt den öffentlichen Schlüssel, mit dem Empfänger die Signatur prüfen, und wird von vielen Anbietern als CNAME statt als TXT ausgeliefert. DMARC unter _dmarc sagt dem Empfänger, was mit Mails geschehen soll, die durchfallen.

Der häufigste Fehler ist hier kein fehlender, sondern ein doppelter Eintrag. Zwei SPF-Einträge nebeneinander sind ungültig, die Prüfung schlägt fehl, und es merkt niemand, bis die Zustellrate einbricht. Wie Sie die drei sauber aufsetzen, steht in der Anleitung zu SPF, DKIM und DMARC.

Subdomains, Dynamic DNS und Sonderfälle

Subdomains wie blog.example.de legen Sie in der eigenen Zone an, per A- und AAAA-Eintrag oder per CNAME auf einen bestehenden Namen. Sie können sie auch abgeben: Setzen Sie NS-Einträge für die Subdomain, verwaltet ein fremder Nameserver diesen Zweig allein. Das ist der saubere Weg, wenn eine Agentur nur einen Teilbereich betreuen soll und nicht gleich die ganze Zone.

Wer zu Hause eine wechselnde IP hat, stolpert über Dynamic DNS. Dabei meldet ein kleiner Client die neue Adresse an den Anbieter, der den A-Record automatisch nachzieht. Für eine Website beim Hoster brauchen Sie das nicht, für den Zugriff auf die eigene Fritzbox oder einen Heimserver schon.

TTL pro DNS-Eintrag: die Drei-Phasen-Strategie

Die TTL sagt in Sekunden, wie lange ein Resolver eine Antwort behalten darf. Übliche Werte sind 300 für fünf Minuten, 3600 für eine Stunde und 86400 für einen Tag. Sie lässt sich für jeden Ihrer DNS-Einträge getrennt setzen, und sie ist der einzige Hebel, den Sie gegen lange Umstellzeiten haben.

1. 24 bis 48 Stunden vorher: TTL des betroffenen Eintrags auf 300 senken. Den Wert selbst noch nicht ändern. Der Grund ist der wunde Punkt, an dem die meisten scheitern: Erst muss die alte, hohe TTL überall abgelaufen sein, damit die neue niedrige überhaupt greift.
2. Umstellung: Jetzt den Wert ändern. Weil die TTL niedrig ist, greift das meist binnen Minuten bis zu einer Stunde weltweit.
3. Nach mindestens 48 Stunden stabilem Betrieb: TTL wieder auf 3600 oder 86400 setzen.

Solange die TTL unten ist, kostet ein Rollback fünf bis zehn Minuten statt eines Tages. Das allein rechtfertigt den Aufwand.

Dauerhaft niedrige Werte sind trotzdem keine gute Idee. Sie erhöhen die Last auf den autoritativen DNS-Servern und die Zahl der Anfragen. Manche Resolver ignorieren extrem niedrige TTLs ohnehin und erzwingen ein Minimum, NameSilo etwa 3600 Sekunden. Für den Normalbetrieb sind 3600 bis 86400 richtig, die 300 sind ein Werkzeug für den Umzugstag.

Nameserver wechseln: DNS-Server und Registrar trennen

Das sind zwei verschiedene Vorgänge, und sie werden ständig in einen Topf geworfen.

Beim Nameserverwechsel ziehen Sie die Zone zu einem anderen DNS-Hoster um. Die Reihenfolge entscheidet: erst beim neuen Anbieter alle DNS-Einträge nachbauen, lückenlos, also A, AAAA, MX, TXT, CNAME und CAA. Erst danach beim Registrar die NS-Einträge umstellen. Wer es andersherum macht, hat für die Dauer der Umstellung eine leere Zone. Der Klassiker dabei ist ein vergessener Verifizierungs-TXT, worauf die Google Search Console die Bestätigung verliert und Drittdienste ausfallen.

Beim Registrarwechsel wandert die Zuständigkeit für die Domain. Kern ist der Auth-Code, bei .de AuthInfo genannt, das Verfahren heißt ChProv, die alte Bezeichnung KK-Antrag hält sich hartnäckig. Der Ablauf: beim bisherigen Anbieter kündigen und die AuthInfo anfordern, der hinterlegt sie verschlüsselt bei der DENIC und teilt sie Ihnen mit, der neue Anbieter startet damit den Transfer. Der Code ist höchstens 30 Tage gültig und 8 bis 16 Zeichen lang. Stimmt er, ist die Domain meist binnen Minuten umgezogen.

Mauert der alte Anbieter, können Sie bei .de die AuthInfo2 direkt bei der DENIC beantragen. Die schickt den Code kostenpflichtig per Einschreiben an die Adresse im Inhaber-Datensatz. Und ein Punkt, der regelmäßig überrascht: Zone und E-Mail ziehen beim Transfer nicht automatisch mit. Beides müssen Sie vorher nachbauen oder danach neu einrichten.

Bei .de zählt rechtlich allein der Inhaber. Die früheren Kontaktrollen admin-c und tech-c hat die DENIC 2018 abgeschafft. Inhaber ohne Sitz in Deutschland benennen auf Aufforderung einen Zustellungsbevollmächtigten. Ein Dispute-Eintrag sperrt die Domain bei einem Rechtsstreit gegen Übertragung, gilt ein Jahr und ist verlängerbar. Die Domain bleibt nutzbar, geht aber nach einer Löschung direkt an den Antragsteller.

Für .com und andere generische Endungen gilt die ICANN-Transferregel: Nach Registrierung, Transfer oder Änderung der Inhaberdaten sperrt eine Frist von 60 Tagen den nächsten Wechsel. Im März 2025 hat ICANN alle 47 empfohlenen Änderungen beschlossen, darunter die Umbenennung des AuthInfo Code in Transfer Authorization Code und eine Verkürzung der Sperre auf 30 Tage. Umgesetzt wird das frühestens 2026. Für .de und .eu gilt diese Policy nicht.

Was passiert, wenn eine Domain abläuft

Endung	Nach Ablauf	Frist
.de	TRANSIT bei der DENIC oder Redemption Grace Period	30 Tage, danach frei
.com, .net, .org	Redemption Period, Status HOLD	30 Tage, dann 5 Tage Pending Delete
.eu	Quarantäne	40 Tage, danach frei

Das TRANSIT-Verfahren bei .de ist ein Sicherheitsnetz: Fällt der Provider weg, verwaltet die DENIC die Domain vorübergehend selbst und schreibt den Inhaber an. Der kann dann umziehen, zu DENICdirect wechseln oder löschen. Bei generischen Endungen wird es teuer, ein Restore aus der Redemption Period kostet oft 100 bis 150 Euro oder mehr.

Der unterschätzte Teil ist nicht der Verlust der Website, sondern die Mail. Wer eine abgelaufene Domain schnappt, kann eine Catch-All-Adresse einrichten und damit Passwort-Zurücksetzen-Mails und Login-Links abfangen, solange irgendwo noch alte Adressen hinterlegt sind. Deshalb gehören Auto-Renew und aktuelle Kontaktdaten zur Grundausstattung. Die saubersten DNS-Einträge nützen nichts, wenn die Domain darunter wegläuft.

Fehlersuche: welcher Record die Störung verursacht

Bevor Sie tiefer graben: Fast alles auf dieser Liste lässt sich an den DNS-Einträgen selbst ablesen. Prüfen Sie die Zone, bevor Sie den Server verdächtigen.

Was Sie sehen	Woran es meist liegt
Website nach der Umstellung nicht erreichbar	alter A-Record noch im Cache, TTL war zu hoch
www geht, die Domain ohne www nicht	A-Record am Apex fehlt, oder umgekehrt der CNAME für www
Mails kommen nach dem Hosterwechsel nicht mehr an	MX vergessen oder auf eine IP gesetzt
DNS_PROBE_FINISHED_NXDOMAIN	Name existiert im DNS nicht: falsche NS, fehlender A-Record, Domain nicht registriert
Zertifikatsfehler nach der Umstellung	CAA blockiert die Zertifizierungsstelle
Domain global weg, obwohl die Zone stimmt	gebrochene DNSSEC-Kette, Resolver liefern SERVFAIL

Wenn nach einer Umstellung plötzlich das Zertifikat klemmt, sehen Sie zuerst im CAA nach. Ohne CAA darf jede Stelle ausstellen, mit CAA 0 issue "letsencrypt.org" eben nur Let's Encrypt. Zertifizierungsstellen müssen den Eintrag seit dem 8. September 2017 prüfen. Wie kurz Zertifikate künftig laufen, steht im Artikel zu SSL-Zertifikaten ab 2026.

Werkzeuge, mit denen Sie DNS-Records prüfen

Werkzeug	Wofür	Beispiel
nslookup	schnelle Abfrage, überall vorhanden	nslookup -type=MX example.de
dig	die genaue Analyse, Standard unter Fachleuten	dig example.de A +short
Resolve-DnsName	dig-Ersatz in der PowerShell	Resolve-DnsName example.de -Type MX
dnschecker.org	weltweite Karte, wo die Änderung schon greift	Domain und Typ eingeben
MXToolbox	Mail-Diagnose und Blacklists	SuperTool
intoDNS	Gesundheitscheck der ganzen Zone	Warnungen durchgehen
DNSViz	DNSSEC sichtbar machen	Vertrauenskette prüfen

Fragen Sie beim Umstellen gezielt einzelne Resolver ab: dig example.de A @8.8.8.8, dann @1.1.1.1 und @9.9.9.9. Liefern alle denselben Wert mit unterschiedlicher Rest-Laufzeit, läuft die Umstellung. Eine weltweite Übersicht liefert dnschecker.org, die DNSSEC-Kette macht DNSViz sichtbar.

Den lokalen Cache leeren Sie unter Windows mit ipconfig /flushdns, unter macOS mit sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Dass macOS dabei nichts ausgibt, ist normal. Chrome hat zusätzlich einen eigenen Cache unter chrome://net-internals/#dns.

Und wenn ein Kollege sagt, bei ihm gehe es doch: Das ist fast immer der Cache. Sein Rechner, sein Router oder sein Resolver hält die alte Antwort. Wer zum Testen den Resolver wechselt, sieht die neue Antwort nur deshalb, weil der neue Resolver den alten Wert nie hatte.

DNSSEC: Schutz und Ausfallrisiko in einem

DNSSEC signiert die ausgelieferten DNS-Einträge kryptografisch. Ein Resolver prüft die Signatur und verwirft manipulierte Antworten, das schützt vor Cache-Poisoning und Spoofing. Gegen Ausfälle hilft es nicht, und mitlesen kann trotzdem jeder, der den Verkehr sieht. Aktiviert wird es, indem die Zone signiert und beim Registrar ein DS-Eintrag in der übergeordneten Zone hinterlegt wird. Der schließt die Vertrauenskette.

Genau diese Kette ist die häufigste vermeidbare Totalausfall-Ursache. Wer den Nameserver wechselt, ohne vorher den DS zu löschen, hat im Elternbereich einen Verweis auf Schlüssel, die es beim neuen Anbieter nicht gibt. Validierende Resolver antworten mit SERVFAIL, und die Domain ist komplett weg. Nicht langsam, nicht teilweise, sondern weg.

Die richtige Reihenfolge lautet deshalb: DS-Eintrag beim Registrar löschen, warten bis dessen Laufzeit in der Elternzone abgelaufen ist (bei vielen Endungen 24 bis 48 Stunden, mit dig DS example.de nachsehen), dann erst die Nameserver umstellen, und ganz zuletzt beim neuen Anbieter DNSSEC wieder einschalten und den neuen DS hinterlegen. IONOS weist darauf hin, dass allein die Deaktivierung mindestens acht Stunden braucht, bis alle Systeme sie kennen.

Dass auch die Profis das trifft, hat der Ausfall vom 5. Mai 2026 gezeigt. Bei einem routinemäßigen Schlüsselwechsel, den die DENIC alle fünf Wochen automatisch fährt, gelangte eine ungültige Signatur in die produktive .de-Zone. Die Ursache lag laut der DENIC-Analyse vom 8. Mai in eigenem Code der dritten Signatur-Systemgeneration, die im April 2026 in Betrieb gegangen war: Für denselben Key-Tag entstanden drei verschiedene Schlüsselpaare statt eines einzigen, eines je Hardware-Sicherheitsmodul. Nur etwa ein Drittel der Signaturen ließ sich noch prüfen, den Rest mussten die Resolver verwerfen. Um 21:57 Uhr begann die Störung, ab 00:08 Uhr lief wieder eine korrekte Zone, um 01:15 Uhr am 6. Mai war alles hergestellt.

Zwei Details daran sind für die eigene Planung lehrreich. Cloudflare und Google Public DNS schalteten die DNSSEC-Prüfung für .de vorübergehend ab, damit Seiten wieder erreichbar wurden. Und betroffen waren auch Domains ohne eigenes DNSSEC, weil in der .de-Zone selbst die Delegationen und die Nachweise fehlender Einträge signiert sind. Dabei sind laut ICANN nur rund 3,6 Prozent der .de-Domains signiert, bei etwa 18 Millionen Domains allerdings immer noch Hunderttausende.

Für kleine Websites heißt das: DNSSEC ja, aber nur mit sauberem Änderungsmanagement. Wer die Zone nicht überwacht und beim Umzug den DS vergisst, handelt sich ein Risiko ein, das größer ist als der Schutz, den er gewinnt.

DNS ist ein Single Point of Failure

Jeder Anbieter betreibt mindestens zwei Nameserver, damit der Ausfall eines Servers nicht die Domain lahmlegt. Das Risiko liegt inzwischen aber woanders, nämlich in der Abhängigkeit von einem einzigen großen Anbieter.

Am 20. Oktober 2025 legte ein DNS-Fehler in der AWS-Region us-east-1 weite Teile des Internets für rund 15 Stunden lahm. Laut dem Bericht von Amazon war es ein latenter Wettlauf zweier Prozesse in der automatischen DNS-Verwaltung von DynamoDB, der die Adresseinträge des Dienstes aus Route 53 löschte. Am 18. November 2025 folgte Cloudflare: Eine geänderte Berechtigung in ClickHouse erzeugte eine Konfigurationsdatei mit Duplikaten, die das interne Limit von 200 Merkmalen sprengte, worauf das Kernsystem Fehler 5xx auslieferte. Kein Angriff, in beiden Fällen. Betroffen waren unter anderem X, ChatGPT, Spotify und Canva.

Für geschäftskritische Domains ist die Konsequenz eine zweite, unabhängige DNS-Anbindung. Für eine Vereinsseite ist das übertrieben, für einen Shop, dessen Umsatz an der Erreichbarkeit hängt, ist es eine Rechnung, die sich schnell aufmacht.

Domains gegen Übernahme absichern

Angreifer übernehmen Domains selten über technische Lücken, sondern über gekaperte Konten beim Registrar oder gestohlene Auth-Codes. Vier Maßnahmen decken das Meiste ab:

• Transfer-Lock bei generischen Endungen dauerhaft an, und nur für einen gewollten Transfer kurz lösen. Bei .de gibt es diesen klassischen Registrar-Lock nicht, dort schützt das Providerverfahren.
• Registry Lock bei der DENIC für wirklich kritische Domains. Änderungen an Daten, Nameservern und Provider werden dann manuell geprüft und von einem benannten Kontakt freigegeben. Kostenpflichtig, je nach Endung meist 200 bis 650 Euro im Jahr.
• Zwei-Faktor-Anmeldung für das Registrar- und DNS-Konto, dazu aktuelle Kontaktdaten und aktives Auto-Renew.
• Dispute-Eintrag bei .de als rechtliche Absicherung, solange ein Streit um Domain-Namen läuft.

Neu 2026: IPv6, HTTPS-Records und verschlüsseltes DNS

IPv6 ist keine Kür mehr. Nach Googles Statistik lag der IPv6-Anteil für Deutschland Ende 2024 bei rund 76 Prozent, weltweit überschritt der Wert im April 2026 erstmals die Hälfte. Fehlt der AAAA unter Ihren DNS-Einträgen oder zeigt er auf den alten Server, schickt das einen erheblichen Teil Ihrer Besucher ins Leere. Unbemerkt noch dazu, weil Sie selbst vermutlich über IPv4 testen.

Verschlüsseltes DNS über DoH auf Port 443 oder DoT auf Port 853 verbirgt die Anfragen zwischen Gerät und Resolver. An Ihrer Zone ändert das nichts. Für die Fehlersuche ist es trotzdem relevant, weil Firefox den lokalen Resolver dabei umgeht und Ihre Messung anders ausfällt als erwartet.

HTTPS- und SVCB-Einträge nach RFC 9460 sind das moderne Gegenstück zum A-und-AAAA-Paar. Sie liefern Verbindungshinweise schon in der DNS-Antwort, beschleunigen den Aufbau und erlauben, anders als der CNAME, eine Umleitung an der Wurzel der Domain. Firefox fragt sie seit Mai 2020 ab, Apple seit September 2020, Chrome seit Dezember 2020, und Hetzner unterstützt sie bereits in seiner Oberfläche. Wichtig: A und AAAA parallel behalten, ältere Programme ignorieren die neuen Typen. Eng damit verbunden ist Encrypted Client Hello, das den Servernamen im TLS-Handshake verbirgt und seine Schlüssel über eben diese Einträge verteilt.

Nebenbei: Im Juni 2026 wurde die 18-millionste .de-Domain registriert.

Checkliste: gängige DNS-Einträge, die jede Website braucht

Diese DNS-Einträge sollte jede Website haben. Gehen Sie die Liste einmal gegen Ihre eigene Zone durch, erfahrungsgemäß fehlen AAAA, CAA und DMARC am häufigsten.

• A auf @ mit der IPv4 des Webservers, AAAA auf @ mit der IPv6
• CNAME für www auf die Domain, oder alternativ eigene A- und AAAA-Einträge
• MX auf den Mailserver, mit Priorität, als Hostname
• TXT mit SPF, DKIM (oft als CNAME), DMARC unter _dmarc
• CAA mit der Zertifizierungsstelle, die ausstellen darf
• Verifizierungs-TXT für Google Search Console und andere Dienste
• NS vollständig und korrekt

Und vor jeder Änderung: Zone exportieren, TTL rechtzeitig senken, einen Zeitpunkt mit wenig Verkehr wählen, die Änderung notieren, danach aus mehreren Resolvern nachmessen. Bei aktivem DNSSEC zuerst der DS.

Wo Sie das im Kundenbereich finden, heißt überall anders: bei IONOS „DNS-Einstellungen“, bei STRATO „Domainverwaltung, DNS“, bei Hetzner „Console, DNS“ oder konsoleH, bei All-Inkl „KAS, Tools, DNS-Einstellungen“, bei netcup „CCP, Domains, DNS“. Zwei Eigenheiten sind gut zu wissen: All-Inkl lässt Nameserver-Änderungen bei selbst registrierten Domains nur über den Support zu, und Hetzner legt bei neuen Zonen keine Standardeinträge an.

Häufige Fragen zu DNS-Einträgen

Diese Fragen zu DNS-Einträgen tauchen im Alltag mit Domain und Hosting immer wieder auf.

So gehen Sie jetzt vor

Exportieren Sie zuerst Ihre Zone und legen Sie die Datei irgendwo ab, wo Sie sie im Ernstfall auch finden. Das dauert zwei Minuten und ist die einzige echte Rückversicherung. Danach gehen Sie die Checkliste oben durch und ergänzen die DNS-Einträge, die fehlen. Wer seine Zone einmal sauber konfiguriert hat, fasst sie jahrelang nicht mehr an. Steht eine Umstellung an, senken Sie die TTL zwei Tage vorher und nicht am selben Morgen. Und wenn Sie ohnehin gerade in der Zone sind: Schalten Sie im Registrar-Konto die Zwei-Faktor-Anmeldung ein und prüfen Sie, ob Auto-Renew aktiv ist. Wenn als Nächstes der Server dran ist, arbeiten Sie jetzt die Checkliste zum Website-Umzug durch, dort steht der Rest.

DNS Domain TTL Hosting Webmaster

Webung: Hier bekommen Sie PHP fähigen Webspace der mit Ökostrom betrieben wird ab bereits 2 Euro/ Monat für ihre Homepage. Zusätzlich ist eine eigene Internetadresse mit enthalten.

Neusten News in der Kategorie "Webmaster"

• Google Maps DSGVO: Karte einbinden oder besser ersetzen Eine Google-Karte auf der Kontaktseite lädt Daten von Google, bevor je...

• Online-Terminbuchung DSGVO-konform: Calendly und Co. 64 Prozent der Deutschen haben schon online einen Arzttermin gebucht. ...

• PHP Sicherheitslücke: Notfallupdate gegen PHP2Shell Zwei kritische Sicherheitslücken im PHP-Kern lassen Angreifer ohne Pas...

• Bilder rechtssicher verwenden: Abmahnungen vermeiden Fast jedes Foto im Netz ist geschützt, auch der Handy-Schnappschuss. W...

• Zahlungsarten im Onlineshop: Kosten, Recht, Auswahl Ohne PayPal und Kauf auf Rechnung fehlt über die Hälfte der gewohnten ...

• Google Analytics Alternative 2026: DSGVO-konform messen Rund 60 Prozent der Besucher lehnen die Einwilligung ab. Wer eine Goog...

• Domain rechtssicher registrieren: Fallen vermeiden Seit April 2026 prüft die DENIC die Daten von .de-Inhabern, falsche An...

• Onlineshop rechtssicher 2026: Widerrufsbutton, GPSR Wer seinen Onlineshop rechtssicher führen will, hat 2026 neue Baustell...

• WordPress Wartungsvertrag: Leistungen, Kosten, Haftung Ein WordPress-Wartungsvertrag für 30 Euro im Monat klingt nach Sorglos...

• Website erstellen lassen: ehrlicher Kostenvergleich Zehn Euro im Monat oder 12.000 einmalig: Wer eine Website erstellen la...