Webhosting 6 Min Lesezeit

Domain & DNS richtig einrichten 2026 – A, CNAME, MX erklärt

Warum DNS 2026 komplexer ist als je zuvor

DNS war lange Zeit ein „einmal einstellen und vergessen"-Thema. 2026 sieht das anders aus: E-Mail-Provider verlangen SPF, DKIM und DMARC, Let's Encrypt prüft CAA-Records, Gameserver brauchen SRV-Einträge für Voice und Minecraft-Ports, und Cloudflare, Hetzner und Route 53 bieten unterschiedliche Feature-Sets. Wer seine Zone falsch aufsetzt, verliert Mails, bekommt keine Zertifikate oder wundert sich über 4 Stunden Downtime nach einem Umzug.

Dieser Guide erklärt dir die wichtigsten Record-Typen praxisnah — A, AAAA, CNAME, MX, TXT, SRV, CAA und NS — mit konkreten Werten, TTL-Empfehlungen und Debugging-Befehlen. Du erfährst außerdem, wie du eine Migration ohne Ausfall planst und welche Preise 2026 für DNS-Hosting realistisch sind.

Zielgruppe sind Server-Admins, DevOps-Engineers und Gamer, die ihre eigene Domain verwalten — egal ob auf einem cPanel-Hosting für 4,99 €/Monat oder in einer selbstgebauten BIND-Umgebung auf einem 5-€-VPS.

DNS-Grundlagen: Zone, Nameserver und TTL

Jede Domain gehört zu einer Zone, die auf mindestens zwei autoritativen Nameservern (NS-Records) liegt. Diese Nameserver werden bei der Registry hinterlegt — bei .de ist das die DENIC, bei .com die ICANN-akkreditierte Registry Verisign. Fragt ein Resolver nach example.de, läuft die Kette Root → TLD → autoritativer NS ab.

Die TTL (Time To Live) bestimmt in Sekunden, wie lange ein Resolver einen Record cachen darf. Typische Werte:

Wichtig: TTL wird in Sekunden angegeben, nicht in Minuten. Ein häufiger Fehler ist TTL 3600 als „3600 Minuten" zu interpretieren — das wären 60 Stunden. Senke die TTL mindestens 24 Stunden vor einem Serverwechsel auf 300, damit die Propagation nach dem Umschalten schnell greift.

A- und AAAA-Records: IPv4 und IPv6 richtig setzen

Der A-Record verbindet einen Hostnamen mit einer IPv4-Adresse, der AAAA-Record mit einer IPv6-Adresse. Beide sind unabhängig — ein Client mit IPv6-Priorität nutzt AAAA, wenn vorhanden. Fehlt AAAA, fällt er auf A zurück.

example.de.      3600  IN  A     203.0.113.42
example.de.      3600  IN  AAAA  2001:db8::1
www.example.de.  3600  IN  A     203.0.113.42
mc.example.de.   300   IN  A     198.51.100.77

Für Gameserver empfiehlt sich ein eigener Subdomain-A-Record (z. B. mc.example.de), damit du die IP später ändern kannst, ohne Spieler zu verwirren. Bei Webhosting mit Load-Balancer setzt du mehrere A-Records auf unterschiedliche IPs — der Client wählt per Round-Robin. Das ist kein echtes Failover, aber eine einfache Lastverteilung.

Prüfe deine Einträge immer mit dig:

dig +short example.de A
dig +short example.de AAAA
dig @1.1.1.1 example.de A
dig +trace example.de

Achte darauf, dass die IP im A-Record zur tatsächlichen Server-IP passt. Ein Tippfehler in einem Oktett (z. B. 203.0.114.42 statt 203.0.113.42) führt zu „Connection timed out" — und das suchst du stundenlang.

CNAME-Records: Alias statt fester IP

Ein CNAME zeigt auf einen anderen Hostnamen, nicht auf eine IP. Der Resolver löst die Kette weiter auf. Das ist ideal für Subdomains, die auf wechselnde Infrastruktur zeigen — etwa ein CDN oder ein verwalteter Mail-Dienst.

