Een organisatorisch domein is een grens die wordt gebruikt DMARC verwerking. Het helpt een ontvanger beleid te vinden wanneer een zichtbaar Van-domein geen eigen record heeft, en het helpt geauthenticeerde identiteiten op een ontspannen manier te vergelijken. uitlijning. Dat zijn verwante operaties, maar het is niet dezelfde vraag.
De sneltoets “neem de laatste twee labels” is onbetrouwbaar. Een naam onder een meerdelig openbaar achtervoegsel, zoals co.uk , laat al zien waarom het tellen van twee labels het achtervoegsel kan selecteren in plaats van de organisatie. De huidige specificatie voegt nog een reden toe om snelkoppelingen te vermijden: RFC 9989 definieert DNS tree walking in plaats van te vertrouwen op a openbare achtervoegsellijst alleen.
Schrijf de drie vragen afzonderlijk op
Begin met het daadwerkelijke domein in het Van-adres van het bericht, het auteurdomein genoemd. Vraag dan:
- Welk DMARC beleidsrecord is van toepassing op dit auteurdomein?
- Welk organisatiedomein wordt door het toepasselijke ontdekkingsproces tot stand gebracht voor elke identiteit die wordt vergeleken?
- Doet het passeren SPF of DKIM identiteit voldoen aan de geselecteerde uitlijningsmodus?
Een geldige record rechtstreeks bij het auteurdomein wint de beleidsselectie. Dat bewijst niet automatisch dat het auteursdomein het organisatorische domein is dat wordt gebruikt voor ontspannen afstemming. Beschouw een DNS checker die slechts één ‘domein’-veld weergeeft als startweergave, en verzamel de daadwerkelijke namen en antwoorden die nodig zijn om de conclusie ervan te verklaren.
De gids voor identiteitsketens helpt bij het identificeren van de Van-, Envelope- en DKIM -domeinen voordat de detectie begint.
Volg een gelabeld voorbeeld
Het volgende is een synthetische DNS momentopname. Het illustreert een fictief register onder de gereserveerde .example-naamruimte; het is geen live zoekresultaat of een bewering over een echt openbaar achtervoegsel.
Stel dat het bestaande auteurdomein invoice.harbour.registry.example is. Zijn boodschap heeft een voorbijgaand karakter DKIM -handtekening met d=sign.harbour.registry.example. SPF gaat door voor een afzonderlijk servicedomein dat niet op één lijn ligt.
| Zoekdoel | Illustratieve reactie | Gevolg |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | Geen DMARC -beleidsrecord | Ga door met ontdekken |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Stel deze expliciete organisatorische grens vast en stop de wandeling |
| _dmarc.registry.example | Niet ondervraagd na de stop | Voor deze wandeling is geen verdere reactie nodig |
Het geselecteerde beleid is de record op harbour.registry.example . Omdat invoice.harbour.registry.example bestaat en een subdomein is, is het toepasselijke beoordelingsbeleid quarantaine via sp. Het organisatiedomein is harbour.registry.example omdat het record expliciet psd=n.
Voor de DKIM identiteit retourneert de illustratieve zoekopdracht op _dmarc.sign.harbour.registry.example geen record, gevolgd door hetzelfde psd=n grensrecord. De geverifieerde ondertekeningsidentiteit en het auteurdomein delen daarom een organisatorisch domein. Bij ontspannen DKIM uitlijning levert de passerende DKIM handtekening een uitgelijnd pad op. Een strikte afstemming zou exacte identiteitsgelijkheid vereisen, wat deze twee verschillende namen niet hebben.
In het voorbeeld worden beleidsselectie, grensdetectie, authenticatie en afstemming bewust als afzonderlijke resultaten zichtbaar gehouden. Als u de beleidswaarde wijzigt, worden de ongelijke domeintekenreeksen niet omgezet in een exacte overeenkomst.
Begrijp wat de wandeling tegenhoudt
RFC 9989 Sectie 4.10 specificeert de query's, recordfiltering en limieten. Een geldig record met psd=n identificeert een organisatiegrens. Een geldig record met psd=y identificeert een openbare achtervoegselgrens, waarbij de selectieregels voor het organisatiedomein rekening houden met het domein, indien van toepassing, één label eronder.
Als geen van beide signalen de grens oplost, biedt de specificatie selectie- en terugvalregels. Het beperkt ook de detectie van lange namen om te voorkomen dat een aanvaller onbeperkte zoekopdrachten forceert. Een productie-implementatie heeft dat volledige algoritme nodig, inclusief ongeldige of meerdere records en DNS fouten; het verwijderen van labels totdat een bekende naam verschijnt, is geen vervanging.
Kopieer psd=y niet naar het dossier van een gewone organisatie. Het beschrijft een achtervoegselrol. psd=n kan opzettelijke organisatorische grenzen ondersteunen, inclusief gedelegeerde subbomen, maar zou een gedocumenteerde naamruimtebeslissing moeten volgen in plaats van een universele checklist.
Onderzoek de verschillen tussen tools en ontvangers
Een oudere implementatie kan de openbare achtervoegselbenadering gebruiken die hoort bij RFC 7489. Een nieuwere implementatie volgt mogelijk op RFC 9989 boomwandeling. DNS reacties, caches en implementatieondersteuning kunnen daarom van belang zijn als de resultaten niet overeenkomen.
Voor een nuttige vergelijking bewaart u de volledige identiteitsnamen, query-antwoorden met tijdstempels, ontdekte beleidsrecord, uitlijningsinstellingen en ontvangerresultaat. Vraag de leverancier van de tool welk detectiemodel hij implementeert. Leid geen universele adoptie af op basis van een publicatiedatum en wijzig DNS niet uitsluitend om ervoor te zorgen dat twee dashboardlabels het eens worden.
Scheid een echt meningsverschil over de grenzen van een ruw authenticatieprobleem. Een ontbrekende DKIM handtekening, mislukte handtekening of niet-goedgekeurde verzendroute wordt niet geldig omdat de organisatiedomeinberekening wordt gecorrigeerd.
Maak van de grens een operationeel record
Voor domeinen met meerdere bedrijfseenheden of gedelegeerde DNS teams kunt u vastleggen wie onder elke grens mag publiceren en welke services daar e-mail mogen verifiëren. Bezoek dat record opnieuw wanneer een applicatie een subdomein krijgt, een bedrijfseenheid DNS -beheer wijzigt of een leverancier met pensioen gaat.
Gebruik verificatie van subdomeinbeleid om te controleren welk beleid van toepassing is, en de uitlijningsvergelijking bij het beslissen welke domeinrelaties acceptabel zijn.
Het bruikbare resultaat is een reproduceerbare keten: dit waren de berichtidentiteiten, deze DNS antwoorden stelden de relevante grenzen vast, dit beleid werd toegepast en deze passerende identiteit kwam wel of niet overeen. Een geraden domeinlabel kan dat bewijs niet leveren.
Gebruik een grensbeslissingskaart
Gebruik deze kaart voor de selectie van organisatiedomeinen, niet als vervanging voor beleidsdetectie. Controleer eerst het auteurdomein op zijn eigen beleid. Een direct beleid kan zelfs van toepassing zijn als uitlijning een andere grensberekening vereist.
| Observatie tijdens de aangegeven wandeling | Grensbeslissing |
|---|---|
| Een geldig record bevat psd=n | Stop; het domein van die record is het organisatiedomein. |
| Een geldig record bevat psd=y verwijderd van het startdomein | Stop; kies het domein één label onder dat openbare achtervoegsel. |
| psd=y is at the starting domain | De vrije loop stopt, maar de regel ‘één label hieronder’ is niet van toepassing op dat startrecord. Pas de selectieregels toe, in plaats van een onderliggend domein te bedenken. |
| Er bestaan geldige records zonder een beslissend grenssignaal | Selecteer het geldige record bij de naam met de minste labels. Selecteer niet automatisch het eerste voorouderrecord. |
| Er is geen organisatiedomein bepaald | Gebruik het oorspronkelijke doeldomein als organisatiedomein. Deze fallback creëert geen beleidsrecord. |
| De onderwerpnaam heeft veel labels | Pas de grens van acht query's toe: behoud de initiële query en verkort deze vervolgens zoals opgegeven. Ondervraag niet elke voorouder van een willekeurig lange naam. |
Deze rijen zijn samengevat RFC 9989 paragrafen 4.10–4.10.2; recordfiltering en DNS-foutafhandeling zijn nog steeds van toepassing. Er is geen beleid gevonden tijdens het ontdekken van beleid, wat betekent dat DMARC niet van toepassing is, ook al heeft het uitlijningsalgoritme een terugval op de grenzen.
Als tweede fictieve tracering, stel dat de wandeling voor a.mail.example.com geldige records vindt op mail.example.com en example.com , noch met psd=n of psd=y, en nergens anders. Het geselecteerde organisatiedomein is example.com . Als mail.example.com in plaats daarvan psd=n, stopt de wandeling daar en wint die specifiekere grens. Bewaar de DNS snapshot met het resultaat, zodat een andere operator de vergelijking kan reproduceren.