Under RFC 9989 §9.2, en midlertidig DMARC fejl betyder, at evalueringen stødte på et problem, der muligvis løses ved et senere forsøg. Det betyder ikke, at domænet ikke har nogen politik, eller at legitim e-mail definitivt har mislykkedes med godkendelse.
Behandl resultatet som starten på en opløsningsundersøgelse. Bestem, hvilket påkrævet opslag mislykkedes, om dataene findes på dens autoritet, og hvad der forhindrede det modtagende system i at opnå et brugbart svar.
Fang den mislykkede evaluering
Gem det komplette betroede resultat eller returnerede SMTP svar, tid, fra domæne og afsenderrute. Bemærk, hvilken godkendelsesmetode fejlen tilhører. En midlertidig SPF eller DKIM problem er ikke automatisk det samme som dmarc=temperror.
Bevar det nøjagtige opslagsnavn og posttype, når logfiler afslører dem. En politik TXT forespørgsel, en SPF afhængighed og en DKIM vælger opslag kan involvere forskellige navne og autoriteter. Test af kun domæneroden kan gå glip af den mislykkede afhængighed.
Bevar en lille bevispakke, før du foretager ændringer. Gentagne forespørgsler kan lykkes efter hændelsen, så et senere sundt svar kan ikke erstatte den oprindelige fejlregistrering.
Følg en svarbaseret beslutningsvej
Dette er en diagnostisk beslutningstabel, ikke en universel kortlægning fra DNS status til én e-mail-disposition:
- Forespørgselsobservation: Relevant fuldstændigt svar med NOERROR; Hvad det fastslår: Denne forespørgsel returnerede brugbare data på det tidspunkt; Næste undersøgelse: Sammenlign det med modtagerens tidligere observation
- Forespørgselsobservation: Komplet svar uden data; Hvad det fastslår: Det anmodede rekordsæt blev ikke fundet i denne svarkontekst; Næste undersøgelse: Tjek nøjagtigt navn, autoritet, aliaser og opdagelse
- Forespørgselsobservation: NXDOMAIN uden en aliaskomplikation; Hvad det fastslår: Det forespurgte ejernavn eksisterer ikke; Næste undersøgelse: Bekræft forespørgselsomfanget og den relevante reserve
- Forespørgselsobservation: SERVFAIL ; Hvad det fastslår: Opløsning blev ikke fuldført med succes; Næste undersøgelse: Inspicer myndigheds-, delegations-, validerings- og resolverlogs
- Forespørgselsobservation: AFVISET; Hvad det fastslår: En server afviste forespørgslen; Næste undersøgelse: Tjek forespørgselspolitik og serverens tilsigtede rolle
- Forespørgselsobservation: Timeout; Hvad det fastslår: Intet brugbart svar ankom inden for forsøgets grænser; Næste undersøgelse: Tjek tilgængelighed, transport, tab og servertilstand
DNS svarkoder er defineret af RFC 1035 §4.1.1; negative svar af RFC 2308 §2.1 og RFC 2308 §2.2. En forespørgsel til _dmarc.example.com vedrører dette ejernavn. Dets negative svar fastslår ikke i sig selv, at example.com ikke eksisterer. Følg aliaskæder, før du tilskriver et fravær til det oprindelige forespurgte navn.
Sammenlign autoritative og rekursive veje
Identificer først de korrekte autoritative servere, inklusive ethvert delegeret underdomæne. Test det relevante navn hos hver myndighed og sammenlign svarene. Hvis myndighederne er uenige, skal du undersøge zonens tjenestetilstand og de seneste ændringer.
Inspicér derefter den rekursive sti, der bruges af det berørte modtagende system, hvor beviser er tilgængelige. Sammenlign forespørgselstid, status, svar og TTL. En operatørs lokale resolver og en fjernmodtager kan have forskellige cache- eller valideringstilstande.
Følgende fiktive forkortede transskription illustrerer sammenligningen:
14:02 UTC | rekursiv resolver R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | autoritativ server A | samme navn/type | FEJL, politik returneret 14:04 UTC | autoritativ server B | samme navn/type | FEJL, politik returneres 14:09 UTC | resolver R efter undersøgt reparation | samme navn/type | NOERRORDisse observationer indsnævrer undersøgelsen mod den rekursive eller mellemliggende vej. De beviser ikke årsagen uden logfiler, og de fastslår ikke, hvad enhver modtager oplevede.
Inkluder DNSSEC -validering i undersøgelsen
Under RFC 4035 §5.5, kan en validerende resolver afvise data, der fejler DNSSEC validering, selv når en direkte forespørgsel til en autoritativ server returnerer tekst. Tjek delegerings- og valideringsbeviser, herunder nøgle- eller signaturændringer, ved hjælp af det ansvarlige DNS teams understøttede værktøjer og logfiler.
Et direkte svar fra en myndighed gengiver ikke i sig selv modtagerens valideringsbeslutning. Ligeledes beviser en SERVFAIL ikke et DNSSEC problem; det kan have flere årsager.
Reparer den konstaterede valideringsfejl, hvis der er en. Deaktivering af validering for at skjule symptomet er ikke et bevis på, at den tilsigtede sikre løsningssti blev genoprettet.
Test både UDP og TCP, hvor det er relevant
DNS transport kan være en del af fejlen. En lille UDP-forespørgsel, der lykkes, fastslår ikke, at et større svar, et trunkeret-svar-genforsøg eller TCP fungerer ad samme vej.
RFC 7766 RFC 7766 §5 kræver generelle DNS -implementeringer for at understøtte både UDP og TCP. Sammenlign det relevante navn og type over hver transport, når du diagnosticerer tilgængelighed eller størrelsesrelaterede fejl. Undersøg trunkeringsflaget og netværksbeviset i stedet for at antage, at hver timeout har samme årsag.
En transporttest er en diagnostisk observation. Det bør ikke omdannes til en produktionsløsning, der omgår den tilsigtede resolver eller valideringssti uden et gennemgået design.
Hold fravær og mislykket løsning adskilt
Under RFC 2308 §5, negative svar kan cachelagres, ligesom positive data kan. En nyligt tilføjet post kan forblive fraværende i en rekursiv visning, indtil den tidligere negative cachetilstand udløber. Det er forskelligt fra, at en autoritativ server ikke kan nås.
En konfigurationsfejl kan også fortsætte, mens den observerede fejl forbliver klassificeret som midlertidig. "Midlertidig" beskriver evalueringskategorien, ikke et løfte om, at ventetiden vil reparere en ødelagt delegation eller underskrift.
Bruge guiden til manglende registrering for bekræftet fravær og udgivelsens arbejdsgang for at verificere det faktiske navn og autoritet.
Bekræft gendannelsen, før du genovervejer politikken
Strøm RFC 9989 §4.10.1 overlader håndtering af DNS -fejl til politikopslag til modtageren. Evalueringsvejledningen i RFC 9989 §5.3.6 siger, at påkrævede DNS forespørgsler, der ikke er fuldført på grund af DNS fejl, ikke etablerer et DMARC bestået eller mislykket, og domæneejervurderingspolitikken kan ikke anvendes på det ufuldstændige resultat. Modtagerhåndtering kan stadig variere.
Ændring af p reparerer ikke et uopnåeligt påkrævet opslag. Gendan først brugbar opløsning, test derefter den samme rute igen, og inspicér de nye metodespecifikke resultater. Bevar enhver beslutning om forretningsgenopretning som en separat ændring.
Den endelige registrering skal identificere den mislykkede afhængighed, etablerede årsag, reparation og modtagerbevis efter genopretning. Det gør den næste periodiske fiasko lettere at diagnosticere uden at svække en fungerende politik refleksivt.
Hold beslutningen og beviserne adskilt
For det fiktive 14:02-14:09-udskrift indsnævrer autoritetssuccesen, men identificerer ikke den mislykkede komponent. Kræv den faktiske resolver eller netværksfinding, før du navngiver DNSSEC , transport eller en bestemt server som årsagen. RFC 8767 §4 tillader kvalificerende brug af uaktuelle svar; friskhed alene er ikke et universelt udfald eller genopretningsur. Disse observationer er opfundne undervisningsinventar, ikke udførte tests.