Jegliche Kommunikation innerhalb des DNS Protokolls basiert auf  sog. DNS Messages.
Speziell die DNS Nachrichten, die zwischen zwei Name-Servers im  Rahmen von Zonentransfers ausgetauscht werden, nämlich DNS  NOTIFY Message(s) vom Master (oder auch Slave) an den Slave und DNS  AXFR/IXFR Request/Response Messages zwischen Slave und Master (oder  zwischen Slaves), können durch Einsatz eines symmetrischen Kryptographieverfahrens  auf Transaktionsebene geschützt werden.

Dieser als Transaction Signatures bezeichnete Mechanismus ist in  [RFC2845] spezifiziert und nutzt ein "Shared Secret" – d.h. einen  gemeinsamen symmetrischen Schlüssel –, um die zwischen zwei Parteien  ausgetauschten DNS Messages zu signieren.
Über entsprechende "Access Control Lists" (ACL) (auf Basis  dieses Shared Secret) wird zudem gesteuert, ob die genannten DNS  Nachrichten von der Gegenseite überhaupt akzeptiert werden.
Hat einer der beteiligten Name-Server eine entsprechende  ausgehende Nachricht generiert, so wird auf diese vor dem tatsächlichen  Versand eine "Keyed One-Way Hash Function" zur Erzeugung eines  128-bit großen "Message Digest" angewendet. Als Key kommt dabei der  gemeinsame symmetrische Schlüssel von sendender und empfangender Partei  zum Einsatz.

In komplexeren DNS Topologien ist meist die Trennung zwischen  allgemein und eingeschränkt sichtbaren Zoneninformationen erforderlich. Diese Art der NS Konfiguration, die als "Split Namespace" bezeichnet wird, kommt üblicherweise auf speziell gesicherten Systemen  einer "De-Militarisierten Zone" (DMZ), dem sogenannten "Bastion Hosts" zum Einsatz. Die Split Namespace Konfiguration einer DMZ Nameserver-Instanz  verfügt i.d.R. über folgende Eigenschaften:

• Bereitstellung  einer bewusst kleingehaltenen Menge offizieller und öffentlich  verfügbarer Resource Records (sog. "External View" oder auch "Shadow  Namespace") einer Domain zur Auflösung von Anfragen externer DNS  Clients. Typische Beispiele hierfür sind der SOA Record der Domain, NS  Records, MX Records für den Email-Exchange, sowie einige wenige A  Records und ihre jeweiligen PTR Records.
• Fähigkeit,  interne Namen und IP-Adressen parallel zum externen Resolving  aufzulösen, wobei die Nutzung dieser Fähigkeit jedoch i. d. R. auf  Anfragen aus der DMZ (und ggfs. aus dem Intranet) beschränkt ist.

Name-Server  beantworten prinzipiell zwei Arten von Anfragen: iterative und  rekursive.
Dieses Verhalten gilt es aus Sicherheitsgründen auf  das absolut erforderliche Maß einzuschränken, ohne dabei die Nutzbarkeit  des Dienstes selbst in Frage zu stellen. Hierarchisch  gegliederte Namensräume und die physische Segmentierung von  Netzwerk-Topologien machen es möglich, Klassen von Name-Servers zu  definieren, bei denen die genannten Anfragetypen entweder vollständig  voneinander getrennt sind oder hinsichtlich ihrer Verfügbarkeit lokal  beschränkt werden können.

Ein  Name-Server, der grundsätzlich keine rekursiven Queries beantwortet und  keinen entsprechenden Daten-Cache aufbaut. Beispiele hierfür sind die NS  der (Internet) Root Domain und (üblicherweise) Hidden Primary Master  Name-Server.

Ein  Name-Server, der Empfänger von rekursiven Queries ist, die von entfernten Name-Servers an ihn weitergeleitet wurden. Besagte entfernte NS nutzen eine Forwarding-Konfiguration, mittels der ausgewählte oder auch alle  bei ihnen eingehenden rekursiven Queries als solche an einen oder mehrere Forwarders durchgereicht werden.

