Les mises à jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mécanisme appelé transfert de zone. Pour déterminer si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numéro de version de la zone et le compare à la version qu'il possède. Le serveur primaire détermine à quelle fréquence le numéro de version est consulté. Quand un changement est effectué, les serveurs envoient des messages de notification aux serveurs secondaires pour accélérer le processus.
Il se peut que des informations qui ne sont plus à jour soient cependant conservées dans des serveurs cache. Il faut alors attendre l'expiration de leur Time to live pour que ces informations cachées disparaissent et donc que la mise à jour soit pleinement effective. On peut minimiser le temps nécessaire en diminuant le TTL associé aux noms de domaines qui vont être modifiées préalablement à une opération de changement.
Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un Glue Record est modifiée, le gestionnaire du domaine de niveau supérieur doit effectuer la mise à jour correspondante.
Pour éviter les points individuels de défaillance, on évite de partager l'infrastructure entre les serveurs qui font autorité. Un serveur secondaire sera de préférence délocalisé et routé différemment que le serveur primaire.
Bien que cela soit techniquement possible, on évite de mêler sur un même serveur le rôle de DNS récursif et celui de serveur qui fait autorité.
De même, un hôte sera configuré avec plusieurs serveurs récursifs, de sorte que si le premier ne répond pas à la requête, le suivant sera employé. En général, les serveurs récursifs fournis par les FAI refusent les requêtes émanant d'adresses IP appartenant à d'autres FAI.
Il existe des services de DNS récursifs ouverts, c'est-à-dire qu'ils acceptent les requêtes de tous les clients. Il est donc possible à un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problèmes suivants :
Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation utilisés. Pour exemple sur Windows la commande nslookup est disponible via l'invite de commande MS-DOS :
C:\>nslookup www.google.fr Serveur: Livebox-6370 Address: 192.168.1.1 Réponse ne faisant pas autorité: Nom: www.l.google.com Addresses: 209.85.229.104 209.85.229.106 209.85.229.103 209.85.229.147 209.85.229.105 209.85.229.99 Aliases: www.google.fr www.google.com ou encore dig sur les systèmes UNIX :
dig www.google.com aaaa ; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 422901 IN CNAME www.l.google.com. www.l.google.com. 77 IN AAAA 2a00:1450:8004::67 www.l.google.com. 77 IN AAAA 2a00:1450:8004::68 www.l.google.com. 77 IN AAAA 2a00:1450:8004::69 www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a www.l.google.com. 77 IN AAAA 2a00:1450:8004::93 www.l.google.com. 77 IN AAAA 2a00:1450:8004::63 ;; AUTHORITY SECTION: google.com. 155633 IN NS ns2.google.com. google.com. 155633 IN NS ns1.google.com. google.com. 155633 IN NS ns3.google.com. google.com. 155633 IN NS ns4.google.com. ;; Query time: 0 msec ;; SERVER:::1#53(::1) ;; WHEN: Sun May 23 16:23:49 2010 ;; MSG SIZE rcvd: 292