Ingen DMARC post fundet: spor værtsnavnet og DNS autoriteten

Et "nej DMARC rekord fundet"-advarsel er et udgangspunkt for diagnose. Det kan afspejle en virkelig manglende politik, en forespørgsel efter det forkerte navn, en redigering i en inaktiv DNS konto, et ældre cachelagret svar eller en løsningsfejl.

Før du udgiver en anden post, skal du fastslå, hvad værktøjet forespurgte, og hvilke autoritative servere, der kontrollerer dette svar. Bevar DNS svarkoden samt alle returnerede TXT data. Dette adskiller en fraværende registrering fra en rekord der findes, men ikke kan hentes gennem en bestemt opslagssti.

Fang det nøjagtige mislykkede opslag

Optag værktøjet, det forespurgte domæne, tidsstemplet, resolveren og det fulde DNS svar, hvor det er tilgængeligt. Gem den aktuelle politikpost og DNS konfiguration før redigering.

Disse illustrative BIND grave-kommandoer udføres ikke her. Erstat dokumentationsnavne med det godkendte mål og den faktiske delegerede server. De BIND gravemanual definerer server-, navn-, type- og forespørgselsmuligheder. Autoritetssektionen hjælper med at bevare negativ-svar kontekst; kommentarer bevarer overskriftsstatus og flag. En simpel forespørgsel til det synlige From-domæne example.com starter her:

dig _dmarc.example.com . TXT +noall +svar +autoritet +kommentarer

Bevar både svarstatus og svarsektion. En kort skærm kan skjule forskellen mellem et navn uden relevante TXT data og en opløsningsfejl.

Identificer, hvem der kontrollerer det offentlige DNS svar

Dette problem bliver ofte et ejerskabsproblem. En virksomhed kan have købt domænet fra én udbyder, flyttet sin hjemmeside et andet sted hen og uddelegeret DNS til en tredje konto. En post tilføjet i det forkerte panel kan se komplet ud uden at have nogen effekt på offentlige e-mail-tjek.

Bed operatøren om at identificere den aktuelle autoritative DNS vært og vise dens svar for det tilsigtede navn. Undgå at betale for gentagne rettelser uden en demonstreret udgivelsessti. Spørg også, om advarslen vedrører dit hoveddomæne, et afsendende underdomæne eller en anden identitet, der bruges af en applikation.

Tjek navnet og udgivelseskontoen

Tjek den autoritative delegation for zonen, inklusive en separat delegeret underordnet zone, hvis der findes en. Forespørg direkte på en relevant autoritativ server ved at bruge dens faktiske navn:

dig @ ns1.example.net _dmarc.example.com . TXT +norecurse +noall +svar +autoritet +kommentarer

Hvis DNS editoren automatisk tilføjer zonen, indtastes _dmarc.example.com kan ved et uheld offentliggøres _dmarc.example.com.example.com. I en anden editor, kun indtastning _dmarc kan være forkert. Tjek det endelige offentliggjorte ejernavn i stedet for at foreskrive det samme inputformat for hver udbyder.

Andre hyppige fejl omfatter en TXT post ved domæneroden, en redigering af en inaktiv DNS konto, en ikke-gemt ændring eller et opslag efter det forkerte afsendende domæne.

Skelne fravær fra opslagsfejl

• Observation: NXDOMAIN ; Hvad skal undersøges: Det forespurgte navn rapporteres som ikke-eksisterende
• Observation: NOERROR uden relevante TXT data; Hvad skal undersøges: Det forespurgte navn har ikke noget relevant TXT svar i det svar
• Observation: SERVFAIL ; Hvad skal undersøges: Løsning mislykkedes; inspicere myndighed, delegation, validering og afhængigheder
• Observation: Autoritativt svar findes, men det rekursive svar er forskelligt; Hvad skal undersøges: Cachetilstand, resolvervisning, delegeringssti og timing
• Observation: Adskillige politikkandidater; Hvad skal undersøges: Et rekord-set problem, ikke en simpel manglende rekord-tilstand

