Leitfaden für die sichere DNS-Bereitstellung: 15 Best Practices für autoritative Dienste

Anfang dieses Jahres, im März 2026, hat NIST SP 800-81r3 veröffentlicht, seinen Leitfaden für die sichere DNS-Bereitstellung. Es handelt sich um die zweite Überarbeitung dieses Dokuments (das erstmals 13 Jahre zuvor erschien), und sie gliedert sich grob in drei Teile:

1. DNS als Bestandteil der Netzwerkarchitektur
2. sichere Nutzung von DNS
3. Sicherheit autoritativer DNS-Server.

Falls Sie es noch nicht getan haben, empfehlen wir Ihnen dringend, unsere Zusammenfassung zu lesen, um sich einen Überblick zu verschaffen. Dieser Leitfaden konzentriert sich jedoch auf den letzten Teil, die Sicherheit autoritativer DNS-Server. In gewisser Weise setzt er dort an, wo NIST aufgehört hat: Nach mehr als einem Jahrzehnt, in dem wir Produkte rund um DNS-Sicherheit entwickelt haben, möchten wir zusätzliche Details in Form leicht umsetzbarer Best Practices für die Sicherheit autoritativer DNS-Server liefern.

Diesen Leitfaden sollte jeder lesen, um sich über die wichtigsten Bedrohungen zu informieren, festzustellen, welche davon für die eigene Organisation relevant sind, und die jeweils am besten geeigneten Gegenmaßnahmen festzulegen. Keine Sorge, er ist kurz!

Wenn sich Ihr Angebot an die breite Öffentlichkeit richtet, sollten Sie Ihre autoritativen DNS-Server aus mehreren Gründen besser nicht selbst betreiben. Erstens ist das keine kleine Aufgabe. Zunächst müssen Sie eine weltweit verteilte Nutzerbasis bedienen, was die Bereitstellung auf mehreren Servern weltweit mittels Anycast erfordert, sodass alle unter derselben IP-Adresse erscheinen. Darüber hinaus müssen Sie für Ausfallsicherheit sorgen; idealerweise benötigen Sie mindestens zwei Server-Ebenen in zwei unabhängigen Netzwerken. Dann müssen Sie sicherstellen, dass diese verfügbar und synchron bleiben. Und zu alldem kommen noch Denial-of-Service-Angriffe hinzu. Die Liste ließe sich fortsetzen, aber Sie verstehen das Prinzip. Es ist wirklich keine kleine Aufgabe.

Zweitens gibt es zahlreiche hochwertige Managed-DNS-Anbieter zu sehr günstigen Preisen. Ein eigenes DNS-Hosting verschafft Ihnen keinen besonderen Vorteil, kostet Sie mehr und gelingt nicht so gut wie bei den großen Anbietern. Ihre Zeit und Ressourcen sind in anderen Vorhaben deutlich besser investiert. Wenn Sie eine sehr robuste DNS-Präsenz anstreben, werden Sie sogar zwei Managed-DNS-Anbieter in Betracht ziehen, um online zu bleiben, falls einer ausfällt.

Diese Empfehlung gilt nicht unbedingt, wenn Sie einen autoritativen DNS-Server für eine nicht öffentliche Zielgruppe bereitstellen. Das ist deutlich weniger Aufwand; Sie möchten Ihre Daten ohnehin privat halten, und Sie können die Server sehr nah bei Ihren Nutzern betreiben.

Wenn Sie Ihren DNS-Bedarf an einen Drittanbieter auslagern, pflegt dieser in der Regel Ihre autoritativen Daten, die Sie über eine proprietäre API aktualisieren. Wenn Sie neu beginnen, ist das meist unproblematisch, doch möglicherweise haben Sie bereits einen DNS-Server, der als Ihre maßgebliche Datenquelle dient. Oder er ist bereits mit Workflows in Ihrer Organisation verankert, die Sie nicht ändern möchten.

Es ist völlig in Ordnung, die Kontrolle über Ihren Primärserver zu behalten, aber in der Regel sollten Sie ihn nicht im öffentlichen Internet exponieren. Denial-of-Service-Angriffe sind verbreitet, und Angreifer zielen meist auf die schwächste Stelle. Wenn sie herausfinden, wo sich Ihr Primärserver befindet, wird er wahrscheinlich als Erstes angegriffen.

