Avant le DNS, la résolution d'un nom sur Internet devait se faire grâce à un fichier texte appelé HOSTS.TXT (RFC 608) maintenu par le NIC du Stanford Reseach Institute (SRI) et recopié sur chaque ordinateur par transfert de fichier. En 1982, ce système centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le système distribué Grapevine de Xerox et IEN 116. Le premier est jugé trop compliqué tandis que le second est insuffisant. La tâche de développer un autre système revient à Paul Mockapetris qui publie le design du système dans les RFC 882 et RFC 883 en 1983. La norme correspondante est publiée dans les RFC 1034 et RFC 1035 en 1987. En 1987, le fichiers HOSTS.TXT contenait 5500 entrées, tandis que 20000 hôtes étaient définis dans le DNS.
On entend par Fully qualified domain name (FQDN), ou Nom de domaine pleinement qualifié un nom de domaine écrit de façon absolue, y compris tous les domaines jusqu'au domaine de premier niveau (TLD), il est ponctué par un point final, par exemple fr.wikipedia.org.
La norme prévoit qu'un élément d'un nom de domaine (appelé label) ne peut dépasser 63 caractères, un FQDN ne pouvant dépasser 253 caractères.
Il existe 13 serveurs racine, nommés de a à m.root-servers.net. Ces serveurs sont gérés par douze organisations différentes : deux sont européennes, une japonaise et les neuf autres sont américaines. Sept de ces serveurs sont en réalité distribués dans le monde grâce à la technique anycast et sept disposent d'une adresse IPv6. Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service. Le serveur k reçoit par exemple de l'ordre de 20 000 requêtes par seconde.
Le DNS ne fournit pas de mécanisme pour découvrir la liste des serveurs racine, chacun des serveurs doit donc connaître cette liste au démarrage grâce à un encodage explicite. Cette liste est ensuite mise à jour en consultant l'un des serveurs indiqués. La mise à ce jour de cette liste est peu fréquente de façon à ce que les serveurs anciens continuent à fonctionner.
Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet), qui consiste à associer plusieurs adresses IP à un nom de domaine. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).
Dans leur définition initiale, les noms de domaines sont constitués des caractères de A à Z (sans casse : les lettres capitales ne sont pas différenciées), de chiffres et du trait d'union.
La RFC 3490 définit un format appelé Punycode qui permet l'encodage d'un jeu de caractère plus étendu.
Chaque record est associé à un Time to live (TTL) qui détermine combien de temps il peut être conservé dans un serveur cache. Ce temps est typiquement d'un jour (86400 s) mais peut être plus élevé pour des informations qui changent rarement, comme des records NS. Il est également possible d'indiquer que des informations ne doivent pas être mises en cache en spécifiant un TTL de zéro.
Certaines applications, comme des navigateurs web disposent également d'un cache DNS, mais qui ne respecte pas nécessairement le TTL du DNS. Ce cache applicatif est généralement de l'ordre de la minute, mais Internet Explorer par exemple conserve les informations jusqu'à 30 minutes, indépendamment du TTL configuré.