www.example.de.     3600  IN  CNAME  example.de.
shop.example.de.    3600  IN  CNAME  shops.myshopify.com.
cdn.example.de.     300   IN  CNAME  d1234.cloudfront.net.

Wichtig: Am Zone Apex (also direkt example.de) ist ein CNAME laut RFC 1034 nicht erlaubt, weil dort zwingend SOA- und NS-Records stehen müssen. Cloudflare und einige andere Anbieter lösen das mit CNAME Flattening — sie lesen den CNAME-Zielwert aus und schreiben intern A-Records. Bei BIND oder einem einfachen Hosting-Panel funktioniert das nicht.

Ein weiterer Stolperstein: Ein CNAME darf nicht mit anderen Records am selben Namen koexistieren. Du kannst also nicht gleichzeitig www als CNAME und als MX definieren. Für Mail brauchst du einen eigenen A-Record oder MX auf einer anderen Subdomain.

MX-Records: E-Mail-Routing mit Prioritäten

MX-Records bestimmen, wohin Mails für deine Domain gehen. Der niedrigere Wert hat höhere Priorität. Du brauchst immer mindestens zwei MX-Einträge, damit Mails bei Ausfall eines Servers nicht verloren gehen.

example.de.  3600  IN  MX  10  mx1.example.de.
example.de.  3600  IN  MX  20  mx2.example.de.
example.de.  3600  IN  MX  30  fallback.mailprovider.net.

Der MX-Zielwert muss ein A- oder AAAA-Record sein — niemals ein CNAME. Viele Provider (Google Workspace, Microsoft 365, mailbox.org) geben dir fertige MX-Sets. Google Workspace nutzt z. B. smtp.google.com mit Priorität 1, Microsoft 365 example-de.mail.protection.outlook.com mit Priorität 0.

Vergiss nicht den PTR-Record (Reverse DNS). Der wird nicht in deiner Zone, sondern beim IP-Inhaber (Hoster) gesetzt. Ohne passenden PTR landen deine Mails bei Gmail und Outlook oft im Spam. Bei Hetzner und netcup kannst du rDNS im Kundenpanel konfigurieren — bei Hetzner Cloud über die API:

hcloud server set-rdns --ip 203.0.113.42 --ptr mail.example.de srv-web-01

TXT-Records: SPF, DKIM, DMARC und Verifizierung

TXT-Records sind der Alleskönner. Sie enthalten SPF-Regeln, DKIM-Public-Keys, DMARC-Policies und Domain-Verifizierungen für Google, Microsoft und Cloudflare.

SPF legt fest, welche Server für deine Domain senden dürfen:

example.de. 3600 IN TXT "v=spf1 include:_spf.google.com include:mailing.example.net ip4:203.0.113.42 -all"

Die Endung -all bedeutet „alles andere ablehnen" (Hard Fail), ~all ist Soft Fail. 2026 empfehlen die meisten Provider -all. Achtung: Maximal 10 DNS-Lookups sind erlaubt — jeder include zählt.

DKIM signiert ausgehende Mails. Der Public Key liegt unter einem Selektor:

google._domainkey.example.de. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

DMARC verbindet SPF und DKIM und gibt eine Policy vor:

_dmarc.example.de. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.de; pct=100; adkim=s; aspf=s"

Starte mit p=none und werte die Reports 2–4 Wochen aus, bevor du auf quarantine oder reject umstellst. Sonst sperrst du versehentlich legitime Absender aus.

SRV, CAA und NS: Spezialrecords für Gameserver und TLS

SRV-Records sind für Gameserver essenziell. Sie erlauben Ports und Ziele in der Domain zu verstecken. Minecraft-Voice-Chat, Teamspeak oder Microsoft 365 Autodiscover nutzen sie:

