7. Compatibilité ascendante

Décrire la compatibilité ascendante est difficile en raison du manque de spécificités dans la définition originale. Dans cette section, quelques indices pour construire la compatibilité ascendante sont donnés, principalement répétés des sections antérieures pertinentes.

La compatibilité ascendante n'est pas nécessaire, mais plus l'étendue de la compatibilité d'une implémentation est grande, plus son interopérabilité est grande. Pour les implémentations clés en main, ce n'est généralement pas une préoccupation. Pour les implémentations à usage général, cela prend des niveaux d'importance variables, selon le désir de l'implémenteur de maintenir l'interopérabilité.

Il est regrettable qu'un besoin de revenir au comportement plus ancien ne puisse pas être découvert, et doive donc être noté dans un fichier de configuration. Une implémentation DEVRAIT, dans sa documentation, encourager les opérateurs à examiner périodiquement les clients et serveurs AXFR sur lesquels elle a pris des notes de manière répétée, car les anciens logiciels sont mis à jour de temps en temps.

7.1. Serveur

Un serveur AXFR a le luxe de pouvoir réagir aux capacités d'un client AXFR, à l'exception de savoir si le client peut accepter plusieurs enregistrements de ressources par message de réponse AXFR. La connaissance qu'un client est ainsi restreint ne peut pas être découverte; par conséquent, elle doit être définie par configuration.

Une implémentation d'un serveur AXFR PEUT permettre de configurer, sur une base par client AXFR, la nécessité de revenir à un seul enregistrement de ressource par message; dans ce cas, la valeur par défaut DEVRAIT être d'utiliser plusieurs enregistrements par message.

Considérations pour les clients hérités :

1. Un seul RR par message : Certaines implémentations DNS très anciennes s'attendent à un seul enregistrement de ressource dans la section de réponse de chaque message de réponse AXFR. Les serveurs AXFR modernes DEVRAIENT supporter plusieurs RR par message pour l'efficacité, mais PEUVENT fournir une option de configuration pour revenir au comportement à RR unique pour des clients hérités spécifiques.

2. Taille de message : Les clients plus anciens peuvent avoir des limitations sur la taille maximale des messages DNS qu'ils peuvent traiter. Les serveurs AXFR PEUVENT fournir des options de configuration pour limiter la taille des messages de réponse individuels lors de l'interaction avec de tels clients.

3. EDNS(0), TSIG et SIG(0) : Les clients plus anciens peuvent ne pas supporter EDNS(0), TSIG ou SIG(0). Un serveur AXFR DEVRAIT gérer gracieusement les requêtes des clients qui n'incluent pas ces options et NE DEVRAIT PAS exiger leur présence sauf s'il est spécifiquement configuré pour le faire pour des raisons de sécurité.

Recommandations pour les implémentations de serveur :

• Par défaut vers un comportement moderne et efficace (plusieurs RR par message, support pour EDNS(0)/TSIG/SIG(0)).
• Fournir des options de configuration pour accommoder les clients hérités sur une base par client.
• Documenter les problèmes de compatibilité connus et les paramètres de configuration recommandés pour interopérer avec les logiciels plus anciens.

7.2. Client

Un client AXFR a l'opportunité d'essayer d'autres fonctionnalités (c'est-à-dire, celles non définies par ce document) lors de l'interrogation d'un serveur AXFR.

Tenter d'émettre plusieurs requêtes DNS sur un transport TCP pour une session AXFR DEVRAIT être abandonné si cela interrompt la requête originale, et DEVRAIT prendre en considération si le serveur AXFR a l'intention de fermer la connexion immédiatement après l'achèvement du transfert de zone original (causant la connexion).

Considérations pour les serveurs hérités :

1. Plusieurs RR par message : Les clients AXFR modernes DOIVENT être préparés à recevoir plusieurs enregistrements de ressources dans un seul message de réponse AXFR. Il s'agit d'un comportement standard et qui est largement déployé depuis de nombreuses années.

2. Gestion de connexion : Les serveurs plus anciens peuvent fermer la connexion TCP immédiatement après l'envoi du RR SOA final, tandis que d'autres peuvent garder la connexion ouverte pendant une période de temps. Les clients AXFR DEVRAIENT être préparés à l'un ou l'autre comportement et NE DEVRAIENT PAS compter sur le fait que la connexion reste ouverte après la fin du transfert de zone.

3. Réponses d'erreur : Certains serveurs plus anciens peuvent retourner des réponses d'erreur non standard ou peuvent ne pas se conformer strictement au format de message DNS. Les clients AXFR DEVRAIENT implémenter une gestion d'erreur robuste pour gérer gracieusement les réponses inattendues.

Recommandations pour les implémentations de client :

• Supporter toutes les fonctionnalités standard définies dans ce document.
• Implémenter une gestion d'erreur robuste pour tolérer des déviations mineures par rapport à la spécification.
• Éviter de compter sur la persistance de connexion ou d'autres comportements non standard.
• Être prêt à revenir à un comportement plus simple (par exemple, ne pas utiliser EDNS(0)) si un serveur semble ne pas le supporter.