La décision d'effectuer ou non le transfert de zone repose uniquement sur le numéro de série de l'enregistrement SOA de la zone. Si ces numéros de série sont configurés à la main par un administrateur, celui-ci doit bien prendre garde à mettre à jour le numéro de série à chaque modification et que celui ci augmente toujours sous peine de ne pas les propager. Ce processus peut facilement générer des erreurs. Une bonne pratique (nullement obligatoire, et pas toujours suivie) consiste à noter le numéro de série sous la forme AAAAMMJJSS où AAAA est l'année, MM le mois, JJ le jour et SS un numéro incrémenté au fur et a mesure des modifications effectuées dans le journée.
Certain systèmes DNS génèrent automatiquement ce numéro de série en fonction de la date de dernière modification du fichier de zone (cas de djbdns (en)). La responsabilité est reportée sur le système d'exploitation et sa synchronisation. Si le fichier est édité pour ajouter un commentaire par exemple, le numéro de série est automatiquement modifié alors qu'aucun changement n'est opéré.
Le paradigme du numéro de série (et du transfert de zone) est qu'il impose d'avoir un serveur maître unique qui assure seul la référence de la zone pour l'ensemble des serveurs esclaves (un serveur esclave peut être maître d'un autre esclave). Certain systèmes DNS permettent de s'affranchir du transfert de zone en utilisant en sous main les mécanismes de réplication multi-maître de certaines bases de données SQL ou LDAP (openldap, Active Directory). Il faut cependant noter que de telles implémentations s'avèrent très gourmandes en bande passante et nécessitent une synchronisation temporelle précise.
La comparaison des numéros de série devrait se baser sur l'Arithmétique des numéros de série décrite dans la RFC 1982. Mais la RFC 1034 n'y fait pas explicitement référence ce qui a pour conséquences que l'ensemble des esclaves déclenchent pas le transfert de zone sur les mêmes critères.
Dans le processus actuel de transfert de données, chaque groupe d'enregistrements (RR) pour un nom de domaine unique était transféré par le serveur au client dans un message DNS séparé ce qui n'optimise pas du tout l'utilisation de la bande passante. Certain systèmes DNS pallient a ce problème en compressant des données et en les insérant comme suit :
Ces systèmes deviennent alors incompatibles avec ceux qui respectent strictement la norme ou implémentent une option spécifique.