NS-Record im DNS verständlich erklärt: Nameserver-Delegation
Der NS-Record (kurz für Name Server Record) ist ein fundamentaler DNS-Eintrag, der festlegt, welche Nameserver für eine Domain und deren Subdomains autoritativ zuständig sind. Er delegiert die administrative Verantwortung für eine DNS-Zone an spezifische Server. Ohne NS-Records wüsste das weltweite Domain Name System nicht, wo es nach den A-Records, MX-Records oder TXT-Records einer Domain suchen soll.
NS-Records sind das Scharnier der gesamten DNS-Hierarchie: Sie verbinden die übergeordnete Zone (Parent) mit der untergeordneten Zone (Child) und definieren so, an welcher Stelle die Verantwortung von einem Nameserver an den nächsten übergeben wird.
Zonen-Delegation: Wie NS-Records Abfragen leiten
Das Domain Name System ist hierarchisch aufgebaut. Wenn ein Benutzer eine Website (z. B. example.com) aufruft, läuft die Abfrage im Hintergrund wie folgt ab:
- Der DNS-Resolver fragt die Root-Nameserver nach der Endung
.com. - Die Root-Nameserver verweisen den Resolver an die Nameserver der Registry (z. B. Verisign für
.com). - Die Registry-Nameserver enthalten die NS-Records der Domain
example.com. Sie teilen dem Resolver mit: „Die DNS-Verwaltung für example.com liegt bei den Nameservernns1.dns-provider.comundns2.dns-provider.com.“ - Der Resolver kontaktiert diese autoritativen Nameserver und erhält von ihnen die endgültige IP-Adresse (A-Record) der Website.
Aufbau und Syntax eines NS-Records
Nameserver-Einträge werden in der Zonendatei wie folgt konfiguriert. Sie verweisen immer auf einen Hostnamen und niemals auf eine IP-Adresse:
example.com. 86400 IN NS ns1.dns-provider.com.
example.com. 86400 IN NS ns2.dns-provider.com.
- Host/Name (
example.com.): Die Domain, die delegiert wird. - Time to Live (TTL -
86400): Die Cache-Dauer. Da Nameserver-Wechsel extrem selten vorkommen, ist die TTL standardmässig hoch eingestellt (meist 24 Stunden = 86400 Sekunden). - Klasse (
IN): Internet. - Typ (
NS): Identifiziert den Eintrag als Nameserver-Delegation. - Wert/Ziel (
ns1.dns-provider.com.): Der Hostname des Nameservers.
NS-Records im Vergleich zu verwandten Einträgen
NS-Records werden leicht mit anderen DNS-Einträgen verwechselt, die ebenfalls die «Verwaltung» einer Domain betreffen. Die folgende Tabelle grenzt sie ab:
| Record | Zweck | Verweist auf | Wo hinterlegt |
|---|---|---|---|
NS | delegiert eine Zone an Nameserver | Hostname (ns1.example.com.) | Parent-Zone und eigene Zone |
SOA | nennt den primären Nameserver & Zonenparameter | Hostname + Mailadresse | nur eigene Zone (1×) |
A | löst einen Hostnamen zu einer IPv4 auf | IP-Adresse | eigene Zone |
| Glue-Record | liefert die IP des Nameservers selbst | IP-Adresse | Parent-Zone (Registry) |
Wichtig: Ein NS-Record verweist immer auf einen Hostnamen, niemals auf eine IP-Adresse. Die zugehörige IP liefert entweder ein regulärer A-/AAAA-Record oder – bei In-Zone-Nameservern – ein Glue-Record.
Glue-Records: Die Auflösung der Henne-Ei-Frage
Liegt der Nameserver einer Domain innerhalb derselben Domain (z. B. ns1.example.com für example.com), entsteht ein Zirkelschluss: Um example.com aufzulösen, braucht der Resolver die IP von ns1.example.com – diese kennt aber nur der Nameserver, den er gerade sucht.
Die Lösung ist der Glue-Record: Bei der Domain-Registrierung wird die IP-Adresse des Nameservers direkt bei der Registry (im Parent) hinterlegt. So kann der Resolver den Nameserver kontaktieren, ohne die Zone vorher auflösen zu müssen. Nutzt eine Domain dagegen externe Nameserver (z. B. ns1.dns-provider.com für example.com), ist kein Glue-Record nötig, da die IP über die separate Zone dns-provider.com auflösbar ist.
Vorher/Nachher: Ein Nameserver-Wechsel ohne Ausfall
Ein Unternehmen wechselt von Provider A zu Provider B. Ein unsauberer Wechsel führt zu stunden- bis tagelangen Ausfällen:
- Falsch (Hard Cut): Die NS-Records werden bei der Registry sofort von A auf B umgestellt, bevor die Zone bei B vollständig angelegt ist. Resolver, die noch die alte Delegation (mit hoher TTL von 86400 s) gecacht haben, fragen weiter Provider A – dessen Zone aber bereits gelöscht wurde. Ergebnis: SERVFAIL, sporadische Ausfälle für bis zu 24 Stunden.
- Richtig (geplante Migration): Zuerst wird die komplette Zone (alle A-, MX-, TXT-Records) identisch bei Provider B angelegt und getestet. Erst danach werden die NS-Records bei der Registry umgestellt. Während der Propagation liefern beide Provider identische Antworten – egal, welche Delegation ein Resolver gerade gecacht hat, der Nutzer landet immer korrekt.
Die Lehre: Ein Nameserver-Wechsel ist kein Schalter, sondern ein Prozess. Halten Sie beide Zonen für die Dauer der TTL parallel deckungsgleich.
Best Practices für Nameserver-Redundanz
- Geografische und netzwerkseitige Trennung: Hosten Sie Ihre Nameserver nicht im selben Rechenzentrum oder im selben IP-Subnetz. Fällt die Internetanbindung dieses Rechenzentrums aus, sind alle Ihre Nameserver gleichzeitig offline. Nutzen Sie stattdessen die verteilten Nameserver-Infrastrukturen etablierter DNS-Provider (Anycast-Netzwerke).
- Subdomains delegieren: Sie können NS-Records nutzen, um Subdomains an völlig andere Nameserver zu übergeben. Hat Ihre Hauptdomain
example.comihre DNS-Einträge bei Provider A, können Sie fürtest.example.comeigene NS-Records anlegen, die auf Nameserver von Provider B verweisen. Dies ist nützlich für getrennte Entwicklungs-Umgebungen. - Lame Delegation vermeiden: Eine «lame delegation» liegt vor, wenn ein im NS-Record genannter Server für die Zone gar nicht (mehr) autoritativ antwortet. Prüfen Sie nach jeder Änderung, dass alle gelisteten Nameserver konsistente, autoritative Antworten liefern und der Delegationssatz bei der Registry mit den NS-Records in Ihrer Zone übereinstimmt.
- Konsistente TTL: Halten Sie die TTL der NS-Records bei allen Nameservern identisch, damit Resolver kein widersprüchliches Caching aufbauen.
[!TIP] Verzögerungen bei der Nameserver-Reaktion verlangsamen jeden einzelnen Seitenaufruf für Ihre Besucher (Time to First Byte - TTFB). Analysieren Sie die Antwortzeiten und die Konsistenz Ihrer Nameserver mit dem DNS Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Wie viele NS-Records benötigt eine Domain mindestens?
Aus Gründen der Ausfallsicherheit (RFC 1034) müssen für jede Zone mindestens zwei verschiedene Nameservern hinterlegt werden. Viele Registrys (z. B. für `.de` oder `.ch` Domains) lehnen die Registrierung ab, wenn nicht mindestens zwei erreichbare Nameserver eingetragen sind.
Was passiert, wenn der primäre Nameserver ausfällt?
DNS-Resolver weichen automatisch auf die weiteren in den NS-Records hinterlegten Nameserver aus. Solange mindestens ein Nameserver der Liste online ist, bleibt Ihre Domain erreichbar.
Was ist ein Glue-Record und wann wird er benötigt?
Ein Glue-Record ist ein A- oder AAAA-Record, der direkt bei der Registry hinterlegt wird, wenn der Nameserver einer Domain innerhalb derselben Domain liegt (z. B. `ns1.example.com` für `example.com`). Ohne diesen Glue-Record entstünde eine zirkuläre Abhängigkeit: Der Resolver bräuchte die IP des Nameservers, um die Domain aufzulösen, könnte sie aber nur über genau diesen Nameserver erfahren.
Müssen die NS-Records bei der Registry und in der Zone identisch sein?
Ja. Die bei der Registry hinterlegten Nameserver (der sogenannte Delegationssatz im Parent) und die NS-Records in der eigenen Zonendatei sollten exakt übereinstimmen. Weichen sie voneinander ab (Lame Delegation), kommt es zu inkonsistenten Antworten, Verzögerungen und im schlimmsten Fall zu Ausfällen.