Før du godkjenner DKIM delegering, be om den nøyaktige DNS endringen og signeringsidentiteten den vil aktivere. "Legg til våre DNS -poster" er en for bred instruksjon for en sikkerhetsgjennomgang. EN velger CNAME, en NS-delegasjon og tilgang til hele DNS kontoen gir ulike former for kontroll.
Tegn grensen før du godkjenner den
Et CNAME på ett velgernavn leder oppløsningen gjennom målet. En leverandør som kontrollerer det målet kan endre verifikasjonsdataene som nås gjennom aliaset. Den gir ikke i seg selv tillatelse til å redigere vilkårlige navn i sonen din. En NS-delegasjon etablerer en sonegrense og gir de delegerte autoritative serverne ansvar for navn under den, underlagt DNS hierarkiet. Administrativ tilgang for hele kontoen kan fortsatt være mye bredere. RFC 1034 §3.6.2 og RFC 1034 §4.2 beskrive disse DNS mekanismene.
Skriv inn eiernavnet og det berørte undertreet i godkjenningen. En forespørsel om service1._domainkey.example.com er forskjellig fra kontroll over hele _domainkey.example.com undertre. Ikke bytt ut en smal leverandørstøttet post med en bred delegering bare fordi den virker enklere å automatisere.
Skille DNS omfang fra signeringspåvirkning
DKIM verifisering får en nøkkel ved å bruke signaturens velger og signeringsdomene. Kontroll over en brukbar velgers bekreftelsesdata, sammen med den matchende private signeringsnøkkelen, kan aktivere gyldige signaturer for det signeringsdomenet. Den tilsynelatende smalheten til ett DNS navn betyr derfor ikke at konsekvensen av e-posttillit er ubetydelig.
Et syntetisk eksempel illustrerer skillet. En leverandør mottar et CNAME kl invoices._domainkey.example.com og driver matchende underskriver for d=example.com. Dens DNS tilgang er begrenset til alias-målet, men den underskriveren kan produsere signaturer som krever ansvar fra example.com. En velger som heter fakturaer begrenser ikke selv signaturer til fakturaer, bestemte mottakere eller en godkjent kampanje. Applikasjons- og kontokontroller må pålegge disse grensene.
Hvis du bruker et dedikert sendeunderdomene, vurder det aktuelle DMARC justering regler også. Subdomene-separasjon isolerer ikke automatisk avslappet justering. RFC 9989 §4.4 beskriver hvordan autentiserte identifikatorer sammenlignes med forfatterdomenet; politikken og organisasjonsdomenebestemmelsen gjelder.
Samle bevis som svarer på godkjenningsspørsmålet
Be om leverandørens gjeldende instruksjoner, genererte navn, kontoidentifikator, støttet signeringsdomene og rotasjonsmodell. Bekreft hvem som kan endre disse verdiene i leverandørkontoen og om rolleseparasjon er tilgjengelig. Spør om kontostenging og foreldet DNS-håndtering, uten å anta kontraktsmessige garantier som ikke er levert.
Bygg et kompakt register: DNS -eier, posttype, destinasjon eller navneservere, tjenesteeier, tiltenkt d= identitet, privilegerte leverandørbrukere, fornyelsesdato og pensjonsprosedyre. For en foreslått NS-delegasjon, inspiser hele det berørte undertreet for eksisterende velgere før du godkjenner det. For en forespørsel om kontotilgang, utfordre hvorfor instruksjoner per post eller en smalere støttet rolle ikke er tilstrekkelig.
Test onboarding og planavslutning
Etter en godkjent endring, sammenlign autoritative og rekursive DNS observasjoner og send gjennom den tiltenkte tjenesten. Inspiser en pålitelig mottakers DKIM resultat og justering. Testen skal demonstrere den innvilgede identiteten, ikke bare vise at noen signaturer består.
Ved oppsigelse, stopp applikasjonstilgang, fjern foreldet sendelegitimasjon og koordiner velgerpensjonering med leveringskøer og leverandørens prosess. Hvis leverandøren mistenkes for kompromittering, påkall hendelsesrespons i stedet for å bevare en rutineoverlapping automatisk. En tjeneste merket som inaktiv i anskaffelsesposter kan fortsatt representere en direkte teknisk avhengighet.
Dokumenter gjenværende tillit eksplisitt: hva leverandøren kan signere, hvem som kan administrere den og hvor raskt organisasjonen kan fjerne avhengigheten. Denne posten gjør senere fornyelser til en gjennomgang av faktisk autoritet i stedet for en repetisjon av den originale DNS billetten.
Sammenlign tre hypotetiske godkjenningsforespørsler
Bruk omfanget og konsekvensen sammen:
- Én velger CNAME : gjennomgå dens eksakte eier og mål, tiltenkte identitet og leverandørkontokontroller. Den gir ikke vilkårlig soneredigeringstilgang, men nøkkeltilordningen kan aktivere signering for den identiteten.
- NS-delegering under _domainkey.example.com : inventar velgerne under den delegerte sonen og hvem som kontrollerer dens autoritative servere. Eksisterende eller fremtidige velgere der kan bli påvirket, med forbehold om ytterligere sonekutt.
- Full DNS kontotilgang: krever et eksplisitt behov og inspiser kontoens faktiske tillatelser. Det kan nå urelaterte e-post- og webposter; dette tilsvarer ikke å publisere ett velgeralias.
Dette er gjennomgangsscenarier, ikke autorisasjoner eller endringer som er gjort i en reell sone. Hvis det nøyaktige omfanget eller eierskapet er ukjent, må du løse dette gapet før godkjenning.
Relatert lesing
DKIM TXT og CNAME publisering: Følg leverandørens nøkkelstyringsmodell · Tilbakekall en DKIM nøkkel og skille tilbakekalling fra en manglende DNS post.