Hier haben Sie mehrere Möglichkeiten. Erstens können Sie ihn online halten, ohne jedoch seinen Namen oder seine IP-Adresse bekannt zu machen. Oder Sie setzen eine Firewall ein, die den Zugriff aus den Netzwerken Ihres DNS-Anbieters erlaubt, nicht aber aus dem öffentlichen Internet.

In diesem Aufbau ist Ihr Primärserver Ihre Control Plane, während Ihre Managed-DNS-Anbieter die Query Plane (Data Plane) betreiben.

Das versteht sich eigentlich von selbst, ist aber dennoch eine Erwähnung wert: Autoritative und rekursive Funktionen zu vermischen, ist nie eine gute Idee. Auch wenn beide aus der Ferne wie DNS-Server aussehen, sind ihre Aufgaben sehr unterschiedlich. Außer in trivialen Fällen ist die rekursive Funktion anspruchsvoller und kann die autoritative Komponente beeinträchtigen.

Ein primärer Nameserver kommuniziert normalerweise nur mit seinen sekundären Servern. Seine Aufgabe ist einfach: die maßgeblichen Domaininformationen vorzuhalten und an die Server zu verteilen, die mit der Öffentlichkeit kommunizieren. Rekursive Server hingegen müssen ein breites Publikum bedienen (oft die Öffentlichkeit, also genau das Gegenteil dessen, was Sie für einen autoritativen DNS-Server wollen), jeden beliebigen anderen DNS-Server im Internet abfragen, einen Cache betreiben und so weiter.

Autoritative Server enthalten per Definition öffentliche Informationen, doch das bedeutet nicht, dass diese jedem, der danach fragt, in großen Mengen ausgeliefert werden müssen. Verschleierung erfüllt nach wie vor einen Zweck. Zonentransfers sind ein Mechanismus, der Aktualisierungen von Primär- an Sekundärserver weitergeben soll, doch häufig stellt sich heraus, dass sie für jeden zugänglich sind. In der Praxis sollten Sie diese Informationen am besten nur nach dem Need-to-know-Prinzip bereitstellen.

Nutzen Sie nach Möglichkeit Netzwerkzugriffskontrollen und Authentifizierung, um sicherzustellen, dass die Zoneninformationen nicht in falsche Hände geraten. Üblicherweise kommt dafür TSIG-Authentifizierung zum Einsatz, die schnelle symmetrische Algorithmen verwendet. Wenn Sie eine große Zahl von Parteien authentifizieren müssen, gibt es außerdem SIG(0), das Public-Key-Kryptografie nutzt, jedoch mehr Aufwand bei Bereitstellung und Wartung erfordert.

Manche DNS-Server geben ihre Versionsnummer preis. Auch das sollten Sie prüfen und deaktivieren.

Eine gängige Taktik von Angreifern besteht darin, Ihre Verwaltungsschnittstellen ins Visier zu nehmen. Wenn Sie Ihren Primärserver verbergen, beseitigen Sie einen erheblichen Angriffsvektor, indem Sie ihn vom öffentlichen Internet fernhalten.

Liegen Ihre autoritativen Daten bei einem Managed-DNS-Anbieter, nutzen Sie alle verfügbaren Mittel, um die Verwaltungsschnittstellen und API-Endpunkte zu schützen. Verwenden Sie mindestens Zwei-Faktor-Authentifizierung und erwägen Sie zusätzlich, die für den Zugriff zulässigen IP-Adressen einzuschränken.

Bei vielen kleinen Unternehmen ändert sich die DNS-Zonenkonfiguration nicht besonders oft und kann als statische Konfiguration gepflegt werden. Traditionell waren dynamische DNS-Updates (z. B. RFC 2136) größeren Unternehmen mit komplexen Umgebungen vorbehalten. Die automatisierte Domainvalidierung für die Ausstellung von X.509-Zertifikaten über das ACME-Protokoll hat jedoch stark an Beliebtheit gewonnen, und eine der Methoden basiert auf einer DNS-Änderung.

Dynamische DNS-Updates zuzulassen, steht im Widerspruch dazu, Ihren primären Nameserver abzuschotten und sicher zu halten. Dabei sind zwei Aspekte zu berücksichtigen:

