--- id: "name-server" kind: "glossary-term" title: "Nameserver" language: "de" category: "DNS und technische Grundlagen" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/de/glossar/nameserver/" translations: en: "https://tldlog.com/glossary/name-server/" es: "https://tldlog.com/es/glosario/servidor-nombres/" fr: "https://tldlog.com/fr/glossaire/serveur-noms/" it: "https://tldlog.com/it/glossario/name-server/" pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/" ru: "https://tldlog.com/ru/glossariy/dns-server/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # Nameserver Ein Server, der DNS-Records speichert und Anfragen zu Domainnamen beantwortet. Damit eine Domain funktioniert, teilt der Registrar der Registry mit, welche Nameserver ihre Records vorhalten. Wer die Nameserver einer Domain ändert, ändert, wo ihre Website und ihre E-Mails zu finden sind. Ein Nameserver ist der Rechner, der antwortet, wenn jemand fragt, wo die Website oder die E-Mail einer Domain zu finden ist. Jede Domain muss mindestens zwei haben, und der Registrar trägt sie bei der Registry ein. Fehlen sie, sind sie falsch oder abgeschaltet, funktioniert die Domain nicht mehr, obwohl sie weiterhin registriert ist. ## Was ein Nameserver für eine Domain leistet Die Begriffe „Nameserver“ und „DNS-Server“ umfassen zwei Aufgaben. Autoritative Server halten die DNS-Records einer Domain und antworten für sie; Resolver stellen diese Fragen im Auftrag der Nutzer. RFC 9499 (März 2024), das Dokument zur DNS-Terminologie, weist darauf hin, dass beide oft Nameserver genannt werden. Hier sind die autoritativen gemeint. Die Zone oberhalb der Domain, die die Registry ihrer TLD führt, enthält NS-Records, die die Server der Domain nennen. Diese Delegation sagt Resolvern, wo sie fragen müssen. Der Registrar übermittelt diese Namen per EPP an die Registry. Eine Domain ohne Nameserver hat den Status inactive und wird nicht aufgelöst. RFC 1034 (November 1987) verlangt, dass jede Zone auf mindestens zwei Servern liegt, damit sie den Ausfall eines Servers übersteht. Der SSAC-Bericht SAC125 (9. Mai 2024) stellt fest, dass Registrys in der Regel bei der Registrierung und bei jeder Änderung mindestens zwei verlangen. ## Registrar, DNS-Anbieter und Hoster: wer die Nameserver betreibt Drei Rollen sind beteiligt, wahrgenommen von einem Unternehmen oder von dreien: - Der Registrar hinterlegt bei der Registry, welche Nameserver die Domain verwendet. - Der DNS-Anbieter betreibt diese Server und die Zone mit den Records der Domain. Das kann der Registrar sein, ein Webhoster oder ein spezialisierter Anbieter. - Web- und E-Mail-Hoster betreiben die Dienste, auf die die Records verweisen. Ein Wechsel des DNS-Anbieters ändert nichts am Registrar: Ersetzt werden nur die für die Domain eingetragenen Nameserver. ## Nameserver ändern, Schritt für Schritt 1. Zuerst die Zone beim neuen DNS-Anbieter einrichten, mit allen Records, die die Domain nutzt, einschließlich Website und E-Mail, und mit NS-Records, die den neuen Nameservern entsprechen. 2. Ist die Domain mit DNSSEC signiert, kann ein DS-Record, der weiter auf die alten Schlüssel verweist, dazu führen, dass sie bei Resolvern, die Signaturen prüfen, nicht mehr funktioniert. Kooperiert der bisherige Betreiber nicht, beschreibt RFC 6781 diese Reihenfolge: die Entfernung des DS-Records beantragen, die Nameserver ändern, warten, bis sich die Änderung im DNS verbreitet hat, und dann einen DS-Record für die neu signierte Zone hinzufügen. Bis dahin ist die Domain nicht durch DNSSEC geschützt. 3. Prüfen, dass die Domain nicht gegen Änderungen gesperrt ist: Solange clientUpdateProhibited oder serverUpdateProhibited gesetzt ist, lehnt die Registry Änderungen ab. Der Registrar hebt clientUpdateProhibited auf; serverUpdateProhibited (Registry Lock) kann nur die Registry entfernen, über den Registrar. 4. Die neuen Nameserver beim Registrar eintragen, der sie an die Registry weitergibt. Mindestens zwei angeben, idealerweise in getrennten Netzwerken. 5. Den alten Dienst noch eine Weile weiterlaufen lassen: Resolver halten Kopien von Antworten vor, daher erreichen manche Besucher stunden- oder noch länger die alten Server. Die alte Zone nicht am selben Tag löschen. Regeln, Sperren und Fristen hängen von Registry und Registrar ab; vor der Änderung einer wichtigen Domain sollte man sich daher bei ihnen erkundigen. ## Glue-Records und Nameserver innerhalb der eigenen Domain Ein Beispiel ist example.com mit den Nameservern ns1.example.com und ns2.example.com. Um ns1.example.com zu finden, müsste ein Resolver zuerst die Nameserver von example.com fragen, also genau die Server, die er sucht. Der Ausweg ist der Glue-Record: Die Registry veröffentlicht die IP-Adressen dieser Server zusammen mit der Delegation. RFC 9471 (September 2023) macht diesen Glue in Verweisantworten verpflichtend und stellte damals fest, dass Adressen (A- und AAAA-Records) die einzige definierte Art von Glue waren. Bei der Registry ist jeder Nameserver ein Host-Objekt. Weil ns1.example.com unter example.com liegt, muss die Domain zuerst existieren; danach legt der Registrar das Host-Objekt mit seinen IP-Adressen an und verknüpft die Domain damit. Adressen sind nur nötig, wenn Glue gebraucht wird: Würde example.com ns1.example.net verwenden, bräuchte die Registry von .com dafür keinen Glue. ## Primäre und sekundäre Server und warum Redundanz wichtig ist Der primäre Server hält die Kopie der Zone, an der Änderungen vorgenommen werden. Sekundäre Server kopieren sie per Zonentransfer: Ein vollständiger Transfer (AXFR) kopiert die ganze Zone, ein inkrementeller (IXFR) nur das, was sich geändert hat. Das Protokoll DNS UPDATE (RFC 2136), der standardisierte Teil von dynamischem DNS, fügt Records hinzu oder löscht sie, ohne dass die Zone von Hand bearbeitet wird. Zwei Server sind das Minimum, nicht die Empfehlung: RFC 2182 (Juli 1997) warnt, dass eine Zone mit nur zwei Servern nach dem Ausfall eines davon „tatsächlich nur mit einem läuft“, und empfiehlt für die meisten Organisationen drei, davon mindestens einen weit entfernt von den anderen, und vier oder fünf für höhere Zuverlässigkeit. Die technischen Anforderungen der IANA (zuletzt überarbeitet am 14. November 2024, Stand: Oktober 2026) gelten nur für die Root-Zone, .INT und .ARPA, sind aber eine nützliche Checkliste: mindestens zwei NS-Records auf unterschiedlichen IP-Adressen, Server in mindestens zwei topologisch getrennten Netzwerken, autoritative Antworten und kein rekursiver Dienst. ## Was schiefgeht: Lame Delegations und vergessene Server „Lame Delegation“ bezeichnet mehrere Fehler: einen eingetragenen Server, der nicht antwortet, nicht erreichbar ist oder mit einem Fehler oder ohne Autorität antwortet. RFC 9499 empfiehlt genauere Bezeichnungen. In jedem Fall werden Abfragen langsamer oder schlagen fehl. Eine häufige Ursache ist ein vergessener Server: Ein Domaininhaber verlässt einen DNS-Anbieter, ohne die NS-Records zu ändern, und die Domain bleibt an Server delegiert, die nicht mehr für sie antworten, was den Weg zu einer Übernahme öffnen kann. Ein weniger sichtbares Risiko: Laut SAC125 weigern sich die meisten Registrys, eine abgelaufene Domain zu löschen, solange andere Domains von ihr abhängen, und RFC 5731 besagt, dass sie nicht gelöscht werden sollte, bevor ihre Host-Objekte gelöscht oder umbenannt sind. Manche Registrare haben sie in eine andere Domain umbenannt. SAC125 nennt diese Sacrificial Name Servers, unsicher, wenn diese andere Domain registriert werden kann: Wer sie registriert, kontrolliert die Auflösung jeder Domain, die sie noch nutzt. Mit Stand September 2020 hatte dies laut dem Bericht über 500.000 gTLD-Domains dem Risiko einer Übernahme ausgesetzt, und die Auflösung von über 163.000 war unter unbefugte Kontrolle geraten; SAC125 merkt an, dass das Ausmaß bei ccTLDs unbekannt ist. Der Bericht empfiehlt einen Verhaltenskodex für Registrys und Registrare; Stand Oktober 2026 war kein angenommener Kodex bestätigt. Wer die Domains verlängert, auf denen die eigenen Nameserver liegen, verringert dieses Risiko. ## Quellen - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## verwandte begriffe - [autoritativer Server](https://tldlog.com/de/glossar/autoritativer-server/) - [NS-Record](https://tldlog.com/de/glossar/ns-record/) - [Glue-Record](https://tldlog.com/de/glossar/glue-record/) - [DNS](https://tldlog.com/de/glossar/dns/)