DNS statusserne og skelnen mellem negative svar er beskrevet i RFC 1035 §4.1.1, RFC 2308 §2.1 og RFC 2308 §2.2. Behandl ikke SERVFAIL som tilladelse til at offentliggøre en anden post. Posten kan eksistere, men være utilgængelig gennem den mislykkede løsningssti. Ligeledes afgør en manglende registrering ved et børnenavn ikke, om en modtager kan opdage en gældende politik andetsteds under RFC 9989 §4.10.1.

Bearbejdet eksempel: posten er i en inaktiv zone

Overvej denne illustrative undersøgelse. En administrator tilføjer _dmarc til registratorens DNS panel. Offentlig delegation peger dog på en separat DNS vært, der blev brugt under en tidligere webstedsmigrering.

Registratorens panel viser den tilsigtede værdi. En direkte forespørgsel til den aktuelt delegerede myndighed returnerer den ikke. At vente længere kan ikke gøre en inaktiv zone autoritativ.

Rettelsen skal offentliggøres gennem den faktiske myndighed med passende godkendelse. Behold bagefter det autoritative svar og sammenlign den rekursive observation. Ændring af navneservere bare for at gøre det tidligere panel effektivt kunne forstyrre ikke-relaterede web- og mailposter, så det er en separat, meget bredere ændring.

Sammenlign autoritative og cachelagrede svar

Under RFC 2308 §5, kan en resolver cache et tidligere negativt svar. En ny autoritativ rekord kan derfor sameksistere midlertidigt med en rekursiv observation med manglende svar. Skylning af en bærbar computers cache rydder ikke en ekstern modtagers resolvertilstand.

Sammenlign autoriteten og relevante rekursive observationer med tidsstempler. Hvis autoritative servere er uenige, skal du undersøge deres offentliggjorte tilstand. Hvis intern og offentlig DNS er forskellige, skal du bestemme, hvilken visning den eksterne mailmodtager bruger.

Undgå at love, at alle svar vil konvergere efter et fast antal minutter. Diagnostiser den faktiske sti og cachebevis.

Ret udgivelsesprocessen

Behandl resultatet som et kontrol-ejerskabsproblem, når det afslører uklart DNS ansvar, forladte konti eller ikke-administreret delegering. Registrer, hvem der kan foretage ændringer, hvilken zone der er aktiv, og hvordan en anden anmelder verificerer resultatet.

En observation af manglende politik er en konfigurationskonstatering. Det fastslår ikke, at a phishing kampagnen lykkedes, at hvert underdomæne mangler en politik, eller at hver modtaget besked mislykkes DMARC. Hold disse konklusioner adskilt og saml de beviser, hver enkelt kræver.

Bekræft politikken og en reel besked

Efter den tilsigtede rettelse skal du bekræfte det gældende politikopslag og teste en ægte legitim meddelelse gennem den relevante tjeneste. Bekræft dets pålidelige godkendelsesresultat og justering.

Bruge arbejdsgangen for oprettelse af journaler når en ny politik faktisk er påkrævet. Hvis politikken er synlig, men e-mailen mislykkes, skal du flytte til alignment diagnose. Hvis en gammel guide og en ny modtager er forskellige ved opdagelse, medtag DMARCbis beredskab i efterforskningen.

Den praktiske takeaway

Luk resultatet med den rettede udgivelsessti og det resulterende autoritative svar. Bekræft derefter den gældende politik og en ægte legitim besked. Dette efterlader en reproducerbar diagnose i stedet for et uforklarligt kontrolresultat.

Hold beslutningen og beviserne adskilt

For den inaktive zone-opstilling skal du vælge den aktive myndighed som det foreslåede udgivelsesmål; skift ikke delegation blot for at gøre et forældet panel relevant. Undersøg flaget for autoritativt svar og den fulde svarkontekst, ikke kun returneret tekst. RFC 8767 §4 tillader kvalificerende brug af uaktuelle svar efter TTL-udløb, så en TTL er ikke en universel konvergensfrist. Ingen opslag eller konfigurationsændring blev udført.