Définir le déploiement en tant que propriété DNS observable
Une étude de déploiement DNS peut établir qu'un enregistrement particulier a été observé à un nom et à une heure de propriétaire particuliers. Il ne peut pas, à lui seul, établir que chaque message de l'organisation est authentifié, que les destinataires ont appliqué la même politique ou qu'une demande commerciale était légitime. L'étude doit définir sa propriété mesurée avant de collecter des données : la présence d'enregistrements, la validité syntaxique, la découverte de politiques applicables et la conformité des messages opérationnels sont des résultats différents.
RFC 1035 définit les structures des messages et des enregistrements DNS . RFC 9989 définit DMARC découverte et alignement comportement. Ces normes soutiennent une méthode de mesure reproductible et non une affirmation selon laquelle une analyse a été effectuée. Ce manuscrit ne contient aucune observation de domaine, pourcentage d'adoption ou résultat de message déduit.
Choisissez l'unité et la population avant d'interroger
Précisez si l'étude prend en compte les domaines enregistrés, les noms complets, les identités d'envoi ou les organisations clientes. Ces unités ne sont pas interchangeables. Une organisation peut exploiter plusieurs domaines, tandis qu'un domaine peut héberger plusieurs flux de travail d'envoi indépendants. Une liste de noms de sites Web n'est pas automatiquement une liste de domaines qui envoient du courrier. Enregistrez comment l'échantillon a été sélectionné et ce que la sélection exclut.
Gelez la liste d'entrée avec un identifiant de version et un hachage conservé. Définissez la gestion des doublons, des noms internationalisés, des points de fin, des alias et des changements de propriété ou de statut. Ne supprimez pas silencieusement les noms difficiles après avoir vu leurs résultats. Si la population constitue un échantillon de commodité, décrivez-la ainsi plutôt que de la présenter comme représentative de tous les domaines de messagerie. Aucune liste de population n'a été créée ou interrogée pour ce projet.
Distinguer l'observation du nom exact de la découverte
Une recherche TXT exacte répond à une question plus précise que la détermination d’une politique DMARC applicable. Sous RFC 9989, le processus de découverte peut impliquer un Promenade dans l'arborescence DNS. Une méthode qui interroge un seul nom de propriétaire attendu doit étiqueter son résultat avec la présence exacte du nom, et non terminer le déploiement DMARC . Conservez l'algorithme et la version standard utilisés afin qu'un autre analyste puisse comprendre ce que signifie un résultat négatif.
SPF a sa propre identité et ses propres règles de sélection d'enregistrements dans RFC 7208. La recherche d'une politique sur un domaine de site Web ne prouve pas qu'il s'agit du COURRIER DE identité utilisée par les messages de l'organisation. Une étude DNS uniquement peut décrire la publication sous des noms sélectionnés, mais elle ne doit pas inventer des identités d'envoi ni substituer des noms de marque au contexte SMTP observé.
Conserver séparément les preuves faisant autorité et les preuves récursives
Pour chaque observation autorisée, enregistrez le propriétaire exact, le type, la classe, le serveur ou le résolveur, l'heure et l'état de la réponse. Les réponses faisant autorité décrivent la réponse de l'autorité interrogée ; les réponses récursives peuvent refléter les données mises en cache et le propre traitement du résolveur. Si les deux sont collectés, conservez les deux plutôt que de sélectionner la réponse qui correspond au résultat attendu. Leur désaccord peut être analytiquement important.
Documentez comment les serveurs faisant autorité sont découverts et comment la méthode gère les réponses incohérentes entre eux. Enregistrez tous les échecs dans le chemin de découverte plutôt que de les étiqueter comme absence de politique finale. Une durée de vie récursive peut refléter la durée de vie restante du cache, elle ne doit donc pas être signalée comme la durée de vie configurée d'origine sans preuve. L'étude doit conserver les transcriptions brutes ainsi que les champs normalisés pour permettre un examen ultérieur.
Préserver les limites des enregistrements et les catégories d’erreurs
TXT RDATA peut contenir plusieurs chaînes de caractères au sein d'un même enregistrement. Cela diffère de plusieurs enregistrements de ressources TXT chez le même propriétaire. Un analyseur de mesures doit conserver ces limites avant d’appliquer une sélection spécifique au protocole. Des données TXT non liées peuvent coexister avec des enregistrements d'authentification ; elle ne doit pas gonfler le nombre de politiques ni être fusionnée dans une assertion d'apparence valide.
Erreur de nom distinctif, réponse réussie sans données demandées, panne de serveur, délai d'attente, syntaxe invalide et enregistrements pertinents ambigus. Ces catégories ne devraient pas toutes devenir des déploiements manquants. Le tableau des résultats doit conserver la réponse originale et la règle utilisée pour attribuer une catégorie. Si la méthode effectue une nouvelle tentative, prédéfinissez le calendrier des nouvelles tentatives et la classification finale afin que les échecs temporaires ne soient pas traités différemment en fonction du résultat souhaité.
Conserver les preuves DNSSEC dans son propre champ
RFC 4033 distingue les états de validation sécurisés, non sécurisés, faux et indéterminés. Un record peut être présent sans chaîne validée de manière sécurisée. Un échec de validation peut également empêcher un résolveur de renvoyer des données utilisables. Si l'étude mesure DNSSEC, il doit documenter le contexte de l'ancre de confiance et du résolveur plutôt que de supposer que tout enregistrement visible est authentifié.
Ne faites pas du statut DNSSEC une exclusion cachée qui modifie le dénominateur de l'échantillon. Indiquez combien de noms ont été évalués, quels états ont été observés et lesquels n'ont pas pu être déterminés, en utilisant des preuves réelles lors de leur collecte. Ce projet ne contient pas de tels chefs d’accusation. Le but de la méthode est de préserver l’incertitude, et non de transformer des données indisponibles en un résultat de déploiement pratique.
Séparer la publication de la conformité au niveau du message
Une politique SPF publiée n'indique pas quelle adresse IP a soumis un vrai message. UN DKIM La clé ne montre pas qu'un fournisseur a signé un message particulier ou a conservé la clé privée correspondante en toute sécurité. Une politique DMARC ne démontre pas que tous les flux légitimes s'alignent. Ces questions nécessitent des preuves opérationnelles de l’itinéraire réel et un récepteur fiable.
RFC 8601 explique la limite de confiance pour Authentication-Results. Un échantillon de message reçu correspondant peut prendre en charge une observation au niveau du message, mais il ne valide pas automatiquement chaque domaine ou flux de travail dans une étude DNS . Conservez les métriques de publication et les métriques de message en tant que mesures distinctes avec leurs propres populations et limites. Ne réétiquetez pas un pourcentage d’adoption DNS comme étant une conformité ou une protection atteinte.
Une fiche d'observation reproductible
Créez une feuille de calcul avec un exemple de version, une unité de domaine, une entrée normalisée, un propriétaire exact interrogé, un type d'enregistrement, une méthode de requête, une heure d'observation, une transcription faisant autorité, une transcription récursive et une version de l'analyseur. Ajoutez la catégorie de résultat attribuée, le chemin de découverte de la stratégie applicable, le statut DNSSEC lorsqu'il est évalué et une explication des erreurs. Conservez un lien vers les preuves brutes plutôt que uniquement vers la classification finale.
La spécification de l'analyse doit indiquer le numérateur et le dénominateur de chaque mesure. La présence parmi tous les noms tentés, la validité parmi les noms avec réponses et la couverture de la politique applicable sont des fractions différentes. Si plusieurs sont utiles, signalez-les séparément. Définissez les exclusions avant l’analyse et conservez un journal d’exclusion avec les raisons. Aucune entrée originale, transcription de requête ou résultat de mesure n’est fournie dans ce manuscrit.
Diagnostic fictif : une charte de déploiement devient une déclaration de conformité
Un analyste fictif interroge une liste de domaines de sites Web d'entreprise et trouve des données TXT relatives aux politiques sur certains d'entre eux. Une présentation étiquette le résultat de la conformité de l'authentification des e-mails. L'examen proposé identifie deux lacunes : l'échantillon n'établit pas les identités d'envoi réelles et la présence de l'enregistrement n'établit pas l'authentification au niveau du message. Le graphique doit être renommé pour décrire la propriété DNS observée et son échantillon.
Une étude autorisée ultérieure pourrait ajouter des inventaires d’expéditeurs et des preuves de messages reçus, mais elle nécessiterait une nouvelle définition métrique plutôt qu’une mise à niveau silencieuse de la déclaration initiale. Cet exemple ne contient aucun domaine, décompte ou analyse réel. Il illustre une erreur de rapport dans une méthode hypothétique, et non une découverte concernant une organisation ou une étude de déploiement terminée.
Libérer la méthode avec ses limites de preuves
Une conclusion d'étude utile indique la population, les dates d'observation, l'algorithme de requête, les catégories de résultats et ce que les preuves ne peuvent pas établir. Cela évite les réclamations concernant le comportement du récepteur universel, la livraison dans la boîte de réception ou la fraude évitée. Une mesure DNS transparente reste précieuse précisément parce que sa portée est claire.
Le catalogue nécessite des réponses horodatées faisant autorité et récursives avec les noms exacts des propriétaires et les types d'enregistrement. Ces transcriptions originales restent ouvertes. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité et la libération par le propriétaire restent également ouverts. Ce projet est une méthode de mesure proposée, et non une analyse effectuée ou un résultat de conformité de message.