Quel joker élargit délibérément
Un consommateur de rapports peut être disposé à recevoir DMARC rapports pour n'importe quel domaine plutôt que de publier un propriétaire d'autorisation pour chaque relation. RFC 9990 autorise explicitement un enregistrement DNS générique à cette fin. Son exemple place un Enregistrement TXT à *. _report._dmarc.example.com avec au moins v=DMARC1. Il s'agit d'un large opt-in de la part du domaine destinataire, et non d'un mécanisme prouvant que chaque client déclarant a été examiné.
La distinction est opérationnellement importante. Un fournisseur peut légitimement choisir un large éventail de données tout en exigeant séparément une vérification au niveau du compte avant de montrer les données à un client. L'enregistrement DNS n'implémente pas ces contrôles de compte. Un examen de sécurité doit identifier exactement quelle limite le caractère générique change et quelles limites restent sous la responsabilité de l'application réceptrice et de ses propriétaires. RFC 9990 , section 4
Gardez les requêtes exactes visibles sous le caractère générique
Le rapporteur construit toujours la recherche d'autorisation à partir du domaine où la stratégie a été récupérée, le _report. Les étiquettes _dmarc et l'hôte de destination. Un caractère générique est une stratégie de publication DNS qui peut répondre à ces requêtes ; cela ne supprime pas la nécessité de comprendre le propriétaire interrogé ou la valeur renvoyée. Conservez le propriétaire exact et la réponse lors de la vérification d’une relation particulière.
La réponse de confirmation doit satisfaire aux règles d'analyse de vérification externe, y compris le premier obligatoire v=DMARC1. La valeur de version reste DMARC1 avec la casse requise. L'intention d'un administrateur d'utiliser un caractère générique ne constitue pas une preuve qu'une requête particulière est résolue comme prévu dans l'arborescence DNS déployée. Les enregistrements de noms exacts et la structure DNS peuvent affecter la résolution réelle, les tests proposés doivent donc conserver la réponse réelle au lieu de supposer qu'une capture d'écran prouve la couverture. RFC 9990 , section 4; RFC 9989 , section 4.7
Séparer l'autorisation d'admission de la propriété et de l'accès aux données
Un caractère générique indique que le domaine destinataire est disposé à recevoir les rapports couverts par l'accord protocolaire. Il n'établit pas qu'une personne se connectant à un tableau de bord contrôle le domaine nommé dans un rapport. Cela n’établit pas non plus que l’expéditeur d’un artefact téléchargé est digne de confiance ou qu’un rapport appartient au compte qui le reçoit.
Définissez séparément les exigences d'acceptation au niveau de l'application : liaison domaine-locataire, accès authentifié, suivi de la provenance, gestion des doublons et examen des domaines inattendus. Il s’agit de contrôles proposés, et non d’affirmations concernant une plateforme EmailAuth implémentée. Un rapport mentionnant une organisation ne doit pas automatiquement créer une relation de propriété ni exposer des données au premier compte qui revendique le nom.
Gardez la facturation, l’intégration et l’autorisation des données hors de l’inférence DNS . Une large volonté de recevoir du trafic ne signifie pas un consentement à inscrire une organisation à un service payant ou à publier sa configuration observée. Si un flux de travail nécessite ces actions, il nécessite des décisions explicites et des preuves au-delà de l'enregistrement générique. L'examen devrait nommer le propriétaire responsable de chaque limite plutôt que de traiter un seul résultat DNS comme une approbation globale.
Tenir compte des abus et de la pression sur les ressources
RFC 9990 avertit que le contenu du rapport peut attaquer le décompresseur ou l'analyseur XML et que les données du rapport peuvent être falsifiées. Un service d'accueil à grande échelle devrait donc partir du principe que l'autorisation de recevoir des rapports ne garantit pas la sécurité ou l'exactitude de chaque dossier reçu. La planification de la capacité, les limites de l'analyseur et les contrôles de provenance font partie de la conception de l'autorisation.
Proposez des tailles de message limitées, des limites de taille décompressée, des budgets de temps d'analyse, une isolation des files d'attente et des alertes en cas de volume source inattendu. Les valeurs numériques doivent être sélectionnées et testées pour l'environnement réel plutôt que copiées à partir d'une limite universelle inventée. Préservez les raisons de rejet et évitez de permettre à une source bruyante de masquer des preuves client sans rapport. Aucun de ces contrôles n'est censé être déployé ou testé ici. RFC 9990 , sections 8.1 et 8.2
Retrait et autorisation mise en cache
Un consommateur de rapports submergé par le volume peut supprimer l'enregistrement DNS de confirmation, mais RFC 9990 note que la mise en cache positive peut retarder l'effet aussi longtemps que la durée de vie de l'enregistrement. Ne promettez pas la cessation immédiate des rapports après un changement DNS . Les systèmes d'admission peuvent également devoir gérer des rapports déjà générés ou mis en file d'attente indépendamment du nouvel état de recherche.
Un plan de retrait doit identifier le propriétaire de l'enregistrement, le chemin d'approbation, les preuves TTL pertinentes, le comportement d'admission pendant la transition et les responsabilités de communication. La suppression d'un caractère générique peut affecter plusieurs relations légitimes à la fois. Une proposition d'autorisation explicite par domaine nécessite un inventaire de ces relations et un plan de vérification, et pas seulement un enregistrement effacement.
Conservez la distinction entre retrait DNS et révocation d’accès aux applications. La suppression de l'autorisation de réception ne supprime pas en elle-même les rapports stockés, ne ferme pas les comptes clients ni ne révoque les sessions utilisateur existantes. Il s’agit de contrôles distincts avec des implications distinctes en matière d’autorisation et de conservation. RFC 9990 , section 4
Examen des limites fictives et conception des tests
Considérons un consommateur fictif sur reports.example.net qui propose *. _report._dmarc.reports.example.net avec la valeur v=DMARC1; . Pour une politique hypothétique sur blue.example.com , la requête exacte serait blue.example.com._report._dmarc.reports.example.net . Aucune requête, publication ou montage DNS n'a été exécuté pour cet exemple.
Le plan en cas positif conserverait la requête exacte et confirmerait que la valeur d’autorisation renvoyée réussit l’analyse. Le plan du cas négatif doit être choisi avec soin : un autre domaine source dirigé vers la même destination largement autorisée n'est pas nécessairement non autorisé, car le caractère générique couvre intentionnellement les domaines sources en général. Au lieu de cela, un hôte de destination contrôlé séparément sans autorisation peut illustrer la limite de destination externe, à condition que tout appareil réel soit autorisé et isolé.
La feuille de travail doit répertorier le propriétaire du caractère générique, la couverture attendue, les propriétaires exacts des tests, les réponses, l'analyse des versions, les limites de l'hôte de destination et les contrôles d'accès des locataires. Il doit également enregistrer le plan de restauration et les limites de traitement des rapports. Les résultats attendus sont des hypothèses de conception jusqu'à ce que de véritables tests limités soient effectués ; ils ne doivent pas être qualifiés de « ratés » simplement parce que le raisonnement est plausible.
Preuves originales non résolues et portes de libération
Le catalogue nécessite le propriétaire de l'autorisation exacte et la réponse, y compris un test positif et un test à destination non autorisée. Ces observations originales restent ouvertes. Ce manuscrit fournit une conception de test proposée et des noms fictifs, et non un déploiement générique fonctionnel ou une évaluation de l'accès au compte.
Avant la publication en tant que guide opérationnel vérifié, un évaluateur qualifié doit inspecter les réponses DNS réelles et confirmer que le test négatif franchit réellement la limite d'autorisation prévue. Les preuves originales, l'examen humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent ouverts. Aucun contact externe, téléchargement de rapport ou modification DNS n'a été effectué pour ce travail.