Le numéro de série changeEdit
La partie préambule du transfert de zone s’appuie sur le numéro de série, et seulement le numéro de série, pour déterminer si les données d’une zone ont changé, et donc si le transfert réel des données est nécessaire. Pour certains paquets de serveurs DNS, les numéros de série des enregistrements de ressources SOA sont conservés à la main par les administrateurs. Chaque modification de la base de données implique d’effectuer deux changements, l’un sur l’enregistrement à modifier et l’autre sur le numéro de série de la zone. Ce processus exige de la précision : l’administrateur peut oublier de modifier le numéro de série ou le modifier de manière incorrecte (le réduire). Le RFC 1912 (section 2.2 SOA records) recommande d’utiliser la valeur YYYYMMDDnn comme numéro (YYYY=année, MM=mois, DD=jour, nn=numéro de révision). Cela ne débordera pas avant l’année 4294.
Certains paquets de serveurs DNS ont surmonté ce problème en construisant automatiquement le numéro de série à partir de l’horodatage de la dernière modification du fichier de base de données sur le disque. C’est le cas de djbdns, par exemple. Le système d’exploitation s’assure que l’horodatage de la dernière modification est mis à jour chaque fois qu’un administrateur modifie le fichier de base de données, mettant effectivement à jour automatiquement le numéro de série, et soulageant ainsi les administrateurs de la nécessité d’effectuer deux modifications (à deux endroits différents) pour chaque changement unique.
En outre, le paradigme de la réplication de la base de données pour lequel la vérification du numéro de série (et en fait le transfert de zone lui-même) est conçu, qui implique un seul serveur DNS central détenant la version primaire de la base de données avec tous les autres serveurs DNS détenant simplement des copies, ne correspond tout simplement pas à celui de nombreux paquets de serveurs DNS modernes. Les progiciels de serveurs DNS modernes dotés de bases de données sophistiquées, comme les serveurs SQL et Active Directory, permettent aux administrateurs d’effectuer des mises à jour de la base de données à plusieurs endroits (ces systèmes utilisent la réplication multi-maître), le mécanisme de réplication propre à la base de données se chargeant de la réplication vers tous les autres serveurs. Ce paradigme ne correspond tout simplement pas à celui d’un nombre unique, central et croissant de façon monotone pour enregistrer les modifications, et est donc incompatible avec le transfert de zone dans une large mesure. Les paquets de serveurs DNS modernes avec des back ends de base de données sophistiqués vont souvent créer un numéro de série « shim », simulant l’existence d’un lieu central unique où les mises à jour sont effectuées, mais cela est au mieux imparfait.
Heureusement, pour cela et pour plusieurs raisons exposées plus loin, les serveurs DNS qui utilisent de tels back ends de base de données sophistiqués en général utilisent rarement le transfert de zone comme leur mécanisme de réplication de base de données en premier lieu, et emploient habituellement à la place les mécanismes de réplication de base de données distribués largement supérieurs que les back ends eux-mêmes fournissent.
Comparaisons de numéros de sérieModifier
Les comparaisons de numéros de série sont destinées à utiliser l’Arithmétique des numéros de série telle que définie dans le RFC 1982. Cependant, cela n’a pas été clairement spécifié dans le RFC 1034, ce qui fait que tous les clients n’effectuent pas la vérification du numéro de série, dans le préambule, de la même manière. Certains clients vérifient simplement que le numéro de série fourni par le serveur est différent de celui connu par le client, ou non nul. D’autres clients vérifient que le numéro de série fourni par le serveur se situe dans une fourchette donnée du numéro de série déjà connu par le client. D’autres clients encore effectuent ce dernier contrôle et vérifient en outre que le numéro de série fourni par le serveur n’est pas nul.
Enregistrements de ressources multiplesModification
À l’origine, lors du transfert réel des données, chaque ensemble d’enregistrements de ressources pour un seul nom de domaine et un seul type était transféré dans un message de réponse distinct du serveur au client. Cependant, ceci est inefficace, et certains logiciels de serveur DNS ont mis en œuvre des optimisations, visant à permettre au mécanisme de compression de réponse dans le protocole DNS de réduire les besoins totaux en bande passante des transferts de données, tels que :
- réaliser un « traitement de section supplémentaire » pour inclure tout ensemble d’enregistrements de ressources « glue » dans la même réponse qu’un ensemble d’enregistrements de ressources NS, SRV ou MX
- collecter tous les ensembles d’enregistrements de ressources relatifs à un seul nom de domaine ensemble et les envoyer, s’ils conviennent, dans une seule réponse
Certains clients ont été écrits pour ne s’attendre qu’au format de réponse original, et ne parviendraient pas à effectuer le transfert de données si de telles optimisations étaient employées. Plusieurs paquets de serveurs DNS ont donc un paramètre de configuration permettant aux administrateurs de spécifier l’utilisation de réponses au « format de réponse unique » pour les clients qui le requièrent.
Exposition des donnéesModification
Les données contenues dans une zone DNS peuvent être sensibles d’un point de vue de la sécurité opérationnelle. En effet, des informations telles que les noms d’hôtes des serveurs peuvent devenir publiques, ce qui peut être utilisé pour découvrir des informations sur une organisation et même fournir une surface d’attaque plus importante. En juin 2017, le registraire responsable des domaines de premier niveau russes a accidentellement activé les transferts de zone DNS via AXFR, ce qui a conduit à l’exposition accidentelle de 5,6 millions d’enregistrements.
En 2008, un tribunal du Dakota du Nord, aux États-Unis, a statué que le fait d’effectuer un transfert de zone en tant que personne extérieure non autorisée pour obtenir des informations qui n’étaient pas accessibles au public constitue une violation de la loi du Dakota du Nord.