A återkallad DKIM nyckel och en saknad nyckelpost kan berätta olika saker för en operatör, men ingen av dem tillhandahåller en användbar verifieringsnyckel. RFC 6376 §3.1 definierar uttryckligen ingen semantisk skillnad mellan att återkalla en nyckel och att ta bort dess post för signaturverifiering. Bevara den distinktionen när du diagnostiserar ett avbrott eller svarar på en kompromiss.
Känn igen de olika observationerna
I en DKIM -nyckelpost, en tom p= värde indikerar återkallelse. Ett syntaktiskt lämpligt illustrativt RSA-återkallande värde är v=DKIM1; k=rsa; p=. Den innehåller ingen privat nyckel och är inte en ersättningsnyckel. Använd den exakta väljare ägarens namn från den berörda signaturen och följ plattformens understödda process.
När nyckelposten inte finns, RFC 6376 §6.1.2 kräver permanent misslyckande med en no-key orsak. Ett tomt värde för den offentliga nyckeln ger permanent fel med en orsak till att nyckeln återkallats. En DNS fråga som inte svarar är ett annat tillstånd och kan orsaka ett tillfälligt fel. Kalla inte alla uppslagningsproblem för återkallande.
Operativ avsikt behöver fortfarande bevis. En tom nyckel kan vara en godkänd nödändring eller ett publiceringsmisstag. En saknad post kan återspegla avsiktlig pensionering, en felaktig väljare eller en oavsiktlig radering. Jämför det auktoritativa DNS tillståndet, det rekursiva svaret, tidsstämpeln och den auktoriserade ändringshistoriken innan du tillskriver orsak.
Välj svar efter händelsen
För rutinmässig pensionering, samordna slutet av signeringen med den period under vilken legitima försenade meddelanden fortfarande kan kräva den gamla offentliga nyckeln. För en misstänkt kompromiss med privat nyckel kan kontinuitet och inneslutning komma i konflikt. Åberopa incidentprocessen, fastställa vem som kan godkänna ändringen och dokumentera varför det valda svaret är proportionerligt.
Återkallelse sker inte omedelbart över cacher. RFC 1034 §3.6 beskriver TTL för cachade poster. En resolver kan behålla tidigare positiva data tills dess cachelivslängd tar slut. Att minska TTL efter incidenten förkortar inte varje cachad kopia i efterhand. Vissa resolvers kan leverera inaktuella data under RFC 8767 §4 när uppdatering inte är tillgänglig, så den gamla TTL är inte en absolut världsomspännande återkallelsesfrist. Påstå inte att en DNS redigering omedelbart förhindrar varje efterföljande verifiering med ett äldre svar.
Att stoppa den komprometterade undertecknaren och begränsa obehörig åtkomst är separata uppgifter. En DNS ändring ensam återställer inte den läckta privata nyckeln eller skyddar kontot som exponerade den. RFC 6376 §8.3 förklarar risken för en komprometterad signeringsnyckel. För leverantörshanterade CNAME:er, identifiera vem som kontrollerar den slutliga nyckeldatan och vilken stödd åtgärd som tar tillbaka den berörda väljaren. Lägg inte till en konflikt TXT post vid sidan av aliaset som en improviserad fix; se RFC 1034 §3.6.2.
Arbeta med ett evidensstyrt exempel
I en syntetisk incident används meddelanden d=example.com; s=oldbilling. Det auktoritativa svaret innehåller nu ett tomt svar p=, medan en rekursiv resolver fortfarande returnerar den tidigare publika nyckeln. Incidentjournalen visar en godkänd återkallelse. Detta stöder en cache-övergångsförklaring; den fastställer inte att alla mottagare redan har slutat validera den gamla signaturen.
Ett andra test använder s=old-billing, med ett bindestreck frånvarande från den avsedda väljaren. Det finns ingen post för det namnet. Uppslagsfelet är verkligt, men det bevisar inte att den avsedda väljaren återkallades. Exakta namn hindrar dessa två fall från att kollapsa till en incident.
Verifiera ersättningen utan att återställa exponeringen
Om fortsatt sändning är tillåten, använd en ny, säkert genererad nyckel och en väljarövergång som stöds. Bekräfta auktoritativ publicering och inspektera ett mottaget test från varje påverkad applikation. Håll den komprometterade nyckeln borta från återställningsskript, säkerhetskopior som återställs till aktiva undertecknare och kopierade konfigurationsmallar.
Bevara den gamla konfigurationen som incidentbevis under begränsad åtkomst, inte som ett automatiskt återställningsmål. En återställning som återställer en komprometterad signeringshemlighet kan återskapa problemet. Stäng incidenten med myndigheten för ändringen, berörda väljare, inneslutningsåtgärder, cache-observationer och nya signaturbevis. Spela in alla äldre legitima meddelanden vars verifiering avsiktligt offrades.
Klassificera uppslagningen innan du väljer en åtgärd
Använd dessa som syntetiska diagnostiska grenar, inte resultat från en riktig domän:
- Exakt väljare returnerar ett tomt p-värde: nyckeln återkallas uttryckligen; RFC 6376 kräver PERMFAIL (nyckel återkallad).
- Exakt väljare har ingen nyckelpost: RFC 6376 kräver PERMFAIL (ingen nyckel för signatur). Kontrollera stavning, delegering och godkänd pensionshistorik.
- Fråga får inget svar: RFC 6376 tillåter TEMPFAIL (nyckeln är inte tillgänglig). Denna observation i sig bevisar inte återkallelse.
Dessa resultat berör den signaturen. Bevara andra signaturer och deras resultat separat; ett meddelande kan ha en annan autentiseringsväg.
Relaterad läsning
DKIM DNS delegering: bedöm omfattningen av kontroll som beviljas en leverantör · Lagra och skydda DKIM privata nycklar över signeringssystem.