Zum Inhalt springen 
Hetzner DNS Konfiguration setze ich so, dass Website, Subdomains und Mail ohne Umwege funktionieren und Änderungen schnell greifen. In diesem Leitfaden zeige ich die notwendigen Einstellungen im Hetzner-DNS, eine erprobte Beispielkonfiguration sowie praktische Prüfmethoden, damit du Fehler früh vermeidest und deine Zone sauber bleibt.
Zentrale Punkte
Die folgenden Stichpunkte geben dir einen schnellen Überblick, was für eine verlässliche DNS-Zone wichtig ist.
- Nameserver korrekt beim Registrar eintragen
- A/AAAA für Web, MX/TXT für Mail
- TTL passend wählen und Propagation abwarten
- SPF/DKIM gegen Spam und Spoofing
- Monitoring und Tests nach Änderungen
DNS kurz erklärt: was du wirklich brauchst
Ich ordne einer Domain über Records konkrete Ziele zu, damit Browser und Mailserver meine Dienste finden. Ein A-Record zeigt auf eine IPv4-Adresse, ein AAAA auf IPv6, und ein MX definiert die Zustellung von E-Mails. Ein CNAME bildet einen Alias, der auf einen anderen Namen zeigt, während TXT Angaben für SPF oder Verifizierungen enthält. Eine saubere Grundlinie besteht aus A/AAAA für die Hauptdomain, CNAME für www, MX für Mail und einem SPF-TXT. So halte ich die Zone übersichtlich, schnell wartbar und für spätere Erweiterungen offen.
Domain zur Hetzner DNS-Konsole hinzufügen
Ich lege in der DNS-Konsole zuerst eine neue Zone an und prüfe, dass die Schreibweise der Domain exakt stimmt. Danach aktiviere ich die manuelle Pflege von Records, damit ich Einträge gezielt anlegen und ändern kann. Tipp: Ich notiere mir vorab IP-Adressen und Mailziele, um alles ohne Unterbrechungen einzutragen. So vermeide ich Tippfehler und setze die Einträge in einer ruhigen Reihenfolge. Sobald die Zone bereitsteht, plane ich den Wechsel der Nameserver und die anschließenden Prüfungen.
Nameserver korrekt beim Registrar eintragen
Nach dem Anlegen der Zone trage ich beim Registrar die Nameserver von Hetzner ein, damit die Verwaltung zentral in der DNS-Konsole läuft. Übliche Einträge sind ns1.first-ns.de, robotns2.second-ns.de und robotns3.second-ns.com. Bei .de- oder .at-Domains setze ich bei Bedarf eigene Nameserver mit Glue-Records, damit die Referenzen samt IPs hinterlegt sind. Wer das noch nie gemacht hat, findet die einzelnen Schritte im Leitfaden zu Glue-Records einrichten. Ich lasse mir danach etwas Zeit für die Umstellung, denn die Aktualisierung kann weltweit unterschiedlich schnell ankommen.
Beispielkonfiguration: Website und E-Mail lauffähig machen
Für einen typischen Webauftritt setze ich einen A-Record für die Root-Domain, einen CNAME für www und passende Mail-Records. Ein SPF-TXT verhindert, dass fremde Server E-Mails im Namen der Domain versenden. Optional ergänze ich einen AAAA-Record, falls der Webserver IPv6 bereitstellt. Für externe Maildienste wie ForwardMX passe ich den MX an und hinterlege deren Vorgaben. Die folgende Tabelle zeigt eine solide Ausgangsbasis für viele Setups.
| Name | Typ | Wert | Hinweis |
|---|---|---|---|
| @ | A | 195.201.210.43 | Webserver IPv4 |
| @ | AAAA | Optional: 2a01:4f8:xxxx:xxxx::1 | Webserver IPv6 |
| www | CNAME | @ | Alias auf Root |
| @ | MX | mx1.forwardmx.net | Prio 10 |
| @ | TXT | „v=spf1 include:_spf.forwardmx.net -all“ | SPF gegen Spoofing |
DNSSEC aktivieren und DS-Record setzen
Wenn mir Manipulationssicherheit wichtig ist, aktiviere ich DNSSEC für die Zone. In der Hetzner-Konsole erzeuge ich dafür Signaturschlüssel und bekomme anschließend die notwendigen DS-Daten, die ich beim Registrar hinterlege. Ich prüfe, dass Algorithmus und Digest korrekt übernommen wurden. Danach warte ich, bis die Kette vom Registrar zur Zone sauber validiert. Vor größeren Schlüsseldrehungen senke ich die TTL und plane ein Zeitfenster ein, damit Resolver neue Signaturen rechtzeitig sehen. Wichtig: Passiert während des Wechsels ein Fehler, schlagen Validierungen bei Empfängern fehl – ich halte daher ein Rollback bereit (alte Schlüssel noch nicht zu früh löschen) und teste mit Validierungs-Resolvern.
TTL richtig setzen und Propagation verstehen
Die TTL bestimmt, wie lange Resolver einen Eintrag zwischenspeichern. Für Umstellungen wähle ich eine kurze TTL (z. B. 300 Sekunden), damit Änderungen rasch sichtbar werden. Nach der finalen Einrichtung erhöhe ich die Werte wieder, um Anfragen zu sparen und gleichmäßige Auflösung zu erreichen. Wer häufig deployt, bleibt gern bei 600–1200 Sekunden, wer selten ändert, nutzt 3600–14400. Eine praxisnahe Übersicht zur Entscheidung liefert mein Blick auf die optimale TTL-Wahl.
Apex-Domain, CAA und Zertifikate im Griff
Bei SaaS-Zielen am Zone Apex denke ich daran, dass CNAME auf @ nicht erlaubt ist. Ich nutze daher die A/AAAA des Anbieters oder setze eine Weiterleitung auf www auf Webserver-Ebene. Für die Zertifikatsvergabe steuere ich mit CAA-Records, welche CAs Zertifikate ausstellen dürfen. Ich pflege z. B. nur die CA, die ich tatsächlich nutze, und ergänze optional eine Mailadresse für Reports. Wechsle ich die CA, erhöhe ich kurz die TTL und aktualisiere CAA vor der Ausstellung. Für Wildcards via ACME DNS-01 vergewissere ich mich, dass TXT-Records unter _acme-challenge schnell gesetzt und automatisch bereinigt werden, damit keine alten Challenges liegen bleiben.
Subdomains und Dienste sauber anlegen
Für jede Subdomain lege ich einen passenden A– oder CNAME-Record an, je nachdem, ob die Subdomain direkt auf eine IP oder auf einen Namen zeigt. Beispiel: blog.example.de als A-Record auf die Blog-VM, cdn.example.de als CNAME auf einen CDN-Namen. Für APIs trenne ich streng zwischen internen und öffentlichen Namen, um Risiken zu vermeiden. Einheitliche Benennungen wie api, app, img helfen bei Wartung und Monitoring. So halte ich die Zone strukturiert und kann Änderungen klar zuordnen.
Wildcards, SRV und spezielle Record-Typen
Ich nutze Wildcard-Records (*.example.de) gezielt, etwa für mandantenfähige Setups. Dabei beachte ich, dass exakte Einträge stets Vorrang vor Wildcards haben. Für Dienste wie SIP, Matrix oder Autodiscover lege ich bei Bedarf SRV-Records an und prüfe Format und Prioritäten. TXT-Records mit langen Inhalten (z. B. 2048-Bit-DKIM) splitte ich in mehrere Anführungssegmente, damit Parser sie korrekt zusammenfügen. Ich vermeide Mehrfach-SPF-Records und kombiniere Einträge zu einem validen SPF, um das Lookup-Limit nicht zu reißen.
E-Mail zuverlässig zustellen: SPF, DKIM und DMARC
Für vertrauenswürdige E-Mail setze ich neben dem MX einen sauberen SPF-TXT, der meine sendenden Systeme abdeckt. Zusätzlich aktiviere ich DKIM beim genutzten Maildienst und veröffentliche die DKIM-Selector als TXT unter selector._domainkey. Mit DMARC definiere ich, wie Empfänger Mails behandeln, die SPF/DKIM nicht bestehen. Ich starte oft mit „p=none“, werte Berichte aus und ziehe später auf „quarantine“ oder „reject“ nach. Diese Reihenfolge senkt Risiken und steigert schrittweise die Zustellqualität.
SPF/DKIM/DMARC in der Praxis vertiefen
Ich halte SPF möglichst schlank: Nur nötige include-Mechanismen und niemals mehr als ein SPF pro Hostname. Um das 10-DNS-Lookups-Limit einzuhalten, reduziere ich Ketten oder nutze IP4/IP6-Mechanismen, wenn sie stabil sind. Für DKIM-Rotation betreibe ich zwei aktive Selector (alt/neu), publiziere den neuen Schlüssel, schalte den Maildienst um und lösche den alten erst nach einigen Tagen. Bei DMARC setze ich anfangs Berichtsadressen (rua/ruf) und prüfe Alignment (aspf/adkim). Für Subdomains kann ich über sp= eine eigene Richtlinie definieren, wenn diese separat senden. So reagiere ich auf echte Traffic-Daten statt auf Annahmen.
Reverse DNS (PTR) für saubere Mailzustellung
Neben MX, SPF und DKIM richte ich Reverse DNS (PTR) für ausgehende Mailserver ein. Der PTR der IP zeigt auf einen Hostnamen, der wiederum per A/AAAA korrekt auf die gleiche IP auflöst (Forward/Reverse-Match). Ich setze PTR je IP direkt beim IP-Inhaber (z. B. im Server-Interface) – nicht in der Zonenverwaltung der Domain. Für IPv6 nutze ich das nibble-Format. Ein passender PTR senkt Spam-Einstufungen und hilft bei Reputation. Läuft Mail über einen externen Dienst, lasse ich dessen PTR so, wie er vorgegeben ist, und vermeide gemischte Senderquellen ohne SPF-Anpassung.
Typische Fehler und schnelle Lösungen
Wenn eine Domain nicht auflöst, prüfe ich zuerst TTL, Nameserver-Einträge und die korrekte Schreibweise der Records. Der zweite Blick geht an die Propagation: Manche Resolver cachen länger, besonders nach TTL-Erhöhungen. Ich vergleiche die Auflösung über verschiedene DNS-Checker, um regionale Unterschiede zu erkennen. Bei lokalen Problemen stelle ich temporär auf öffentliche Resolver wie 1.1.1.1 oder 8.8.8.8 um. Tritt der Fehler nur in internen Netzen auf, kontrolliere ich interne Resolver und Regeln in Containern, Kubernetes oder CoreDNS-Konfigurationen.
Prüfmethoden: dig, nslookup und End-to-End
Ich teste nicht nur Records, sondern den kompletten Pfad:
- dig A/AAAA/CNAME/MX/TXT: Antworten, TTL und Autorität prüfen
- dig +trace: Delegationskette und Nameserver-Verhalten sehen
- SMTP-Tests: HELO/EHLO, TLS und Banner checken
- HTTPS real: Zertifikatskette, Hostname, Weiterleitungen
So erkenne ich auch Fehler, die in reinen DNS-Antworten nicht sichtbar sind, etwa falsche VirtualHost-Mappings oder auslaufende Zertifikate. Nach Änderungen warte ich mindestens eine TTL, bevor ich endgültige Schlüsse ziehe.
Effizient arbeiten mit der Hetzner-Konsole
Ich gruppiere zusammengehörige Einträge zeitlich, setze vor größeren Änderungen eine kurze TTL und veröffentliche dann alles in einem Rutsch. Vor dem Speichern prüfe ich noch einmal MX-Prioritäten, SPF-Syntax und die Ziel-IP des A-Records. Für Serververwaltung und Abläufe helfen mir die kompakten Hinweise unter Hetzner Robot Tipps. Nach Deployments teste ich http, https und Mail mit echten Requests, nicht nur via Ping. So erkenne ich Fehler, die reine DNS-Abfragen nicht zeigen.
Automatisierung: API, Vorlagen und ACME
Ich spare Zeit durch Automatisierung. Für regelmäßige Deployments nutze ich die API der DNS-Konsole, um Records zu erstellen, zu ändern oder zu löschen. Ich arbeite mit Vorlagen für wiederkehrende Muster (z. B. Web + Mail + DMARC) und füge nur projektspezifische Werte ein. Für Let’s Encrypt DNS-01 binde ich einen automatisierten TXT-Record-Writer ein und integriere ihn in den Erneuerungs-Workflow. Wichtig: API-Tokens behandle ich wie Passwörter, weise sie Projekt-gebunden zu und entziehe Zugriffe, wenn sie nicht mehr benötigt werden.
Erweiterte Setups: Split-Horizon, CDN und ACME
Für interne und externe Nutzer trenne ich bei Bedarf DNS-Sichten, damit die interne App auf private IPs und Besucher auf öffentliche Ziele zeigen. Nutze ich ein CDN, verweise ich Subdomains per CNAME auf den CDN-Namen und aktiviere dort TLS. Für automatische Zertifikate über ACME/Let’s Encrypt setze ich optional DNS-01 Challenges via TXT, falls HTTP-01 nicht passt. Wichtig ist hier die Automatisierung, damit Erneuerungen rechtzeitig erfolgen. Logs und Benachrichtigungen helfen beim rechtzeitigen Erkennen von Ausfällen.
Performance- und Verfügbarkeitsmuster
Ich erhöhe Verfügbarkeit mit einfachen Mitteln: Mehrere A/AAAA-Records (Round-Robin) teilen Last ohne Zusatzdienste, vorausgesetzt, die Backends sind zustandslos oder teilen Sitzungen. Bei Wartungen entferne ich einzelne IPs vorübergehend und hebe den Eintrag danach wieder an. Ein zu kurzer TTL-Dauerlauf kann Resolver belasten; ich finde einen Mittelweg zwischen Reaktionsgeschwindigkeit und Cache-Hit-Rate. Für Failover ohne Healthchecks setze ich klare Prozesse: Bei Störung tausche ich Einträge, überwache aktiv und setze sie nach Recovery wieder zurück.
Sicherheit und Zonenhygiene
Ich deaktiviere unnötige Zone-Transfers (AXFR) und veröffentliche nur die NS, die wirklich autoritativ sind. Alte oder verwaiste Subdomains lösche ich regelmäßig, damit keine Schattenoberflächen entstehen. Für IDNs prüfe ich die Punycode-Schreibweise, um Vertipper und Sonderzeichenfehler zu vermeiden. Rollenbasierte Zugriffe in der Konsole sorgen dafür, dass nur die richtigen Personen Zonen ändern. Und ganz pragmatisch: Ich dokumentiere Änderungen kurz im Team-Tool – das reduziert Rückfragen im Betrieb erheblich.
Migrations- und Rollback-Strategie
Vor einem Umzug senke ich die TTL (24–48 Stunden vorher), spiegele alle Records in die neue Zone und teste Auflösung über die neuen Nameserver direkt. Erst wenn alles stimmig ist, stelle ich die Nameserver beim Registrar um. Nach der Delegation beobachte ich Traffic und Fehler. Geht etwas schief, rolle ich kontrolliert zurück oder korrigiere gezielt einzelne Einträge. Bei DNSSEC-Umzügen plane ich besonders konservativ und lasse die alte Signaturkette noch bestehen, bis die neue sicher greift. Zum Schluss setze ich die TTL auf produktionsgerechte Werte zurück.
Kurzer Anbieter-Vergleich für Performance und Flexibilität
Leistung, Funktionen und DNS-Freiheit entscheiden, wie flexibel ich Projekte ausrolle. In der Praxis liefern die großen Hoster solide Antwortzeiten, unterscheiden sich aber in Bedienung, Features und Support. Ich bewerte die Auswahl nach Performance, Funktionsumfang, Hilfequalität und DNS-Optionen. Die folgende Übersicht zeigt ein kondensiertes Bild, das ich für Entscheidungen heranziehen kann. Am Ende zählt, was mein Projekt wirklich braucht, nicht die größte Feature-Liste.
| Anbieter | Performance | Funktionsumfang | Support | DNS-Flexibilität | Ranking |
|---|---|---|---|---|---|
| webhoster.de | Hoch | Sehr umfangreich | Top | Maximal | 1 |
| Hetzner | Hoch | Umfangreich | Gut | Hoch | 2 |
| Contabo | Mittel | Standard | O. K. | Mittel | 3 |
Kurz zusammengefasst
Ich setze eine Hetzner DNS-Zone strukturiert auf: Zone anlegen, Nameserver beim Registrar eintragen, Kern-Records für Web und Mail setzen, dann testen. Mit passender TTL verkürze ich Umstellungszeiten und erhöhe nach Abschluss wieder für weniger Last. SPF, DKIM und DMARC stärken die Zustellung und schützen die Domain gegen Missbrauch. Subdomains halte ich konsistent und trenne interne von öffentlichen Zielen. Mit dieser Beispielkonfiguration und den Checks im Alltag bleibt deine hetzner dns konfiguration verlässlich, schnell und leicht zu warten.