• Entfernte Endpunkte müssen sich mit dem Ort verbinden, an dem Ihre Daten liegen
• Sie müssen sicherstellen, dass jede Entität nur einen eng begrenzten Datenbereich ändern darf, nicht alles

Ihr Managed-DNS-Anbieter bietet dafür in seinen APIs möglicherweise eine gute Lösung, doch Architektur und Verwaltung erfordern dennoch Ressourcen. Wenn Sie Ihren Nameserver selbst betreiben, sollten Sie einen gehärteten Proxy einsetzen, statt Ihren Primärserver im Internet zu exponieren.

Alternativ bieten einige Anbieter ACME-Validierungsdienste an, die auf einer einmaligen Konfiguration eines CNAME-Eintrags von Ihrer Domain auf einen Endpunkt eines Drittanbieters beruhen. Danach können diese die ACME-Validierung für Sie übernehmen. Das hilft, dynamische DNS-Updates zu vermeiden, andererseits hängt Ihre Zertifikatsvalidierung dann jedoch von einem Drittanbieter ab.

Versionskontrolle ist Ihr Freund. Am wichtigsten ist zwar, dass Ihre Zonen korrekte Informationen enthalten und verteilen, doch zu wissen, wann und warum Änderungen vorgenommen wurden, hilft Ihnen festzustellen, ob die Informationen tatsächlich korrekt sind. Tatsächlich ist es heute keine große Herausforderung mehr, Ihre DNS-Konfiguration weltweit zu verteilen; sicherzustellen, dass Ihre Informationen korrekt bleiben, hingegen schon.

Liegt Ihre DNS-Konfiguration in Form von Zonendateien vor, stellen Sie diese unter Versionskontrolle, etwa mit Git. Schützen Sie den Main-Branch und nutzen Sie Pull-Request-Workflows, um Änderungen zu dokumentieren und zu validieren, sobald sie erfolgen. DNSControl und octoDNS sind zwei beliebte Open-Source-Tools, die diese Art von Workflow unterstützen.

Die Informationen in Ihrer DNS-Konfiguration erfüllen einen Zweck und müssen an diejenigen verteilt werden, die sie benötigen. Gehen Sie davon aus, dass alles, was Sie in Ihre Zonen eintragen, öffentlich ist. Tragen Sie nichts ein, was nicht bekannt werden soll, denn es wird unweigerlich ans Licht kommen. Überprüfen Sie regelmäßig, was in Ihren Zonendateien veröffentlicht ist, und ob sich Teile davon entfernen lassen.

Hier ein kurzer Überblick über gängige Aufklärungstechniken:

• Zonentransfers. Sind Zonentransfers aktiviert, bieten sie den effizientesten Weg, an die gesamte Zonendatei zu gelangen. Wie bereits erläutert, sollten Zonentransfers jedoch standardmäßig deaktiviert und nur dort aktiviert werden, wo sie wirklich benötigt werden.
• Passive-DNS-Dienste. Historisch hat DNS den Datenverkehr während der Übertragung nie geschützt. Da die Daten in diesen UDP-Paketen viele nützliche Informationen enthalten (z. B. für die Profilerstellung), ist eine ganze Branche für passives DNS-Monitoring entstanden. Diese Unternehmen platzieren Sonden auf der ganzen Welt an den verkehrsreichsten Knotenpunkten und zeichnen alles auf, was sie können. Die Daten werden dann gegen Gebühr jedem zur Verfügung gestellt, der dafür zahlt. Statistisch gesehen werden einige Ihrer weniger bekannten Subdomains möglicherweise nicht erfasst, die populären aber mit Sicherheit.
• Certificate Transparency. Certificate Transparency (CT) ist ein System, das die Ausstellung aller öffentlichen Zertifikate überwacht. Da Zertifikate Domains und Subdomains enthalten, geben sie Informationen preis, die früher oft privat waren. Nun werden selbst Informationen über wenig bekannte Subdomains öffentlich, sobald ein einziges Zertifikat ausgestellt wird. Wildcard-Zertifikate können, sicher eingesetzt, etwas Abhilfe schaffen, doch leider vergrößert die gemeinsame Nutzung von Zertifikaten durch voneinander unabhängige Dienste den "Explosionsradius" einer Kompromittierung oder eines Ablaufs.
• Brute-Forcing von Resource Records. Da es nur wenige zentrale Resource-Record-Typen gibt, lassen sich diese sehr leicht per Brute Force ermitteln, und das erzeugt kaum Auffälligkeiten, sobald eine Subdomain entdeckt ist.
• Informationslecks durch DNSSEC. Als DNSSEC ursprünglich entworfen wurde, bestand der Hauptansatz darin, alle Daten vorab zu signieren und zur Laufzeit jegliche kryptografischen Operationen zu vermeiden. Das führte zu einem Problem bei Antworten auf beliebige nicht existierende Domains. Dynamisches Signieren galt als zu aufwendig. Zwei Lösungen waren NSEC- und NSEC3-Einträge, die dynamisches Signieren vermieden. Ihr Design machte es jedoch möglich, jede DNSSEC-fähige Zone per "Tree-Walk" vollständig zu erfassen. Moderne Lösungen für dieses Problem sind als "White Lies" (RFC 4470) und, neuer, als "Black Lies" (RFC 9824) bekannt.
• Enumeration von DNS-Domains. Wenn alles andere scheitert, können sich Angreifer stets auf die "gute alte" Brute-Force-Enumeration verlassen. Ausgestattet mit Wörterbüchern der gängigsten DNS-Labels (oft angepasst an das, was über Ihren DNS-Bestand bereits bekannt ist), probieren sie einfach alles aus, häufig mit hoher Geschwindigkeit. Diese Angriffe sind in der Regel sehr auffällig und wenig raffiniert; ein gutes Monitoring sollte sie erkennen, da sie eine große Zahl von NXDOMAIN-Antworten erzeugen.

