5. Autorisation

Les transferts de zone peuvent exposer des informations sensibles sur la structure et le contenu d'une zone, aidant potentiellement les attaquants dans des activités de reconnaissance. Pour cette raison, les serveurs AXFR emploient généralement des mécanismes d'autorisation pour restreindre les transferts de zone aux seuls clients de confiance.

Cette section décrit les techniques d'autorisation courantes utilisées dans les implémentations AXFR. Notez que ce document ne mandate aucune méthode d'autorisation spécifique; les implémenteurs et les opérateurs sont libres de choisir l'approche qui convient le mieux à leurs exigences de sécurité.

Techniques d'autorisation courantes

1. Listes de contrôle d'accès (ACL) : Un serveur AXFR PEUT utiliser des ACL basées sur les adresses IP pour restreindre les clients autorisés à demander des transferts de zone. Le serveur vérifie l'adresse IP source de la connexion TCP entrante par rapport à une liste configurée d'adresses ou de réseaux autorisés.

   • Avantages : Simple à implémenter et à configurer.
   • Limitations : Vulnérable à l'usurpation d'adresse IP (bien que la poignée de main en trois étapes de TCP fournisse une certaine protection). Non adapté aux clients avec des adresses IP dynamiques.

2. TSIG (Transaction Signature) : TSIG [RFC2845] fournit une authentification cryptographique des messages DNS en utilisant des clés secrètes partagées. Un serveur AXFR PEUT exiger une authentification TSIG pour les demandes de transfert de zone.

   • Avantages : Fournit une authentification forte et l'intégrité des messages. Ne dépend pas des adresses IP.
   • Limitations : Nécessite que des clés pré-partagées soient configurées sur le client et le serveur. La gestion des clés peut être difficile dans les grands déploiements.

3. SIG(0) (Signature) : SIG(0) [RFC2931] fournit une authentification basée sur la clé publique des messages DNS. Un serveur AXFR PEUT utiliser SIG(0) pour authentifier les requêtes AXFR.

   • Avantages : Utilise la cryptographie à clé publique, évitant le besoin de secrets pré-partagés. Adapté aux scénarios où la gestion des clés TSIG est impraticable.
   • Limitations : Plus complexe à implémenter et à configurer que TSIG. Nécessite une infrastructure à clé publique.

4. TLS/SSL : Bien que non spécifié dans ce document, un serveur AXFR PEUT utiliser TLS ou SSL pour chiffrer et authentifier les connexions TCP utilisées pour les transferts de zone. Cette approche n'est pas standardisée pour les transferts de zone DNS mais peut être utilisée dans des environnements privés ou contrôlés.

5. VPN ou réseaux privés : Dans certains déploiements, les transferts de zone sont effectués sur des réseaux privés (par exemple, VPN [RFC2764]) qui ne sont pas accessibles à l'Internet public. Cette approche repose sur la sécurité au niveau du réseau plutôt que sur l'authentification au niveau de l'application.

Politique d'autorisation

Un serveur AXFR DEVRAIT implémenter une politique d'autorisation configurable qui détermine quels clients sont autorisés à demander des transferts de zone. La politique DEVRAIT supporter au moins une des techniques d'autorisation listées ci-dessus.

Un serveur AXFR DOIT répondre aux requêtes AXFR non autorisées avec un message de réponse DNS contenant RCODE REFUSED (5). Cela informe le client que le transfert de zone a été refusé en raison de restrictions de politique.

Comportement par défaut

Le comportement par défaut d'un serveur AXFR concernant l'autorisation n'est pas spécifié par ce document. Les implémenteurs DEVRAIENT choisir un comportement par défaut sécurisé, tel que :

• Refuser toutes les demandes de transfert de zone par défaut, nécessitant une configuration explicite pour autoriser des clients spécifiques, ou
• Autoriser les transferts de zone uniquement depuis des adresses IP spécifiques configurées comme serveurs secondaires.

Un serveur AXFR NE DOIT PAS autoriser les transferts de zone non restreints vers des clients arbitraires par défaut, car cela pose un risque de sécurité significatif.

Méthodes d'autorisation multiples

Un serveur AXFR PEUT supporter plusieurs méthodes d'autorisation simultanément. Par exemple, un serveur pourrait exiger à la fois la correspondance ACL basée sur l'adresse IP et l'authentification TSIG pour qu'un transfert de zone soit autorisé. Les spécificités de la combinaison de plusieurs méthodes d'autorisation dépendent de l'implémentation.

Échecs d'autorisation

Si une requête AXFR échoue aux contrôles d'autorisation, le serveur AXFR DEVRAIT répondre avec RCODE REFUSED. Le serveur PEUT enregistrer la tentative d'autorisation échouée à des fins d'audit.

Un serveur AXFR NE DOIT PAS révéler les détails sur les raisons de l'échec de l'autorisation (par exemple, en retournant différents codes d'erreur pour différentes raisons d'échec), car cela pourrait fournir des informations utiles aux attaquants potentiels.