Eksistens tilhører domænet, ikke én posttype
np-tagget leverer en DMARC vurderingspolitik for ikke-eksisterende underdomæner under den gældende opdagede politik. Det er kun nyttigt, når eksistensbeslutningen er sund. "Ingen En rekord," "ingen DMARC TXT post” og “Forfatterdomænet eksisterer ikke” er forskellige udsagn. At behandle dem som synonymer kan anvende den forkerte politik på et rigtigt domæne eller skjule en løsningsfejl bag et falsk negativt svar.
RFC 9989 afsnit 4.7 skelner np fra sp. Førstnævnte adresserer ikke-eksisterende underdomæner; sidstnævnte adresserer eksisterende underdomæner. Hverken træder i stedet for at afgøre, hvilken forsikringsjournal der gælder. Forfatterdomænets egen gyldige politik har prioritet, og dets p-tag bruges til dette domæne. Forældrepolitikberegninger kommer senere, når forfatterdomænet ikke har nogen egen gældende politik.
Angiv forælderen, og hold eksemplerne fiktive
Brug north.example som en opfundet organisatorisk domæne med denne politik: v=DMARC1;p=none; sp=quarantine; np=reject; psd=n. Antag, at hvert tilfælde nedenfor bruger en ellers gyldig meddelelse, hvis godkendelse ikke producerer en tilpasset pass. Disse er dokumentarprogrammer med manuelt afledte resultater, ikke DNS observationer, leveringsforsøg eller udsagn om nogen organisations optegnelser.
For live.north.example skal du angive en adressepost og ingen egen DMARC politik. Opdagelsen når forældregrænsen, og eksistensen er etableret. Den ønskede vurdering kommer fra sp=quarantine. Forælderens p=none erstatter ikke den mere specifikke præference for eksisterende underdomæne. Bevar det valgte tag i resultatet, så en anmelder kan se, hvorfor karantæne blev valgt.
For empty.north.example skal du angive en MX record men ingen A-rekord. En A-forespørgsels autoritative NOERROR/ NODATA svar er kompatibel med det eksisterende navn. Uden egen DMARC politik gælder sp=quarantine stadig. Denne sag adskiller bevidst en manglende registreringstype fra et manglende domæne; en brik, der mærker den som ikke-eksisterende, blot fordi den kun bad om A, ville fejle den forventede beslutning.
Fortolk NXDOMAIN ved det rigtige navn
For gone.north.example skal du angive et autoritativt NXDOMAIN svar for selve forfatterdomænet uden en aliaskæde og ingen egen politik. Den valgte overordnede politik bruger np=reject. RFC 9989 Bilag A.4 forklarer, at DMARC eksistensen ikke kræver en bestemt postrelateret posttype. Dens definition følger DNS eksistensen snarere end SMTP 's snævrere begreb om en opløselig destination.
Et NXDOMAIN svar for _dmarc.live.north.example ville afvise det forespurgte underordnede navn, ikke bevise, at live.north.example er fraværende. Retningen af slutningen har betydning. RFC 8020 forklarer, at et benægtet navn heller ikke har nogen efterkommere; der står ikke, at nægtelse af et barn sletter dets forælder. Aliasbehandling kan også gøre det afviste navn forskelligt fra det oprindelige spørgsmål, så behold det faktiske navn, hvis eksistens blev nægtet.
En tom ikke-terminal er et andet nyttigt grænsetilfælde: en node kan eksistere i DNS hierarkiet, fordi den har efterkommere, selv når den ikke har sine egne poster. Undlad at kollapse den strukturelle eksistens i NXDOMAIN . Armaturets designer bør specificere træet, ikke blot en praktisk tekstlabel knyttet til et tomt svar.
Undersøg NODATA og opløsningsfejl separat
NODATA er ikke en uafhængig DNS svarkode. RFC 2308 afsnit 2.2 beskriver en negativ-svar-klassifikation, der kræver responskontekst. En tom svarsektion kan ledsage en henvisning, og aliaser kan påvirke, hvilket navn og hvilken type der rent faktisk blev løst. Gem spørgsmålet, svarkoden, aliaskæden og myndighedsoplysninger, før du drager en eksistenskonklusion.
SERVFAIL , timeout og et ufuldstændigt svar er ikke bevis for ikke-eksistens. RFC 1035 afsnit 4.1.1 skelner serverfejl fra navnefejl. I det fiktive broken.north.example tilfælde efterlader SERVFAIL eksistensen uafklaret; den vælger ikke np af sig selv. RFC 9989 afsnit 4.10.1 overlader DNS-fejlhåndtering til modtagerens skøn, herunder eventuel midlertidig udsættelse. En evaluator skal beholde denne uafklarede tilstand i stedet for at påstå et normalt negativt opslag.
Anvend bevidst forrang og tilbagefald
Giv nu own.north.example en gyldig v=DMARC1; p=none politik ved dets nøjagtige _dmarc navn. Dens egen p-værdi leverer vurderingen; forældrenes np og sp præferencer erstatter det ikke. Dette er en regel for politikopdagelse, ikke en undtagelse opfundet for tilladelige underordnede domæner. Eksisterende underordnet konfiguration kræver stadig en autoriseret ejer og en begrundet sikkerhedsgennemgang.
Hvis np er fraværende i den valgte overordnede post, er dens sektion 4.7 standard sp, når sp eksisterer, ellers p. For eksempelforælderen gør fjernelse af np vurderingen af et ikke-eksisterende underdomæne i karantæne. Fjernelse af både np og sp efterlader ingen. Denne fallback fortjener en separat test, fordi en genvej, der springer direkte fra manglende np til p, ville ignorere den dokumenterede sp-standard.
Testtilstand og modtagerhåndtering forbliver yderligere lag. Hvis den relevante post inkluderer t=y, skal du først udlede den valgte politik og derefter anvende dens testsemantik. En anmodet afvisningsvurdering er heller ikke en forsikring om et endeligt afslag: modtageranalyse og interoperabilitetskravene i RFC 9989 forbliver relevante. Tabellen, der ledsager denne artikel, registrerer politikvalg, ikke observeret indbakkeplacering.
Bevar en bevispakke i stedet for et grønt skilt
Den nøjagtige kommission er: Sammenlign eksisterende, NODATA og NXDOMAIN sager og udled den valgte politik. Den fiktive sammenligning understøtter gennemgang af den forventede logik, men den lukker ikke den oprindelige operationelle bevisport. Der blev ikke indsamlet live-forespørgsler, kontrollerede autoriteter eller modtagerresultater. Nuværende fejlgennemgang er også uløst, efter at utilgængelige endepunkter blev stoppet.
En godkendt opfølgning bør beholde det nøjagtige forfatterdomæne, gældende politikregistrering, eksistensbeviser, reservevej, modtagerversion og deraf følgende vurdering. Hold DNS-teknisk gennemgang adskilt fra ejerskab af mailpolitik. Produktionsanvendelighed, specialistgennemgang, visuel accept og udgivelsestilladelse forbliver afventende. En pålidelig np-forklaring gør usikkerheden synlig, præcis hvor et skødesløst værktøj kan skjule det.