Wie bereits erläutert, wird alles, was Sie in Ihre autoritativen DNS-Zonen eintragen, auf die eine oder andere Weise öffentlich. Was Sie wirklich benötigen, können Sie nicht entfernen, doch achten Sie darauf, nicht zu viel preiszugeben. Unternehmen nutzen einen Domainnamen oft sowohl für öffentliche als auch für interne Zwecke; im letzteren Fall enthält ihr autoritatives DNS interne Informationen.

Wenn Sie neu beginnen, sollten Sie getrennte Domainnamen für öffentliche und interne Aktivitäten verwenden. Nutzen Sie bereits einen gemeinsamen Domainnamen, erwägen Sie eine Split-Zone-DNS-Bereitstellung, bei der die öffentliche Seite nur wirklich öffentliche Informationen enthält und Sie interne Informationen über eine separate Infrastruktur verteilen, auf die nur Ihre internen Nutzer zugreifen können.

Zum Verbergen von Informationen empfiehlt sich am ehesten eine private PKI für Ihre internen Zertifikate. Damit sind nicht unerhebliche Kosten verbunden: Aufwand und Ausgaben für den Betrieb einer privaten CA sowie die Notwendigkeit, deren Root-Zertifikate auf allen Client-Geräten zu hinterlegen.

Ursprünglich ein einfacher Dienst, der vor allem Informationen über IP-Adressen (A-Einträge) lieferte, ist DNS im Laufe der Zeit immer komplexer geworden. Heute umfasst es zahlreiche bewegliche Teile und Fehlerquellen. Es gibt nicht nur mehrere Server (primäre und sekundäre), sondern diese sind auch weltweit verteilt. Sie müssen über IPv4 und IPv6 sowie über UDP und TCP funktionieren. In großem Maßstab treten ständig Probleme auf, und der beste Weg, sie zu erkennen, ist aktives Monitoring.

Abfrageprotokolle von DNS-Servern werden oft vergessen, doch wenn Sie Ihre eigenen Server betreiben, sollten sie unbedingt überwacht und zusammen mit allen anderen Protokollen gespeichert werden. Wenn Sie diese Best Practices befolgen, fallen die Protokolle Ihres primären Nameservers recht schlank aus. Alles, was dort auftaucht, deutet auf eine nicht funktionierende Kontrollmaßnahme hin.

Standardmäßig unterliegt der gesamte Domain-Namensraum Ihrer autoritativen Zonen Ihrer direkten Kontrolle. DNS ist von Natur aus verteilt, mit Verweisen nicht nur auf andere Orte unter Ihrer Kontrolle, sondern auch auf Dritte. Das geschieht am häufigsten über CNAME-Einträge, die Delegierung von Subzonen und gelegentlich, wenn auch selten, sogar über DNAME-Einträge.