_minecraft._tcp.example.de. 3600 IN SRV 0 5 25565 mc.example.de.
_ts3._udp.example.de.       3600 IN SRV 0 5 9987  voice.example.de.

Format: Priorität Gewichtung Port Ziel. Clients, die SRV unterstützen, verbinden sich dann einfach mit example.de statt mc.example.de:25565.

CAA-Records schränken ein, welche Certificate Authorities TLS-Zertifikate für deine Domain ausstellen dürfen. Seit Let's Encrypt CAA prüft, ist das ein wirksamer Schutz gegen Missbrauch:

example.de. 86400 IN CAA 0 issue "letsencrypt.org"
example.de. 86400 IN CAA 0 issuewild "letsencrypt.org"
example.de. 86400 IN CAA 0 iodef "mailto:security@example.de"

NS-Records delegieren Subzonen. Für die meisten Setups brauchst du sie nur am Apex. Willst du eine Subdomain an einen anderen Anbieter delegieren (z. B. dev.example.de an Cloudflare), legst du NS-Records mit den Ziel-Nameservern an.

DNS einrichten: cPanel, Plesk, Cloudflare und Route 53

Die Einrichtung unterscheidet sich je nach Panel. Ein Überblick über die gängigen Optionen 2026:

AnbieterPreisBesonderheit
Cloudflare Free0 €Anycast, CNAME Flattening, DNSSEC, Proxy
Hetzner DNS0 €API-first, keine Web-UI-Grenzen
INWXab 0,50 €/Zone/MonatVolle API, gute .de-Verwaltung
AWS Route 530,50 $/Zone + 0,40 $/Mio. QueriesAlias-Records, Health Checks
cPanel (Hosting)im Paket (ab 4,99 €/Monat)Zone Editor, kein DNSSEC

In cPanel findest du den Zone Editor unter „Domains → Zone Editor". Dort trägst du Records mit Name, TTL und Typ ein. Achte auf den Punkt am Ende von FQDNs — cPanel hängt automatisch den Zonennamen an.

In Cloudflare aktivierst du den orangenen Proxy nur für HTTP/HTTPS. Für Gameserver, SSH oder Mail-Ports muss der Record auf „DNS only" (grau) stehen, sonst funktioniert die Verbindung nicht.

Bei Route 53 nutzt du Alias-Records statt CNAMEs am Apex — das ist kostenlos bei Queries auf AWS-Ressourcen und löst das Apex-Problem sauber.

DNSSEC, DoH und DoT: Sicherheit 2026

DNSSEC signiert DNS-Antworten kryptografisch und verhindert Cache-Poisoning. Aktivierung läuft in zwei Schritten: Zuerst im DNS-Anbieter einschalten (erzeugt KSK/ZSK), dann den DS-Record beim Registrar hinterlegen. Bei .de unterstützt die DENIC DNSSEC flächendeckend.

dig +dnssec example.de A
dig example.de DS
delv @1.1.1.1 example.de A

Für Clients empfehlen sich verschlüsselte Resolver: DoH (DNS over HTTPS) und DoT (DNS over TLS). Öffentliche Resolver mit Support:

Auf einem Linux-Server konfigurierst du DoT mit systemd-resolved in /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes
Cache=yes

TTL, Propagation und typische Fehler

Die berühmte „48-Stunden-Propagation" ist ein Mythos. In der Praxis greifen Änderungen nach Ablauf der alten TTL — bei 300 Sekunden also nach 5 Minuten, bei 86400 nach 24 Stunden. Was wirklich passiert: Zwischen-Caches (Provider, Firmennetzwerke) halten alte Werte länger.

Die häufigsten Fehler, die wir in Support-Tickets sehen:

  1. Fehlender Punkt am Ende: www.example.de.example.de statt www.example.de.
  2. CNAME am Apex: Wird von BIND abgelehnt oder führt zu Konflikten mit MX.
  3. MX auf CNAME: RFC-Verstoß, viele Mailserver lehnen ab.
  4. Zu hohe TTL vor Migration: 86400 Sekunden = bis zu 24 Std. Downtime.
  5. SPF-Lookup-Limit überschritten: Mehr als 10 Includes → Permerror.
  6. Wildcard zu breit: *.example.de fängt auch Tippfehler-Domains für Mail ab.

