Når en DKIM nøglen vises i et DNS kontrolpanel, men verifikationen mislykkes, inspicér det svar, som verifikatoren faktisk henter. Skærmbilleder kan skjule en afkortet værdi, et duplikeret domæne-suffiks eller flere uafhængige poster. Opgaven er at etablere det nøjagtige ejernavn og nøglebytes, før underskriveren ændres.
Start fra den modtagne signatur
Læse d= og s= fra de ramte DKIM-Signature. Opslagsnavnet kombinerer dem som vælger. _domainkey.signing-domain. Et syntetisk budskab med d=example.com og s=notify bruger derfor notify._domainkey.example.com. En nøgle udgivet kl notifications._domainkey.example.com vil ikke reparere det.
Registrer signaturens algoritme og modtagerens nøjagtige årsag. Manglende nøgle, forkert udformet nøgle, uegnet algoritme, signaturmismatch og body-hash mismatch er ikke udskiftelige diagnoser. Hvis der findes flere signaturer, skal du holde deres vælgere og resultater adskilt.
Rekonstruer én TXT post korrekt
DNS TXT registreringer kan indeholde flere tegnstrenge. RFC 6376 §3.6.2.2 kræver, at disse strenge i en enkelt post sammenkædes uden tilføjet mellemrum før brug. At opdele en lang tangent på tværs af strenge i én post adskiller sig fra at oprette flere TXT poster, der hver indeholder et stykke. Sidstnævnte er ikke en sikker måde at publicere én DKIM nøgle på. Afsnit 3.6.2.2 kræver en unik TXT post for vælger og efterlader resultater med flere poster udefinerede; verifikatorvalgene i afsnit 6.1.2 gør ikke fragmenter komponerbare.
Citerede bidder vist af et DNS værktøj er en præsentation af posten. Antag ikke, at anførselstegn er bogstavelige nøglebytes, og fjern ikke tegn vilkårligt fra DNS grænsefladen. Følg dets understøttede indgangsformat, forespørg på autoritativ DNS og sammenlign den rekonstruerede værdi med den genererede offentlige værdi. RFC 1035 §3.3.14 definerer TXT -tegnstrengrepræsentationen.
Undersøg for trunkering ved grænsefladegrænser, indsatte linjeetiketter, manglende separatorer og utilsigtede redigeringer af base64-værdien. Lange optegnelser kræver nøjagtig sammenligning, ikke visuel inspektion af de første og sidste par tegn. Bevar den oprindelige genererede offentlige værdi for den sammenligning; erstatte aldrig en privat-nøgle fil.
Valider tags og nøglemateriale sammen
Under RFC 6376 §3.6.1, den p= tag bærer de offentlige nøgledata. En tom værdi betyder tilbagekaldt, ikke en delvist gennemført opsætning. De k= tag identificerer nøgletypen med RSA som standard i RFC 6376 ; Ed25519 bruger udvidelsen defineret af RFC 8463 §4.2. RFC 6376 afsnit 3.6.1 markerer formelt nøgleposten v= tag ANBEFALET, med DKIM1 som standard, når det er fraværende. Hvis inkluderet, skal det være det første tag, og dets værdi skal være nøjagtigt DKIM1 ; denne værdi skelner mellem store og små bogstaver.
Brug en vedligeholdt DKIM-bevidst validator til at parse hele posten og bekræfte, at afkodet offentligt materiale er passende til den angivne nøgletype. Gyldig base64 alene beviser ikke, at indholdet er en passende RSA eller Ed25519 offentlig nøgle. Ligeledes kan en syntaktisk gyldig post indeholde den forkerte offentlige nøgle til den aktive private underskriver.
Isoler udgivelseslaget fra signeringslaget
En illustrativ fejl involverer en 2048-bit Offentlig RSA-nøgle kopieret til to separate TXT poster. Reparer repræsentationen til DNS udbyderens understøttede multi-streng single-record formular, og læs derefter svaret tilbage. Forkort ikke nøglen for at dæmpe grænsefladefejlen uden at gennemgå årsagen og sikkerhedskonsekvenserne.
Hvis den korrekte offentlige nøgle løses intakt, men en meddelelse stadig mislykkes, skal du undersøge den aktive vælgertilknytning, matchende nøglepar, algoritme og ændringer med signeret meddelelse. Bliv ikke ved med at genudgive identiske DNS data, mens beviserne peger et andet sted hen. En udbyderstyret CNAME bør spores til dens endelige nøgleregistrering; det bør ikke erstattes med en lokal kopi som en generisk syntaksløsning.
Bevis reparationen på en ny besked
Registrer autoritative og rekursive resultater, der tager højde for cachelagrede gamle eller negative svar. Send den berørte ansøgning igennem, og inspicér den betroede modtagers resultat. Behold det korrigerede ejernavn, den rekonstruerede offentlige værdi eller dens sammenfatning, sammenligning af genererede værdier og testbeviser. En reparation er færdig, når den hentede nøgle og den faktiske underskriver er enige, ikke kun når DNS editoren accepterer formularen.
Tjek struktur uden en rigtig nøgle
Illustrativ præsentation på én plade: " v=DKIM1; k=rsa; p=AB" "CD". Sammenkædning frembringer v=DKIM1; k=rsa; p=ABCD, uden indsat mellemrum mellem AB og CD. ABCD er bevidst ikke en gyldig brugbar offentlig RSA-nøgle; dette eksempel viser kun TXT struktur og må ikke offentliggøres. To separate poster, der ender på p=AB og indeholder CD, er ikke ækvivalente. Efter at have rekonstrueret den reelt genererede værdi, skal en DKIM-bevidst parser stadig validere sine tags og afkodede nøglemateriale.
Relateret læsning
DKIM TXT og CNAME publicering: Følg udbyderens nøglestyringsmodel · DKIM nøglelængde og algoritmer: Tjek den aktuelle modtagerunderstøttelse.