Aliverkkotunnuksen delegointi voi helpottaa lähetyspalvelun käyttöä, mutta se jakaa myös organisaatioidentiteetin hallinnan. Hyödyllinen DKIM design nimeää DNS omistajan, yksityisen avaimen säilyttäjän ja yrityksen omistajan erikseen. Siinä kerrotaan myös tarkalleen, mitä delegoidaan ja miten delegointi päättyy.
Älä aloita julkaisemalla rajoittavia tietueita tai olettamalla, että aliverkkotunnus lähettää vain postia. Määritä sen nykyinen ja aiottu tarkoitus, mukaan lukien vastaanotto, sovellusten käyttö ja perinnölliset riippuvuudet. DKIM määritykset eivät yksinään ratkaise sitä, tuleeko nimitilan hyväksyä viestejä, palvella verkkosivustoa vai jäädä lepotilaan.
Määritä delegoinnin raja
Erottele valitsintaso CNAME koko DNS vyöhykkeen delegoinnista NS-tietueiden avulla. A valitsin CNAME osoittaa tietyn haun palveluntarjoajan hallinnoimiin vahvistustietoihin RFC 1034 §3.6.2. Vyöhykkeen valtuuskunta antaa auktoriteetin vastuun nimistä tällä vyöhykkeellä, jollei lisävyöhykeleikkauksista muuta johdu RFC 1034 §4.2; laajuus voi sisältää tietueita, jotka eivät liity DKIM . Tarkista tämä laajempi auktoriteetti ennen kuin käsittelet näitä kahta mekanismia keskenään vaihdettavissa olevina.
Tallenna koko valitsimen hakunimi, kohde- tai arvovaltainen vyöhyke, tarkoitettu d-verkkotunnus ja palveluntarjoajatili. RFC 6376 §3.1 kuvaa valitsimen käyttötapauksia ja RFC 6376 §3.6.2.1 määrittää avaimen haun. Se ei edellytä tietyn palveluntarjoajan ohjauspaneelin käyttöoikeuksia. Hanki palveluntarjoajan nykyiset ohjeet ja vastuullinen omistaja näistä luvista.
Määritä kolmenlaisia omistajuuksia
Yrityksen omistaja tietää, minkä viestien tulee jatkaa toimintaansa. DNS omistaja voi julkaista tai poistaa haun tai delegoinnin. Avainten säilyttäjä hallitsee yksityistä allekirjoitusavainta, olipa kyseessä sitten sisäinen järjestelmä tai hallittu palveluntarjoaja. Yhdellä tiimillä voi olla useita rooleja, mutta jokaisen vastuun tulee olla selkeä.
Kysy kuka voi kääntää avainta, muuttaa allekirjoitusverkkotunnusta, viedä todisteita ja poistaa lähetystilin käytöstä. Julkiset vahvistustiedot eivät ole yksityinen allekirjoitusavain. Älä koskaan pyydä palveluntarjoajan yksityistä avainta vain todistaaksesi sen ennätys on oikein; käytä sen sijaan dokumentoituja ohjausobjekteja ja vastaanotettujen viestien vahvistusta.
Työskentele laajennetun esimerkin läpi
Havainnollistava ulkoasu: receipts.mail.example on määritetty laskutuspalveluun, jossa on tuettu allekirjoitus käyttämällä d=receipts.mail.example ja valitsin bill1. Organisaatio säilyttää emo DNS nsä, kun taas palveluntarjoaja hallitsee bill1._domainkey.receipts.mail.example -osoitteella saavutettua vahvistusmateriaalia. Kirjaa laskutuksen omistaja, DNS muutosomistaja ja palveluntarjoajan avaimen säilyttäjä täsmälleen tätä nimeä vastaan.
Jos näkyvä Lähettäjä-verkkotunnus on receipts.mail.example , identiteetit vastaavat täsmälleen. Jos Lähettäjä sen sijaan käyttää mail.example , arvioi määritetty linjaus tila alla RFC 9989 §3.2.10 ja organisaation verkkotunnuksen etsintä alla RFC 9989 §4.10.2; älä oleta tiukkaa linjausta. Läpäisevä allekirjoitus todistaa sen d-verkkotunnuksen salaussuhteen, ei sitä, että jokaisella ylätason osoitteella on sama yritysvaltuutus. Tämä on suunnitteluratkaisu, ei elävän vuokralaisen tulos.
Tarkista piilotetut riippuvuudet ennen muutosta
Hae ajoitettujen töiden, hankinta-ajan sovellusten ja vanhojen kampanjajärjestelmien määritysvarastoista aliverkkotunnuksen avulla. Tarkista vastaanottovaatimukset erikseen. DNS delegoinnin muutos voi vaikuttaa useampaan kuin DKIM , kun taas valitsimen poistaminen voi vaikuttaa viivästyneisiin viesteihin, jotka on jo allekirjoitettu tällä valitsimella.
Valmistele edustavat testit jokaiselle tunnetulle lähetysreitille. Capture From, d, s, luotetun vastaanottimen tulos ja kohdistus sekä DNS vastaus ja aikaleima. Tarkista normaali polku sekä palautusreitti. Vahvistetuksi merkitty kojelauta on hyödyllinen määritystodiste, mutta ei korvaa vastaanotettua viestiä.
Tee offboardista osa alkuperäistä suunnittelua
Dokumentoi kuinka lopettaa uusi allekirjoitus, säilyttää tarvittava vahvistus suunnitellun siirtymän aikana ja poistaa käyttämätön delegointi riippuvuuksien päätyttyä. Koordinoi tilin käyttöoikeus ja API-kirjautumistiedot erikseen; yhden DNS tietueen poistaminen ei ole täydellinen palveluntarjoajan poistaminen käytöstä. Jos epäillään avainten vaarantumista, turvallisuuden eristäminen voi olla etusijalla tavalliseen päällekkäisyyteen nähden.
Lopullisessa rekisterissä tulee näkyä nimitilan tarkoitus, myönnetty valtuutus, omistajat, testit ja poistumisehdot. Tämän tietueen avulla seuraava järjestelmänvalvoja voi erottaa tarvittavan riippuvuuden hylätystä osoittimesta arvaamatta palveluntarjoajan nimeä DNS ssä.
Kirjoita seuraava päätös muistiin
Ennen hyväksymistä vertaa tarkkaa pyydettyä nimeä ja tietuetyyppiä aiottuun viranomaiseen. Yhtä valitsinta CNAME ei saa korvata äänettömästi NS-delegaatiolla koko vyöhykkeelle. Jos palveluntarjoaja tarvitsee laajempaa soveltamisalaa, luettele asianomaiset nimet ja riippuvuudet ja hanki vastuullisen omistajan päätös. Esimerkki ei myönnä varsinaisia DNS oikeuksia.