Boîte à Outils Informatique
Guide

Comment vérifier un transfert de zone DNS AXFR

Ce guide montre comment vérifier un transfert de zone DNS AXFR à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. DNSSEC SERVFAIL provient souvent d’une chaîne de confiance cassée : DS parent, DNSKEY, RRSIG, algorithme ou dates de signature.

ThématiqueRéseau informatique →
⌚ Environ 3 min de lecture
Voir mes favoris
Réseau & DNS Intermédiaire 15-30 min

Ce guide montre comment vérifier un transfert de zone DNS AXFR à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. DNSSEC SERVFAIL provient souvent d’une chaîne de confiance cassée : DS parent, DNSKEY, RRSIG, algorithme ou dates de signature.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Identifier les critères déterminants

    DNSSEC SERVFAIL provient souvent d’une chaîne de confiance cassée : DS parent, DNSKEY, RRSIG, algorithme ou dates de signature.

  2. 2

    Recouper le contexte technique

    Comparer une requête avec validation et une requête +cd permet de distinguer donnée absente et échec de validation.

  3. 3

    dig ciblé

    Interroger DNSKEY/DS/RRSIG et l’autorité elle-même avant de modifier la zone.

  4. 4

    Écarter les erreurs de diagnostic

    Changer les clés DNSSEC sans synchroniser le DS parent peut prolonger le SERVFAIL.

  5. 5

    Valider le résultat

    La chaîne DS→DNSKEY→RRSIG valide et les dates de signature sont correctes. Seuls les secondaires autorisés peuvent AXFR et leur SOA serial converge.

Commandes utiles

nslookup -type=soa example.com
dig +dnssec example.com A
dig example.com DNSKEY
dig @ns1.example.com example.com AXFR

À retenir

  • AXFR doit être autorisé uniquement aux secondaires prévus ; le SOA serial aide à vérifier qu’ils reçoivent la bonne version.
  • Ouvrir AXFR à Internet expose toute la zone et n’est pas un test acceptable en production.
  • Seuls les secondaires autorisés peuvent AXFR et leur SOA serial converge.
← Tous les guides
Complément technique

DNS avancé : DNSSEC et AXFR se diagnostiquent depuis l’autorité

Repères techniques

  • DNSSEC SERVFAIL provient souvent d’une chaîne de confiance cassée : DS parent, DNSKEY, RRSIG, algorithme ou dates de signature.
  • Comparer une requête avec validation et une requête +cd permet de distinguer donnée absente et échec de validation.
  • AXFR doit être autorisé uniquement aux secondaires prévus ; le SOA serial aide à vérifier qu’ils reçoivent la bonne version.

dig ciblé

Interroger DNSKEY/DS/RRSIG et l’autorité elle-même avant de modifier la zone.

dig +dnssec example.com A
dig example.com DNSKEY
dig @ns1.example.com example.com AXFR

Pièges spécifiques

  • Changer les clés DNSSEC sans synchroniser le DS parent peut prolonger le SERVFAIL.
  • Ouvrir AXFR à Internet expose toute la zone et n’est pas un test acceptable en production.

Comment valider

  • La chaîne DS→DNSKEY→RRSIG valide et les dates de signature sont correctes.
  • Seuls les secondaires autorisés peuvent AXFR et leur SOA serial converge.

Preuves et vérifications

DNSSEC SERVFAIL provient souvent d’une chaîne de confiance cassée : DS parent, DNSKEY, RRSIG, algorithme ou dates de signature. Comparer une requête avec validation et une requête +cd permet de distinguer donnée absente et échec de validation.

Contrôle de résultat

La chaîne DS→DNSKEY→RRSIG valide et les dates de signature sont correctes. Seuls les secondaires autorisés peuvent AXFR et leur SOA serial converge.

Point d’attention

Changer les clés DNSSEC sans synchroniser le DS parent peut prolonger le SERVFAIL. AXFR doit être autorisé uniquement aux secondaires prévus ; le SOA serial aide à vérifier qu’ils reçoivent la bonne version.

Concepts liés

Référence primaire : RFC 5936 — DNS AXFR.

♡ 0