Une réponse pour un enregistrement manquant peut survivre à l'enregistrement manquant
Un nouveau Sélecteur DKIM peut exister dans DNS faisant autorité alors qu'un résolveur récursif répond toujours comme si la clé était absente. Une explication possible est la mise en cache négative : le résolveur a déjà appris que le nom ou le type d'enregistrement demandé n'était pas disponible et a conservé cette réponse. Enregistrer à plusieurs reprises le même Enregistrement TXT n'informera pas chaque cache que la situation a changé.
Commencez par prouver que l’enregistrement prévu est désormais présent auprès de la bonne autorité. Vérifiez le nom complet du propriétaire, le type demandé et toute cible d'alias. La mise en cache négative est une hypothèse à tester une fois la publication confirmée, et non une explication pratique pour un enregistrement qui a été créé dans la mauvaise zone ou qui n’a pas été desservi par toutes les autorités compétentes.
Identifiez ce que la réponse précédente a nié
NXDOMAIN indique qu'un nom n'existe pas. NODATA décrit une réponse sans aucun enregistrement pertinent du type demandé, plutôt qu'un code de réponse DNS dédié. Son code d'en-tête habituel est NOERROR. Inspectez la section d'autorité et le traitement des alias pour distinguer ce résultat d'une référence ou d'une recherche inachevée. Une section de réponse vide à elle seule ne suffit pas. RFC 2308 , sections 2.1 à 2.2.
La portée compte. Sous le modèle de cache de RFC 2308 , une entrée d'erreur de nom est associée au nom et à la classe ; une entrée sans données inclut également le type demandé. Si un alias précède la réponse négative, déterminez quel nom final manque. Un alias de sélecteur côté client peut exister même si sa cible côté fournisseur n'existe pas. Cela nécessite l'enquête d'un propriétaire différent de celui d'un enregistrement client manquant.
Conservez le résultat précédent s’il est disponible. Une réponse positive actuelle ne peut pas reconstruire la section TTL et autorité d'une réponse négative obtenue hier. Lorsqu'il n'existe aucune capture antérieure, disons que la mise en cache négative est cohérente avec les observations mais non prouvée.
Calculez la durée de vie à partir des bons champs SOA
Pour une réponse négative faisant autorité, RFC 2308 définit le Enregistrement SOAdans cette réponse au plus petit du TTL de l'enregistrement SOA et de son champ MINIMUM. La durée de vie négative mise en cache est ensuite décomptée. La lecture de SOA.MINIMUM seul en tant que minuteur universel de cache négatif est incomplète. RFC 2308 , articles 3 à 5.
Dans un exemple fictif, la durée de vie SOA de la zone est de 900 secondes et la durée MINIMUM est de 3 600. Une réponse négative générée à l’aide de ces valeurs a une durée de vie négative initiale de 900 secondes, et non de 3 600. Si un résolveur l'a obtenu à 12h00 et que le nouveau sélecteur a été publié à 12h03, l'entrée négative précédente pourrait toujours affecter ce résolveur pendant la fenêtre de cache ordinaire restante. Ces temps inventés illustrent le calcul et non un incident observé.
À 12h05, une réponse récursive échantillonnée peut afficher une durée de vie SOA réduite. Conservez ce qu'il rapporte réellement au lieu de remplacer cette valeur par les champs configurés d'une nouvelle requête SOA. D'autres caches peuvent avoir obtenu des réponses différentes à des moments différents, et la politique du résolveur peut limiter la mise en cache. Un seul calcul n’établit pas une reprise universelle à 12h15.
Ne confondez pas la mise en cache des absences et la mise en cache des échecs
SERVFAIL et un timeout n'affirment pas que l'enregistrement est absent. Ils décrivent l’incapacité à obtenir un résultat utilisable. RFC 9520 met à jour les anciennes règles de mise en cache négative en exigeant une mise en cache en cas d'échec de résolution, notamment DNSSEC échecs de validation ; sa durée de cache d'échec est d'au moins une seconde et d'au plus cinq minutes. Ceci est distinct du calcul NXDOMAIN / NODATA dérivé de la SOA. RFC 9520 , sections 3.2 à 3.4.
Des actualisations échouées et répétées peuvent conduire à d'autres entrées de cache d'échec, de sorte que la limite supérieure ne constitue pas une garantie de récupération en cas de panne. Si une recherche renvoie SERVFAIL après une réparation, conservez la réponse et étudiez les diagnostics du résolveur et la disponibilité en amont. Ne remplacez pas une stratégie d'authentification simplement parce qu'un échec de résolution a été décrit de manière informelle comme un enregistrement manquant.
Lors d'échecs d'actualisation des autorités, un comportement de service obsolète peut également compliquer la chronologie, y compris des données négatives obsolètes. Enregistrez si le résolveur concerné est configuré pour fournir des réponses obsolètes lorsque ces informations sont disponibles. Ne déduisez pas la configuration à partir d’une seule ligne de sortie. RFC 8767 , sections 4 et 10.
Publier de nouveaux noms avant qu'ils ne deviennent des dépendances
Pour une rotation planifiée des sélecteurs, préparez le nouveau dossier public avant de changer de service de signature pour l'utiliser. Vérifiez le propriétaire exact et toute cible auprès des opérateurs responsables. Évitez de sonder à plusieurs reprises un nom de production non créé comme si le succès était attendu ; de telles requêtes peuvent établir des entrées de cache négatives avant la publication.
Si une requête de contrôle en amont est nécessaire, conservez son heure et sa réponse. Incluez des considérations relatives au cache négatif dans le plan de lancement plutôt que de masquer un échec de contrôle en amont gênant. Un TTL inférieur sur le futur enregistrement TXT ne raccourcit pas rétroactivement une réponse d'absence déjà mise en cache ailleurs. De même, vider l'ordinateur portable d'un administrateur ne purge pas le résolveur d'un fournisseur de messagerie.
Créer un enregistrement de récupération limité
La feuille de calcul proposée comporte une ligne pour chaque point de terminaison et observation : heure UTC, question exacte, code de réponse, réponse ou alias pertinent, propriétaire SOA et TTL renvoyé, et rôle d'autorité ou de récursion. Comparez les résultats faisant autorité actuels avec le chemin récursif concerné et un résolveur de comparaison identifié séparément. Conservez les réponses complètes et répétez à un intervalle raisonnable et documenté.
Si l'autorité ne dispose pas du dossier, corrigez la publication. Si l'autorité est correcte et qu'une entrée négative capturée explique le résultat récursif, suivez ce chemin de cache spécifique. Si SERVFAIL , des références ou des autorités incohérentes apparaissent, enquêtez plutôt sur ces succursales. Enfin, vérifiez un message contrôlé à l'aide du nouveau sélecteur. Cet article contient uniquement des calculs arithmétiques fictifs et une proposition de flux de travail. Les comparaisons originales des résolveurs et les résultats des messages reçus restent en suspens, de sorte que la porte des preuves opérationnelles du catalogue est toujours ouverte.