Wat een wildcard opzettelijk verbreedt
Een rapportconsument is mogelijk bereid dit te ontvangen DMARC rapporteert voor elk domein in plaats van één autorisatie-eigenaar voor elke relatie te publiceren. RFC 9990 staat expliciet een wildcard DNS record voor dat doel toe. Het voorbeeld plaatst a TXT record bij *. _report._dmarc.example.com met minimaal v=DMARC1. Dit is een brede opt-in door het ontvangende domein, en niet een mechanisme dat bewijst dat elke rapporterende klant is doorgelicht.
Het onderscheid is operationeel van belang. Een aanbieder kan op legitieme wijze kiezen voor een brede instroom, terwijl hij afzonderlijk verificatie op accountniveau vereist voordat gegevens aan een klant worden getoond. De DNS record implementeert deze accountcontroles niet. Een beveiligingsbeoordeling moet precies identificeren welke grens de wildcard verandert en welke grenzen de verantwoordelijkheid blijven van de ontvangende applicatie en de eigenaren ervan. RFC 9990 , sectie 4
Houd exacte zoekopdrachten zichtbaar onder het jokerteken
De reporter construeert nog steeds de autorisatiezoekopdracht vanuit het domein waar het beleid is opgehaald, het _report. _dmarc labels en de bestemmingshost. Een wildcard is een DNS publicatiestrategie die deze vragen kan beantwoorden; het neemt niet de noodzaak weg om de ondervraagde eigenaar of de geretourneerde waarde te begrijpen. Behoud de exacte eigenaar en reactie bij het verifiëren van een bepaalde relatie.
Het bevestigende antwoord moet voldoen aan de parseerregels voor externe verificatie, inclusief de verplichte eerste v=DMARC1. De versiewaarde blijft DMARC1 met het vereiste hoofdlettergebruik. De intentie van een beheerder om een jokerteken te gebruiken is geen bewijs dat een bepaalde query wordt opgelost zoals verwacht in de geïmplementeerde DNS structuur. Exacte naamrecords en DNS structuur kunnen de echte resolutie beïnvloeden, dus voorgestelde tests moeten het daadwerkelijke antwoord behouden in plaats van aan te nemen dat een screenshot de dekking bewijst. RFC 9990 , sectie 4; RFC 9989 , sectie 4.7
Scheid de toestemming voor inname van eigendom en toegang tot gegevens
Een wildcard geeft aan dat het ontvangende domein bereid is de rapporten te ontvangen die onder de protocolregeling vallen. Er wordt niet vastgesteld dat een persoon die zich aanmeldt bij een dashboard het domein beheert dat in een rapport wordt genoemd. Er wordt ook niet aangetoond dat de afzender van een geüpload artefact betrouwbaar is of dat een rapport hoort bij de account die het heeft ontvangen.
Definieer de acceptatievereisten op applicatieniveau afzonderlijk: binding tussen domein en tenant, geverifieerde toegang, tracering van herkomst, afhandeling van duplicaten en beoordeling van onverwachte domeinen. Dit zijn voorgestelde controles, geen claims over een geïmplementeerd EmailAuth platform. Een rapport waarin een organisatie wordt vermeld, mag niet automatisch een eigendomsrelatie creëren of gegevens vrijgeven aan het eerste account dat de naam claimt.
Houd facturering, onboarding en gegevensautorisatie buiten de DNS gevolgtrekking. Een brede bereidheid om verkeer te ontvangen houdt geen toestemming in om een organisatie in te schrijven voor een betaalde dienst of om de waargenomen configuratie ervan te publiceren. Als een workflow deze acties nodig heeft, zijn expliciete beslissingen en bewijsmateriaal nodig dat verder gaat dan het jokertekenrecord. Bij de beoordeling moet voor elke grens de verantwoordelijke eigenaar worden vermeld, in plaats van een enkel DNS resultaat als alomvattende goedkeuring te behandelen.
Houd rekening met misbruik en druk op middelen
RFC 9990 waarschuwt dat rapportinhoud de decompressor of XML-parser kan aanvallen en dat rapportgegevens kunnen worden vervalst. Een brede intakedienst moet er dan ook vanuit gaan dat het ontvangen van meldingen niet ieder binnenkomend dossier veilig of accuraat maakt. Capaciteitsplanning, parserlimieten en herkomstcontroles horen bij het autorisatieontwerp.
Stel begrensde berichtgroottes, gedecomprimeerde groottelimieten, parseertijdbudgetten, wachtrij-isolatie en waarschuwingen voor onverwacht bronvolume voor. De numerieke waarden moeten worden geselecteerd en getest voor de feitelijke omgeving in plaats van gekopieerd van een verzonnen universele limiet. Houd de redenen voor afwijzing in stand en voorkom dat één luidruchtige bron niet-gerelateerd klantbewijs verdoezelt. Er wordt beweerd dat geen van deze controles hier wordt ingezet of getest. RFC 9990 , sectie 8.1 en 8.2
Intrekking en cache-autorisatie
Een rapportconsument die overweldigd wordt door volume kan de bevestigende DNS record verwijderen, maar RFC 9990 merkt op dat positieve caching het effect kan vertragen zolang de TTL van de record bedraagt. Beloof geen onmiddellijke stopzetting van rapporten na een DNS wijziging. Intakesystemen moeten mogelijk ook rapporten verwerken die al zijn gegenereerd of in de wachtrij staan, onafhankelijk van de nieuwe opzoekstatus.
Een opnameplan moet de recordeigenaar, het goedkeuringstraject, relevant TTL-bewijs, het intakegedrag tijdens de transitie en de communicatieverantwoordelijkheden identificeren. Het verwijderen van een jokerteken kan van invloed zijn op veel legitieme relaties tegelijk. Een voorgestelde stap naar expliciete autorisatie per domein vereist niet alleen een inventarisatie van die relaties en een verificatieplan een record verwijdering.
Houd het onderscheid aan tussen DNS intrekking en het intrekken van applicatietoegang. Als u de ontvangende toestemming verwijdert, worden opgeslagen rapporten niet zelf verwijderd, worden klantaccounts gesloten of worden bestaande gebruikerssessies ingetrokken. Dit zijn afzonderlijke controles met afzonderlijke implicaties voor autorisatie en bewaring. RFC 9990 , sectie 4
Fictieve grensbeoordeling en testontwerp
Overweeg een fictieve consument op reports.example.net die *. _report._dmarc.reports.example.net met de waarde v=DMARC1; . Voor een hypothetisch beleid op blue.example.com zou de exacte zoekopdracht blue.example.com._report._dmarc.reports.example.net zijn. Voor dit voorbeeld is geen query, publicatie of DNS fix uitgevoerd.
Het plan met positieve gevallen behoudt de exacte vraag en bevestigt dat de geretourneerde autorisatiewaarde de parsering doorstaat. Het negatieve scenario moet zorgvuldig worden gekozen: een ander brondomein dat naar dezelfde breed geautoriseerde bestemming is gericht, is niet noodzakelijkerwijs ongeautoriseerd, omdat het jokerteken opzettelijk brondomeinen in het algemeen dekt. In plaats daarvan kan een afzonderlijk bestuurde bestemmingshost zonder toestemming de grens van de externe bestemming illustreren, op voorwaarde dat een daadwerkelijk armatuur is geautoriseerd en geïsoleerd.
Het werkblad moet de eigenaar van het jokerteken, de verwachte dekking, exacte testeigenaren, antwoorden, versieparsering, bestemmingshostgrens en controles op tenanttoegang vermelden. Het moet ook het terugdraaiplan en de beperkingen voor de rapportverwerking vastleggen. De verwachte uitkomsten zijn ontwerphypothesen totdat daadwerkelijke begrensde tests worden uitgevoerd; ze mogen niet als geslaagd worden bestempeld alleen maar omdat de redenering plausibel is.
Onopgelost origineel bewijsmateriaal en vrijgavepoorten
De catalogus vereist de exacte autorisatie-eigenaar en het antwoord, inclusief een positieve test en een test voor een niet-geautoriseerde bestemming. Die oorspronkelijke observaties blijven open. Dit manuscript levert een voorgesteld testontwerp en fictieve namen, geen functionerende wildcard-implementatie of een beoordeling van accounttoegang.
Voordat deze als geverifieerde operationele gids worden gepubliceerd, moet een gekwalificeerde reviewer de daadwerkelijke DNS reacties inspecteren en bevestigen dat de negatieve test daadwerkelijk de beoogde autorisatiegrens overschrijdt. Origineel bewijsmateriaal, menselijke beoordeling, toepasbaarheid van de bron, productieroutes, visuele toegankelijkheid en vrijgave door de eigenaar blijven open. Voor deze werkzaamheden is geen extern contact, rapportupload of DNS wijziging uitgevoerd.