Ein  Name-Server, der für keine Zone autoritativ zuständig ist. Die einzigste Funktion dieses NS-Typs besteht darin, angefragte RRs bei anderen Name-Servers zu  ermitteln und in seinem Cache (zur Beantwortung entsprechender Anfragen) vorzuhalten.

Ein Slave  Name-Server, der nicht in den NS Records der Zonen gelistet ist, für die  er autoritativ ist; dadurch ist sichergestellt, dass sich dieser  (zusätzliche) Name-Server nicht negativ auf die Größenlimitierung  UDP-basierter DNS Response Messages auswirkt und entfernte Name-Server  keiner Delegation zu diesem Slave folgen können.

Ein Slave  Name-Server, welche anstelle des Hidden Primary Master Name-Server nach außen  hin in derRolle des Primary Master Name-Server auftritt. Um diese Rolle ausfüllen zu können, ist dieser Server nicht nur – wie üblich – in den NS Records der Zone gelistet, für die  er autoritativ ist, sondern auch in den SOA Records (MNAME Feld) der  besagten Zone mit eingetragen.

Ein Hidden Primary  Master Name-Server wird nicht in den Name-Server Records der Zone (im Zonenfile) gelistet,  für die er eigentlich autoritativ zuständig ist. Hierdurch wird sichergestellt, dass entfernte  Name-Server keiner Delegation zu diesem wirklichen Master Name-Server folgen können. Somit ist dieser  „versteckt“. Diese Art des DNS-Designs findet Verwendung meist in Sicherheitsarchitekturen oder bei kleinen Firmen.

Das Synonym für einen Secondary Names-Server lautet  Slave Name-Server. Ein Secondary Name-Servers ist ein redundanter Autoritativer Name-Server für eine bestimmte Zone. Die Name-Server-Instanz erhält ihre Zonendaten vom Primary Master Name-Server  oder einem anderen Slave Name-Server.

Ein primary Master Nameserver ist ein autoritativer  Nameserver für eine bestimmte Zone (bspw. je-ru.de), innerhalb der Nameserver-Instanz erfolgt  die Pflege der eigentlichen Zonendaten.

Dieser  Query-Typ findet in der Kommunikation zwischen Name-Servers Verwendung,  und zwar dann, wenn diese (quasi in Kooperation) eine rekursive Anfrage  weiterbearbeiten.
Wird z. B. rekursiv nach der IP-Adresse von  www.je-ru.de gefragt, so überprüft der angefragte Name-Server  zunächst, ob ihm die autoritativen Name-Servers für die Domain  je-ru.de bekannt sind. Ist dies der Fall, so sendet der Name-Server  eine entsprechende iterative Anfrage an einen dieser Servers;  andernfalls wird einer der autoritativen de Name-Servers (falls bekannt)  und in letzter Instanz einer der (Internet) Root Name-Servers befragt. Der  Name-Server, der eine iterative Anfrage erhält, liefert als Resultat die  bestmögliche Antwort, die in seinem lokalen Datenbestand (inklusive  Cache) gefunden wird. Dies ist entweder die tatsächlich nachgefragte  IP-Adresse (oder der nachgefragte Name) oder eine Referral-Liste, die  alle „näher“ am Ziel der Anfrage liegenden autoritativen Name-Servers  enthält. Verwaltet der anfragende Name-Server aufgrund früherer  Anfragen sog. Round Trip Times (RTT) für die in der Referral-Liste  genannten Servers, so wählt er denjenigen mit der niedrigsten RTT aus  und wiederholt dort die iterative Anfrage. Dieser Prozess setzt sich  solange fort, bis eine tatsächliche Antwort vorliegt.

Diese Art von Queries wird von (Stub) Resolver Hosts oder von Name-Servern, die Forwarder benutzen, initiiert.

Rekursive Anfragen zur Namensauflösung weisen dem angefragten NS-System die exklusive Aufgabe zu, alle notwendigen Schritte zur Erfüllung der Anfrage durchzuführen. Eine Delegation der Arbeitsschritte an andere Name-server oder die Rückgabe von Referrals an den anfragenden Client sind nicht vorgesehen bzw. nicht erlaubt.
Der adressierte Name-Server kann die Anfrage entweder direkt beantworten oder andere Name-Servers iterativ (siehe unten) anfragen, bis eine Antwort vorliegt.