La publication DNS en un clic compresse une interface, pas les conséquences d'un changement DNS . Un flux de travail sûr doit toujours établir ce qui va changer, qui l'a autorisé, si la ligne de base reste actuelle et si le résultat escompté s'est produit. Évaluez ces contrôles indépendamment de l’étiquette marketing de tout produit.
Inspecter la proposition avant de l’approuver
L'aperçu doit afficher la zone, le propriétaire et le type exacts, les valeurs existantes et proposées, la durée de vie, les services concernés et les conditions de restauration. Distinguer la création du remplacement et de la suppression. Affichez l'ensemble d'enregistrements réel plutôt qu'une instruction vague telle que « réparer DMARC.» Si la proposition change après examen, l'approbation préalable ne doit pas autoriser les nouveaux octets.
Pour le plan écrit DNS-01, supposons la zone example.test, propriétaire _dmarc.example .test, tapez TXT , TTL 300, valeur actuelle v=DMARC1; p=none et valeur proposée v=DMARC1; p=quarantine. Il s’agit d’un exemple de précision d’un plan et non d’une recommandation d’application approuvée. L'approbateur nommé, le résumé de référence actuel et le résumé du plan ne sont pas fournis. Aucun jeton d'approbation ou véritable identifiant n'existe dans cet exemple.
Appliquer l’autorité en dehors de la recommandation
Conseils d'agence excessifs de l'OWASP prend en charge la restriction des capacités et des autorisations de l’outil et la validation de l’autorité à la limite d’exécution. Un rédacteur DNS ne devrait pas bénéficier d’un contrôle illimité du bureau d’enregistrement simplement parce qu’il peut recommander une modification TXT . Examinez l’accès persistant séparément de l’approbation d’une modification particulière.
Utilisez les restrictions de portée prises en charge par le fournisseur lorsqu'elles sont disponibles et limitez le service d'exécution aux zones et opérations approuvées. Une explication rassurante en langage naturel n’est pas un contrôle d’accès. Si la plateforme ne peut pas limiter l'accès de manière adéquate, utilisez une intégration plus étroite ou une implémentation manuelle révisée plutôt que de masquer l'autorité étendue.
Détecter les états obsolètes et les résultats incertains
Immédiatement avant l'exécution, relisez la cible et comparez-la avec la référence révisée. Utilisez la mise à jour conditionnelle d'un fournisseur lorsqu'elle est prise en charge. Une lecture séparée suivie d'une écriture inconditionnelle a une fenêtre de course ; un hachage côté client à lui seul ne rend pas la mise à jour du serveur atomique. Pour les systèmes sans mises à jour conditionnelles, coordonnez les modifications exclusives et résolvez les conflits plutôt que de réclamer une garantie.
Appliquer les cas de décision écrits suivants : la correspondance avec la ligne de base et l'approbation valide de la portée pourraient procéder à la vérification de l'exécution prise en charge par le fournisseur ; une ligne de base modifiée signifie arrêter et réconcilier ; une proposition modifiée ou une zone erronée signifie obtenir un nouvel examen ciblé ; l'approbation manquante signifie aucune écriture. Un délai d'attente après la soumission laisse le résultat inconnu, ce qui nécessite des preuves de l'état actuel et du fonctionnement du fournisseur avant d'envisager une nouvelle tentative. Aucun de ces cas n'a été exécuté.
Vérifier et préserver une voie de récupération
Une réponse réussie de l'API n'est pas le critère d'acceptation final. Capturez les observations DNS faisant autorité et récursives efficaces, puis testez les résultats pertinents du courrier légitime et des destinataires de confiance. RFC 9989 décrit le comportement d'authentification et de politique ; il ne garantit pas qu'une valeur publiée permettra d'atteindre le résultat commercial escompté.
Une vérification de l’égalité des enregistrements stockés ne couvrirait que cet état restreint, et non le comportement efficace DNS ou du courrier. Aucune écriture locale ou fournisseur n'a été testée ici. Conservez l'enregistrement d'origine et un plan de récupération révisé, et tenez compte des valeurs mises en cache lors de sa restauration. Enregistrez explicitement l’exécution partielle ou l’échec de la vérification. Cet article décrit des contrôles à évaluer et une démonstration pédagogique ; il n'affirme pas EmailAuth fournit actuellement une publication en un clic ou ces garanties.