Diese Delegierungen werden in der Regel hinzugefügt, damit der Dritte einen Dienst irgendeiner Art erbringen kann, doch sollte man sich bewusst sein, dass jede Delegierung ein Risiko mit sich bringt. Daher sollten sie im Rahmen Ihres Risikomanagements erfasst und überwacht werden. Binden Sie Ihr Application-Security-Team ein, da es beurteilen kann, ob delegierte Domains die Sicherheit übergeordneter oder benachbarter Domains beeinträchtigen können. Informieren Sie Ihr PKI-Monitoring, da Dritte möglicherweise Zertifikate in Ihrem Namen bei anderen CAs ausstellen lassen als Sie selbst.

Ihre Monitoring-Plattform sollte idealerweise ein vollständiges Inventar der Delegierungen an Dritte bereitstellen. Versehen Sie diese mit Zweck und Verantwortlichkeit und legen Sie nach Möglichkeit ein Ablaufdatum fest. Nehmen Sie in diese Liste auch Dienst-Delegierungen an Domains auf, die Ihnen nicht gehören.

Die im vorherigen Abschnitt besprochenen Delegierungen an Dritte bergen Risiken, solange sie aktiv sind, mitunter aber noch größere, wenn sie nicht mehr funktionieren. In diesem Fall können sie von einem böswilligen Dritten übernommen werden.

Die häufigsten Ursachen dafür:

• Ein Abonnement für einen Drittanbieterdienst wird abgeschlossen und ein CNAME hinzugefügt, der auf die Infrastruktur des Anbieters verweist. Einige Zeit später wird das Abonnement gekündigt, der CNAME bleibt jedoch bestehen. Wird auch das Ziel des CNAME gelöscht, ist das leicht zu erkennen, da der DNS-Resource-Record dann fehlerhaft ist. Weitaus häufiger verweisen diese CNAMEs jedoch auf ein generisches Ziel (d. h. ein Ziel für alle Kunden), was zu einem verwaisten Dienst führt, der deutlich schwerer zu erkennen ist.
• Ein neuer Dienst wird in der Cloud eingerichtet und über eine oder mehrere IP-Adressen identifiziert. Es werden DNS-Einträge vom Typ A und AAAA hinzugefügt. Einige Zeit später wird der Dienst abgeschaltet, die DNS-Einträge bleiben jedoch bestehen. Der Cloud-Anbieter weist die nicht mehr genutzten IP-Adressen nun anderen Kunden zu.

Dies sind zwei der häufigsten Probleme, doch DNS bietet von Natur aus zahllose Möglichkeiten, von einem Ort auf einen anderen zu verweisen. Praktisch jeder DNS-Resource-Record (RR) kann ein Problem dieser Art verursachen: A, AAAA, CNAME, NS, SOA, MX, CAA, SRV, TXT, HTTPS und so weiter.

Das Grundproblem besteht darin, dass sich ein einmal konfigurierter Verweis nicht mit seinem Ziel synchron halten lässt. Ein umfassendes und kontinuierliches Monitoring der gesamten DNS-Angriffsfläche ist der einzige Weg, diese Probleme frühzeitig zu erkennen, bevor sie von böswilligen Akteuren ausgenutzt werden können.

Ihre Gegner werden Sie auf jede erdenkliche Weise angreifen. Wenn sie Ihre Domainnamen nicht direkt missbrauchen können (z. B. durch Ausnutzen eines verwaisten DNS-Eintrags), registrieren sie mitunter Domainnamen, die in den Augen Ihrer Mitarbeitenden und Kunden gleichermaßen als Ihre durchgehen könnten.

Über solche ähnlichen Domainnamen können Sie sich von einem Drittanbieterdienst wie Red Sift Brand Trust benachrichtigen lassen. Die Erkennung erfolgt durch die Überwachung des gesamten weltweiten Bestands an Domainnamen sowie durch eine Reihe weiterer Techniken.

Geben Sie Domainnamen, die einmal in Gebrauch waren, nicht frei und versäumen Sie nicht, sie zu verlängern. Andernfalls werden sie wahrscheinlich neu registriert und möglicherweise gegen Sie verwendet. Schließlich gehörten sie einmal Ihnen und genießen vermutlich noch einen Teil Ihrer impliziten Reputation.