Prüfe nach jeder Änderung mit mehreren Resolvern, um Caching-Effekte zu erkennen:

for ns in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo -n "$ns: "; dig +short @$ns example.de A
done

Migrations-Checkliste: Domain umziehen ohne Ausfall

Ein Umzug auf einen neuen Hoster oder DNS-Provider ist der kritischste Moment. Mit dieser Reihenfolge vermeidest du Ausfälle:

  1. T-48h: TTL aller Records auf 300 senken.
  2. T-24h: Neue Zone beim Ziel-Provider anlegen, alle Records 1:1 kopieren (dig-Abgleich per Skript).
  3. T-1h: DNSSEC deaktivieren, falls aktiv (sonst brechen Resolver mit alten DS-Records).
  4. T-0: NS-Records beim Registrar auf die neuen Nameserver umstellen.
  5. T+1h: Mit dig +trace prüfen, ob die Delegation greift.
  6. T+24h: Alle Dienste testen: Web, Mail, Gameserver, TLS-Zertifikate.
  7. T+72h: DNSSEC neu aktivieren, TTL wieder auf 3600 erhöhen.

Für den Record-Abgleich vor dem Umzug hilft ein kleiner Bash-Loop:

for type in A AAAA MX TXT CAA; do
  echo "== $type =="
  dig +short example.de $type
done > zone-backup.txt

Vergiss nicht, auch Subdomains und Wildcards zu sichern. Ein fehlender mail.example.de-Record ist nach dem Umzug schnell ein echtes Problem.

FAQ

Was ist der Unterschied zwischen A- und CNAME-Record?

Ein A-Record zeigt direkt auf eine IPv4-Adresse (z. B. 203.0.113.42), ein CNAME auf einen anderen Hostnamen (z. B. cdn.example.net). CNAMEs sind flexibler, weil du bei IP-Wechsel nur das Ziel anpassen musst, dürfen aber nicht am Zone Apex verwendet werden und nicht mit MX-Records koexistieren.

Wie lange dauert die DNS-Propagation wirklich?

So lange, wie die alte TTL beträgt — meist 5 Minuten bis 24 Stunden. Bei einer TTL von 300 Sekunden sind Änderungen nach rund 5 Minuten bei den meisten Resolvern sichtbar. Reduziere die TTL 24–48 Stunden vor einer geplanten Änderung, um die Wartezeit zu minimieren.

Kann ich einen MX-Record auf einen CNAME zeigen lassen?

Nein. Laut RFC 2181 darf der MX-Zielwert kein CNAME sein. Viele Mailserver akzeptieren das nicht oder behandeln es als Fehler. Verwende stattdessen einen A- oder AAAA-Record für den Mailserver-Hostnamen.

Brauche ich DNSSEC zwingend?

Zwingend nicht, aber dringend empfohlen. DNSSEC schützt vor Cache-Poisoning und Spoofing. Voraussetzung ist, dass dein DNS-Provider und dein Registrar DNSSEC unterstützen — bei .de ist das über die DENIC flächendeckend gegeben. Plane die Aktivierung sorgfältig, da Fehler die Domain komplett unauflösbar machen können.

Was kostet DNS-Hosting 2026?

Cloudflare und Hetzner DNS sind kostenlos. INWX verlangt ab 0,50 € pro Zone und Monat, AWS Route 53 berechnet 0,50 $ pro Zone plus 0,40 $ pro Million Queries. Bei Shared Hosting (cPanel, Plesk) ist DNS meist im Paket ab 4,99 €/Monat inklusive — dafür fehlen oft DNSSEC und API-Zugriff.

📖 Ähnliche Artikel