Résumé

  • La réponse DNS NOTIFY confirme la réception de la notification ; elle ne contient aucune information utile sur la zone.
  • Il reste à comparer les séries SOA, effectuer IXFR ou AXFR, charger la version reçue puis observer les réponses faisant autorité.
  • Une preuve de publication doit conserver ces étapes au lieu de transformer un accusé de notification en garantie de service.

Une notification reçue n’est qu’un départ

RFC 1996 accélère la propagation en remplaçant l’attente passive du délai de rafraîchissement par une interruption. Le maître annonce qu’un changement existe. Quand la réponse correspondante arrive, il sait que le secondaire a reçu le NOTIFY et peut retirer cet événement de sa file de relance.

Ce reçu ne rapporte ni la série SOA locale, ni la décision de transfert, ni la version chargée. Le texte précise même que la réponse ne transporte aucune information utile. La métrique « NOTIFY réussi » décrit donc le canal de signalement. Elle ne décrit pas encore l’état publié.

Après un NOTIFY SOA valide, le secondaire interroge un maître connu, compare les séries, puis lance IXFR ou AXFR si la série distante a avancé. Chacune de ces transitions peut aboutir, attendre ou échouer indépendamment de l’accusé initial.

Le transfert ne termine pas toute la chaîne

La section de réponse éventuellement jointe au NOTIFY n’est qu’un indice non sécurisé. Elle ne peut mettre à jour la zone locale ni imposer un transfert. Cette limite empêche qu’une notification devienne un canal de données implicite.

RFC 1982 rappelle aussi qu’une série DNS ne se compare pas comme un entier ordinaire dans tous les cas. Une preuve exploitable conserve les deux valeurs et le résultat de comparaison. IXFR transmet des différences ; AXFR transmet une zone complète. RFC 5936 définit le transfert comme mécanisme de cohérence entre serveurs faisant autorité, mais un transfert terminé ne prouve pas que tous les processus ont activé la nouvelle génération.

Un nœud anycast peut rester sur une ancienne image, un rechargement peut échouer, ou un déploiement peut ne toucher qu’une partie de la flotte. La preuve finale doit donc venir aussi de requêtes faisant autorité visant le SOA et un RRset effectivement modifié.

Sources