> selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS,
> c'est une problématique satellite. Il existe d'autre méthodes pour transferer
> ses zones : http, rsync, ssh, par clé USB, etc...
Ah oui mais là ton transfert n'est pas interopérable entre serveurs : ça devient un transfert de fichiers au format d'une implémentation de serveur DNS. Or interop => protocole+specs, c'est donc pas plus mal que cette question soit normalisée ;)
Un autre intérêt d'AXFR, c'est que le proto est implémenté par le serveur lui-même (au lieu d'un outil externe comme rsync), et ça lui permet de savoir qu'il doit recharger la zone dès qu'elle est rafraichie (rsync, ssh ou http ne font que transférer des fichiers, sans se préoccuper de l'applicatif).
Cela dit, je suis d'accord pour le qualificatif de « problématique satellite ».
[^] # Re: Et SCTP ?
Posté par herodiade . En réponse au journal BIND, 2ème édition. Évalué à 2.
Ah bin oui, tu as tout à fait raison.
> selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS,
> c'est une problématique satellite. Il existe d'autre méthodes pour transferer
> ses zones : http, rsync, ssh, par clé USB, etc...
Ah oui mais là ton transfert n'est pas interopérable entre serveurs : ça devient un transfert de fichiers au format d'une implémentation de serveur DNS. Or interop => protocole+specs, c'est donc pas plus mal que cette question soit normalisée ;)
Un autre intérêt d'AXFR, c'est que le proto est implémenté par le serveur lui-même (au lieu d'un outil externe comme rsync), et ça lui permet de savoir qu'il doit recharger la zone dès qu'elle est rafraichie (rsync, ssh ou http ne font que transférer des fichiers, sans se préoccuper de l'applicatif).
Cela dit, je suis d'accord pour le qualificatif de « problématique satellite ».