Darüber hinaus wird Domainbesitz mitunter genutzt, um Vertrauensbeziehungen zu Dritten herzustellen. Wird ein Domainname aufgegeben, erbt derjenige, der ihn erhält, die bestehenden Vertrauensbeziehungen.

DNSSEC ist nach wie vor ein umstrittenes Thema, und Ihnen ist vielleicht aufgefallen, dass wir DNSSEC nicht in unsere Best Practices aufgenommen haben. Tatsächlich sind wir hin- und hergerissen. Einerseits bietet DNSSEC eine Funktion, die anderswo nicht verfügbar ist: kryptografische Integrität der autoritativen DNS-Auflösung. (Ein Beispiel dafür, warum das wichtig ist, finden Sie in diesem Blogbeitrag, der erläutert, wie DNSSEC die Sicherheit der Web-PKI verbessert.)

Andererseits ist die Verbreitung nach wie vor sehr gering. DNSSEC ist schwierig zu betreiben, und die Tools sind noch unausgereift. Die meisten Unternehmen verzichten auf DNSSEC, sofern es nicht von ihrer Hosting-Plattform automatisiert wird, auch wenn die Sicherheit darunter leidet.

Erschwerend kommt hinzu, dass die drohende Gefahr kryptografisch relevanter Quantencomputer bedeutet, dass DNSSEC die zugrunde liegenden kryptografischen Algorithmen wechseln muss. Wie diese Änderungen aussehen werden, ist jedoch noch unklar, ebenso, ob UDP angesichts der deutlich größeren Post-Quanten-Signaturen weiterhin als wichtigster Transportmechanismus dienen wird.

Zusammenfassend sind wir der Meinung, dass DNSSEC einen sehr wichtigen Zweck erfüllt, wir es aber nicht als Best Practice einstufen konnten, da es nicht allgemein als solche anerkannt ist.

Wird ein verwaister DNS-Eintrag oder ein verwaister Dienst ausgenutzt, können die Folgen sehr unangenehm sein. Es gibt jedoch eine mögliche Gegenmaßnahme, die darauf beruht, dass moderne Browser gültige X.509-Zertifikate voraussetzen. Könnten wir Angreifer daran hindern, ein gültiges Zertifikat zu erhalten, würden ihre Angriffsversuche möglicherweise scheitern.

Standardmäßig gilt: Wenn Sie eine IP-Adresse kontrollieren, auf die eine DNS-Domain verweist, können Sie dafür ein Zertifikat erhalten. Das muss aber nicht so sein, denn Domaininhaber können Richtlinien veröffentlichen, die die Domainvalidierung steuern. Die Technologie dafür heißt Certification Authority Authorization (CAA) und muss von allen öffentlichen CAs beachtet werden.

Im Zusammenhang mit Dangling DNS bietet CAA Ihnen mehrere Möglichkeiten: 1) Sie können die Zertifikatsausstellung für den gesamten Domainnamen zentralisieren und so vollständig verhindern, dass einzelne Server direkt Zertifikate erhalten; oder 2) Sie können erzwingen, dass für jede Domain ein bestimmtes ACME-Konto verwendet werden muss.

Die Plattform Attack Surface Monitoring von Red Sift (ASM), ehemals Hardenize, war weltweit die erste Plattform für tiefgehende kontinuierliche Erkennung und Überwachung, entwickelt für Unternehmen, die ihre eigene Internetpräsenz überwachen möchten. Innerhalb von ASM setzt die DNS-Komponente dieses Produkts die in diesem Dokument beschriebenen Monitoring-Aspekte vollständig um, darunter die Überwachung des Zustands autoritativer Dienste und der Verbindungen zu Dritten sowie die Erkennung verwaister DNS-Einträge und Dienste.

Brand Trust von Red Sift stoppt Angriffe mit Lookalike-Domains, bevor sie Ihrer Marke schaden. Die Lösung erkennt, überwacht und entfernt bösartige Lookalike-Domains mit KI-gestütztem Domain- und Markenschutz.

• RFC 9499: DNS-Terminologie
• NIST SP 800-81 Rev. 3: Leitfaden für die sichere DNS-Bereitstellung
• Red Sift: Der NIST-Leitfaden für die sichere DNS-Bereitstellung: Best Practices
• IANA: Technische Anforderungen an autoritative Nameserver