7. Questions de Conception
7. Questions de Conception
Cette section discute diverses décisions de conception et clarifications liées au protocole DNS UPDATE.
7.1. Ce document place intentionnellement toute la complexité dans le serveur. Le comportement du demandeur est largement non spécifié afin de donner aux demandeurs la plus grande liberté possible.
7.2. Les noms de propriétaire joker (c'est-à-dire les noms avec une étiquette "*") sont pris en charge dans le protocole UPDATE avec la restriction que le joker est désactivé (voir section 1.1.3). Cela signifie que les jokers dans les mises à jour sont traités littéralement et n'effectueront pas d'expansion ou de correspondance de joker.
7.3. Le TTL d'un RRset peut être mis à jour en supprimant le RRset puis en l'ajoutant à nouveau avec un nouveau TTL. Cependant, un CNAME ne peut pas coexister avec un autre RRset sur un nom, donc les mises à jour impliquant des CNAMEs doivent être effectuées avec soin pour éviter de créer des configurations illégales.
7.4. Les RRs en double seront silencieusement ignorés. Cela signifie que si une mise à jour tente d'ajouter un RR qui existe déjà dans la zone avec des RDATA identiques, la mise à jour réussira mais n'aura aucun effet sur le contenu de la zone.
7.5. On s'attend à ce qu'en l'absence de Secure DNS Update, un serveur n'accepte les mises à jour que si elles proviennent d'une adresse source qui a été statiquement configurée dans la description du serveur d'une zone maître principale. Les serveurs DHCP seraient des candidats probables pour l'inclusion dans cette liste statiquement configurée.
7.6. Il n'est pas possible de créer une zone en utilisant ce protocole, car il n'y a aucune disposition pour qu'un serveur esclave soit informé de qui sont ses serveurs maîtres. On s'attend à ce que ce protocole soit étendu à l'avenir pour couvrir ce cas. Par conséquent, à ce moment, l'ajout de RRs SOA n'est pas pris en charge. Pour des raisons similaires, la suppression de RRs SOA n'est pas non plus prise en charge.
7.7. Le prérequis pour spécifier qu'un nom possède au moins un RR diffère sémantiquement de QUERY, en ce que QUERY renverrait <NOERROR,ANCOUNT=0> plutôt que NXDOMAIN s'il était interrogé pour un RRset sur ce nom, tandis que la condition préalable d'UPDATE [Section 2.4.4] ne serait PAS satisfaite.
7.8. Il est possible qu'une réponse UDP soit perdue en transit et qu'une requête soit réessayée en raison d'une condition de délai. Dans ce cas, un UPDATE qui a réussi la première fois qu'il a été reçu par le maître principal pourrait finalement sembler avoir échoué lorsque la réponse à une requête en double est finalement reçue par le demandeur. (C'est parce que les prérequis d'origine peuvent ne plus être satisfaits après que la mise à jour ait été appliquée.) Pour cette raison, les demandeurs qui nécessitent un code de réponse précis doivent utiliser TCP.
7.9. Parce qu'un demandeur qui nécessite un code de réponse précis initiera sa transaction UPDATE en utilisant TCP, un transitaire qui reçoit une requête via TCP doit la transférer en utilisant TCP.
7.10. Le report des auto-incrémentations SOA SERIAL est rendu possible afin que les numéros de série puissent être conservés et que le bouclage à 2**32 puisse être rendu un événement peu fréquent. Les SOA SERIALs visibles (aux clients DNS) doivent différer si la zone diffère. Notez que le SOA de la section Authority dans une réponse QUERY est une forme de visibilité, aux fins de ce prérequis.
7.11. Le SOA SERIAL d'une zone ne devrait jamais être mis à zéro (0) en raison de problèmes d'interopérabilité avec certaines implémentations DNS plus anciennes mais largement installées. Lors de l'incrémentation d'un SOA SERIAL, si le résultat de l'incrémentation est zéro (0) (comme ce sera vrai lors du bouclage autour de 2**32), il est nécessaire de l'incrémenter à nouveau ou de le définir sur un (1). Voir [RFC1982] pour plus de détails sur ce sujet.
7.12. En raison de la minimalisation TTL nécessaire lors de la mise en cache d'un RRset, il est recommandé que tous les TTLs dans un RRset soient définis sur la même valeur. Bien que le format de message DNS permette que des TTLs variants existent dans le même RRset, et que cette variance peut exister à l'intérieur d'une zone, une telle variance aura des résultats contre-intuitifs et son utilisation est découragée.
7.13. La gestion des coupures de zone présente quelques cas limites obscurs aux opérations d'ajout et de suppression dans la section Update. Il est possible de supprimer un RR NS tant qu'il n'est pas le dernier RR NS à la racine d'une zone. Si tous les RRs d'un nom sont supprimés, les RRs SOA et NS à la racine d'une zone ne sont pas affectés. Si des RRsets sont supprimés, il n'est pas possible de supprimer les RRsets SOA ou NS au sommet d'une zone. Une tentative d'ajout d'un SOA sera traitée comme une opération de remplacement si un SOA existe déjà, ou comme une opération sans effet si le SOA serait nouveau.
7.14. Aucune vérification sémantique n'est requise dans le serveur maître principal lors de l'ajout de nouveaux RRs. Par conséquent, un demandeur peut faire en sorte qu'un CNAME ou NS ou tout autre type de RR soit ajouté même si leur nom cible n'existe pas ou n'a pas les RRsets appropriés pour rendre le RR d'origine utile. Les serveurs maîtres principaux qui implémentent ce type de vérification devraient prendre grand soin d'éviter les dépendances hors zone (dont la véracité ne peut être vérifiée de manière autoritaire) et devraient implémenter toutes ces vérifications pendant la phase de préanalyse.
7.15. Les CNAMEs non-terminaux ou joker ne sont pas bien spécifiés par [RFC1035] et leur utilisation conduira probablement à des résultats imprévisibles. Leur utilisation est découragée.
7.16. Les non-terminaux vides (nœuds avec des enfants mais sans RRs propres) provoqueront l'envoi de réponses <NOERROR,ANCOUNT=0> en réponse à une requête de tout type pour ce nom. Il n'y a aucune disposition pour les nœuds terminaux vides - donc si tous les RRs d'un nœud terminal sont supprimés, le nom n'est plus utilisé, et les requêtes de tout type pour ce nom entraîneront une réponse NXDOMAIN.
7.17. Dans un graphe de dépendance AXFR profond, il n'a historiquement pas été une erreur pour les esclaves de dépendre mutuellement les uns des autres. Cette configuration a été utilisée pour permettre à une zone de circuler du maître principal à tous les esclaves même si tous les esclaves n'ont pas une connectivité continue au maître principal. L'utilisation par UPDATE du graphe de dépendance AXFR pour le transfert interdit ce type de boucle de dépendance, car le transfert UPDATE n'a pas de détection de boucle analogue au prétest SOA SERIAL utilisé par AXFR.
7.18. Les noms précédemment existants qui sont masqués par une nouvelle coupure de zone sont toujours considérés comme faisant partie de la zone parent, aux fins des transferts de zone, même si les requêtes pour ces noms seront référées aux serveurs de la nouvelle sous-zone. Si une coupure de zone est supprimée, tous les noms de zone parent qui étaient masqués par elle redeviennent visibles aux requêtes. (Ceci est une clarification de [RFC1034].)
7.19. Si un serveur est autoritaire pour une zone et son enfant, alors les requêtes pour les noms à la coupure de zone entre eux seront répondues de manière autoritaire en utilisant uniquement les données de la zone enfant. (Ceci est une clarification de [RFC1034].)
7.20. L'ordonnancement des mises à jour en utilisant le RR SOA est problématique car il n'y a aucun moyen de savoir lequel des RRs NS d'une zone représente le maître principal, et les esclaves de zone peuvent être obsolètes si leurs minuteries SOA.REFRESH n'ont pas expiré depuis la dernière fois que la zone a été modifiée sur le maître principal. Nous recommandons qu'une zone nécessitant des mises à jour ordonnées n'utilise que des serveurs qui implémentent NOTIFY (voir [RFC1996]) et IXFR (voir [RFC1995]), et qu'un client recevant une erreur de prérequis lors de la tentative d'une mise à jour ordonnée réessaye simplement après une période de délai aléatoire pour permettre à la zone de se stabiliser.