6. Intégrité de la zone

Assurer l'intégrité des données de zone transférées est critique pour maintenir la sécurité et la fiabilité de l'infrastructure DNS. Cette section discute des considérations d'intégrité pour AXFR et recommande les meilleures pratiques.

Menaces d'intégrité

Les transferts de zone sont soumis à plusieurs menaces d'intégrité :

1. Attaques de l'homme du milieu : Un attaquant positionné entre le client AXFR et le serveur pourrait intercepter et modifier les données de zone en transit.

2. Attaques par usurpation : Un attaquant pourrait usurper l'identité d'un serveur AXFR et envoyer des données de zone falsifiées à un client AXFR.

3. Attaques par rejeu : Un attaquant pourrait capturer un transfert de zone légitime et le rejouer ultérieurement, causant potentiellement la réversion du client vers des données de zone obsolètes.

4. Modifications non autorisées : Sans authentification et vérifications d'intégrité appropriées, un attaquant pourrait injecter, supprimer ou modifier des enregistrements de ressources pendant un transfert de zone.

Mécanismes de protection de l'intégrité

Pour se protéger contre ces menaces, les implémentations AXFR DEVRAIENT employer un ou plusieurs des mécanismes de protection de l'intégrité suivants :

TSIG (Transaction Signature)

TSIG [RFC2845] fournit une authentification et une protection d'intégrité au niveau message en utilisant des clés secrètes partagées et des algorithmes HMAC.

Comment TSIG fonctionne pour AXFR :

1. Le client AXFR inclut un RR TSIG dans son message de requête, signé avec une clé pré-partagée.

2. Le serveur AXFR valide la signature TSIG sur la requête. Si la validation échoue, le serveur répond avec RCODE NOTAUTH ou REFUSED.

3. Si la requête est valide, le serveur AXFR inclut des RR TSIG dans ses messages de réponse :

   • Le premier message de réponse DOIT inclure un RR TSIG.
   • Les messages intermédiaires PEUVENT omettre TSIG (pour l'efficacité), mais la séquence est toujours protégée par le TSIG sur les premier et dernier messages.
   • Le dernier message de réponse DOIT inclure un RR TSIG.

4. Le client AXFR valide les signatures TSIG sur les messages de réponse. Si une validation échoue, le client DOIT rejeter l'intégralité du transfert de zone.

Avantages : TSIG fournit une protection d'intégrité forte et une authentification mutuelle. Il est largement supporté dans les implémentations DNS.

Limitations : Nécessite des clés pré-partagées, qui doivent être distribuées et gérées de manière sécurisée.

SIG(0) (Signature)

SIG(0) [RFC2931] fournit une authentification de message basée sur la clé publique en utilisant des signatures de style DNSSEC.

Comment SIG(0) fonctionne pour AXFR :

1. Le client AXFR signe son message de requête avec sa clé privée et inclut le RR SIG(0) résultant dans la requête.

2. Le serveur AXFR valide la signature en utilisant la clé publique du client (récupérée via DNS ou depuis une ancre de confiance locale).

3. Le serveur AXFR PEUT signer ses messages de réponse avec sa propre clé privée, permettant au client de vérifier l'authenticité de la réponse.

Avantages : Élimine le besoin de secrets pré-partagés. Adapté aux scénarios où la distribution de clés est difficile.

Limitations : Plus complexe à implémenter et configurer que TSIG. Repose sur l'infrastructure à clé publique.

DNSSEC

Pour les zones qui sont signées DNSSEC, le client AXFR peut valider l'intégrité des données de zone transférées en utilisant des signatures DNSSEC (enregistrements RRSIG).

Comment DNSSEC protège AXFR :

1. Le serveur AXFR transfère la zone, incluant tous les enregistrements RRSIG, DNSKEY et NSEC/NSEC3.

2. Le client AXFR valide les signatures RRSIG sur les RRsets transférés en utilisant les enregistrements DNSKEY dans la zone.

3. Si la validation DNSSEC échoue, le client NE DEVRAIT PAS servir les données de zone.

Avantages : Fournit une protection d'intégrité de bout en bout pour les données de zone, pas seulement pendant le transfert mais aussi lorsque les données sont servies aux résolveurs.

Limitations : Nécessite que la zone soit signée DNSSEC. Ne protège pas le protocole AXFR lui-même (par exemple, contre les clients non autorisés).

Sécurité au niveau réseau

En plus des mécanismes de sécurité au niveau application, les transferts AXFR PEUVENT être protégés en utilisant la sécurité au niveau réseau :

1. TLS/SSL : Le chiffrement de la connexion TCP à l'aide de TLS ou SSL fournit une protection de confidentialité et d'intégrité pour le transfert de zone. (Note : DNS-over-TLS pour les transferts de zone n'est pas standardisé au moment de la rédaction.)

2. IPsec : Les transferts de zone effectués sur des connexions protégées par IPsec bénéficient de la confidentialité, de l'intégrité et de l'authentification fournies par IPsec.

3. VPN ou réseaux privés : Effectuer des transferts de zone sur un réseau privé (tel qu'un VPN) peut fournir une couche de sécurité supplémentaire.

Recommandations

1. Utiliser TSIG ou SIG(0) : Les serveurs et clients AXFR DEVRAIENT supporter et utiliser TSIG ou SIG(0) pour protéger les transferts de zone. TSIG est la solution la plus couramment déployée et est RECOMMANDÉE pour la plupart des déploiements.

2. Valider les données transférées : Les clients AXFR DEVRAIENT valider l'intégrité des données de zone reçues avant de les valider dans leur base de données de zone locale. Pour les zones signées DNSSEC, cette validation inclut la vérification des signatures DNSSEC.

3. Gestion sécurisée des clés : Pour les déploiements basés sur TSIG, les opérateurs DOIVENT s'assurer que les clés partagées sont générées à l'aide de générateurs de nombres aléatoires cryptographiquement forts et sont stockées et distribuées de manière sécurisée.

4. Surveiller les anomalies : Les opérateurs DEVRAIENT surveiller les transferts de zone pour détecter les anomalies, telles que des changements inattendus de la taille de la zone, des fréquences de transfert inhabituelles ou des vérifications d'intégrité échouées.

5. Utiliser des algorithmes forts : Lors de l'utilisation de TSIG, les opérateurs DEVRAIENT utiliser des algorithmes HMAC forts, tels que HMAC-SHA256 ou HMAC-SHA512, plutôt que des algorithmes plus faibles comme HMAC-MD5. Voir [RFC4635] et [RFC5702] pour des conseils sur la sélection d'algorithmes.

Gestion des échecs d'intégrité

Si un client AXFR détecte un échec d'intégrité (par exemple, échec de validation TSIG, échec de validation DNSSEC), il DOIT :

1. Rejeter toutes les données reçues du transfert de zone échoué.
2. Enregistrer l'échec à des fins d'audit et de dépannage.
3. Optionnellement, réessayer le transfert de zone après un délai approprié (avec backoff).

Un client AXFR NE DOIT PAS valider des données de zone partiellement reçues ou ayant échoué l'intégrité dans sa base de données de zone autoritaire, car cela pourrait entraîner le service de données incorrectes ou malveillantes aux clients DNS.