Neben der Protokollspezifikation und ihren Ergänzungen sind für den reibungslosen Betrieb des DNS einige operative Maßnahmen erforderlich. Während die Protokollkonformität in wesentlichen Teilen in den Händen der Softwarehersteller liegt, kann jeder DNS-Verwalter durch saubere operationelle Praxis zum ordnungsgemäßen Betrieb beitragen.
In dieser Liste werden einige RFC-Dokumente aus den Reihen BCP, also Best Current Practice und FYI, sprich For Your Information mit Bezug zum DNS-Betrieb vorgestellt.
BCP 20, RFC 2317 Havard Eidnes, Geert Jan de Groot, Paul Vixie 10 Seiten, März 1997
Dieses Dokument beschreibt eine Methode, Delegationen unterhalb der IN-ADDR.ARPA-Domain durchzuführen ohne die bisher notwendigen Byte-Grenzen beachten zu müssen, so wie es für weniger als 256 Adressen umfassenden Adreßraum notwendig ist. Das vorgestellte Verfahren soll ermöglichen, Adreßraum in Blöcken kleiner als 24-Bit Prefixe zu vergeben und gleichzeitig die Verantwortung für das zugehörige Reverse Mapping zu delegieren. Zur Anwendung des Verfahrens sind keinerlei Modifikationen in der Server- oder Resolver-Software notwendig, es ist mit dem ursprünglichen Algorithmus für das Reverse Mapping voll kompatibel.
Es werden außerdem einige operationelle Hinweise zur konkreten Implementierung gegeben.
BCP 16, RFC 2182 Robert Elz, Randy Bush, Scott Bradner, Michael A. Patton 12 Seiten, Juli 1997
Die Spezifikation des Domain Name Systems verlangt, daß für jede Zone mehrere unabhängige Server existieren. BCP 16 gibt Hinweise zur Auswahl der secondary server. Dabei sind sowohl der physikalische Aufstellungsort als auch deren Ansiedlung in der Netzwerktopologie von wesentlicher Bedeutung. Darüberhinaus wird die Anzahl der einzusetzenden Server diskutiert und generelle Hinweise zum Betrieb von Secondary Servern gegeben.
BCP 17, RFC 2219 Martin Hamilton, Russ Wright 8 Seiten, Oktober 1997
Es ist mittlerweile üblich, Netzwerkdienste wie anonyme FTP-Server, Gopher-Server und vor allem HTTP-Server für das World Wide Web mittels symbolischer Namen im DNS zu verbreiten, wobei üblicherweise CNAME-Records benutzt werden. Das ist aus verschiedenen Gründen sinnvoll, etwa weil dadurch Dienste transparent von einem System auf ein anderes verlagert werden oder weil Benutzer oder entsprechende Werkzeuge aus der Existenz eines symbolischen Namens auf das Dienstangebot einer Organisation schließen können.
Obwohl dieser Ansatz sehr weit verbreitet ist, gibt es bislang keine Spezifikation dieser symbolischen Namen. BCP 17 will diese Lücke füllen, wozu die gegenwärtig gebrauchten Namen den entsprechenden Diensten gegenübergestellt werden.
Wichtig bleibt dabei festzuhalten, daß die Verwendung symbolischer Namen allein auf lange Sicht keine ausreichende Lösung f:ür das Problem darstellt, einen bestimmten von einer Organisation angebotenen Netzwerkdienst zu finden. Innerhalb der IETF wird an anderen Lösungen gearbeitet, wobei wiederum eine Teillösung die Verwendung von SRV-Records im DNS ist.
FYI 27, RFC 1713 Artur Romao 13 Seiten, November 1994
Trotz seiner für das Funktionieren des Internet großen Bedeutung führt das Domain Name System ein Schattendasein in dem Sinne, daß auch Netzwerkadministratoren gern bereit sind, Ungereimtheiten und Konfigurationsfehler in Kauf zu nehmen, solange die Anwendungen, die die Auflösung von Namen in Adressen benötigen, nur halbwegs laufen. FYI 27 präsentiert einige Werkzeuge, mit deren Hilfe DNS-Administratoren ihre Konfigurationen überprüfen und Fahler und Probleme aufspüren können.