Sebelum menyetujui DKIM delegasi, minta perubahan DNS yang tepat dan identitas penandatanganan yang akan diaktifkannya. “Tambahkan data DNS kami” merupakan instruksi yang terlalu luas untuk tinjauan keamanan. A pemilih CNAME, delegasi NS dan akses ke seluruh akun DNS memberikan bentuk kontrol yang berbeda.
Gambarkan batasannya sebelum menyetujuinya
CNAME pada satu nama pemilik pemilih mengarahkan resolusi melalui targetnya. Penyedia yang mengendalikan target tersebut dapat mengubah data verifikasi yang dicapai melalui alias. Itu tidak dengan sendirinya memberikan izin untuk mengedit nama sewenang-wenang di zona Anda. Delegasi NS menetapkan batas zona dan memberikan tanggung jawab kepada server otoritatif yang didelegasikan atas nama-nama di bawahnya, sesuai dengan hierarki DNS . Akses administratif seluruh akun masih bisa lebih luas. RFC 1034 §3.6.2 Dan RFC 1034 §4.2 jelaskan mekanisme DNS ini.
Tulis nama pemilik dan subpohon yang terpengaruh ke dalam persetujuan. Permintaan untuk service1._domainkey.example.com berbeda dari kendali keseluruhan _domainkey.example.com subpohon. Jangan mengganti data sempit yang didukung penyedia dengan delegasi luas hanya karena tampaknya lebih mudah untuk diotomatisasi.
Bedakan cakupan DNS dari dampak penandatanganan
Verifikasi DKIM memperoleh kunci menggunakan pemilih tanda tangan dan domain penandatanganan. Kontrol atas data verifikasi pemilih yang dapat digunakan, bersama dengan kunci penandatanganan pribadi yang cocok, dapat mengaktifkan tanda tangan yang valid untuk domain penandatanganan tersebut. Oleh karena itu, sempitnya satu nama DNS tidak berarti konsekuensi kepercayaan email dapat diabaikan.
Contoh sintetik menggambarkan perbedaannya. Penyedia menerima CNAME di invoices._domainkey.example.com dan mengoperasikan penandatangan yang cocok untuk d=example.com. Akses DNS -nya terbatas pada target alias, namun penandatangan tersebut dapat menghasilkan tanda tangan yang mengaku bertanggung jawab example.com. Pemilih bernama faktur tidak dengan sendirinya membatasi tanda tangan pada faktur, penerima tertentu, atau kampanye yang disetujui. Kontrol aplikasi dan akun harus menerapkan batasan tersebut.
Jika Anda menggunakan subdomain pengirim khusus, nilai subdomain yang berlaku DMARC penyelarasan aturan juga. Pemisahan subdomain tidak secara otomatis mengisolasi perataan yang santai. RFC 9989 §4.4 menjelaskan bagaimana pengidentifikasi yang diautentikasi dibandingkan dengan Domain Penulis; masalah kebijakan dan penentuan domain organisasi.
Kumpulkan bukti yang menjawab pertanyaan persetujuan
Minta instruksi penyedia saat ini, nama yang dihasilkan, pengidentifikasi akun, domain penandatanganan yang didukung, dan model rotasi. Verifikasi siapa yang dapat mengubah nilai-nilai tersebut di dalam akun penyedia dan apakah pemisahan peran tersedia. Tanyakan tentang penutupan akun dan penanganan DNS yang basi, tanpa mengasumsikan jaminan kontrak yang belum diberikan.
Buat register yang ringkas: pemilik DNS , jenis rekaman, tujuan, atau server nama, pemilik layanan, dimaksudkan d= identitas, pengguna penyedia istimewa, tanggal perpanjangan dan prosedur pensiun. Untuk delegasi NS yang diusulkan, periksa seluruh subpohon yang terpengaruh untuk penyeleksi yang ada sebelum menyetujuinya. Untuk permintaan akses akun, tanyakan mengapa instruksi per rekaman atau peran yang didukung secara lebih sempit tidak cukup.
Uji orientasi dan rencanakan penghentian
Setelah perubahan disetujui, bandingkan pengamatan DNS otoritatif dan rekursif dan kirimkan melalui layanan yang dimaksud. Periksa hasil dan penyelarasan DKIM penerima tepercaya. Tes tersebut harus menunjukkan identitas yang diberikan, tidak hanya menunjukkan bahwa beberapa tanda tangan lolos.
Pada saat penghentian, hentikan akses aplikasi, hapus kredensial pengiriman yang usang dan koordinasikan penghentian pemilih dengan antrian pengiriman dan proses penyedia. Jika penyedia layanan dicurigai melakukan kompromi, lakukan respons terhadap insiden daripada mempertahankan rutinitas yang tumpang tindih secara otomatis. Layanan yang ditandai tidak aktif dalam catatan pengadaan masih dapat menunjukkan ketergantungan teknis yang nyata.
Dokumentasikan sisa kepercayaan secara eksplisit: apa yang dapat ditandatangani oleh penyedia, siapa yang dapat mengelolanya, dan seberapa cepat organisasi dapat menghilangkan ketergantungan. Catatan tersebut membuat pembaruan selanjutnya menjadi peninjauan otoritas sebenarnya, bukan pengulangan tiket DNS asli.
Bandingkan tiga permintaan persetujuan hipotetis
Gunakan cakupan dan konsekuensi bersama-sama:
- Satu pemilih CNAME : meninjau pemilik dan target sebenarnya, identitas yang diinginkan, dan kontrol akun penyedia. Ini tidak memberikan akses pengeditan zona secara sewenang-wenang, namun pemetaan kuncinya dapat memungkinkan penandatanganan identitas tersebut.
- Delegasi NS di bawah _domainkey.example.com : menginventarisasi penyeleksi di bawah zona yang didelegasikan tersebut dan siapa yang mengontrol server resminya. Pemilih yang sudah ada atau yang akan datang di sana mungkin terpengaruh, tergantung pada pemotongan zona lebih lanjut.
- Akses akun DNS penuh: memerlukan kebutuhan eksplisit dan memeriksa izin akun yang sebenarnya. Ini mungkin mencapai email dan catatan web yang tidak terkait; ini tidak sama dengan menerbitkan satu alias pemilih.
Ini adalah skenario peninjauan, bukan otorisasi atau perubahan yang dilakukan pada zona sebenarnya. Jika cakupan atau kepemilikan pastinya tidak diketahui, selesaikan kesenjangan tersebut sebelum mendapatkan persetujuan.
Bacaan terkait
Penerbitan DKIM TXT dan CNAME : ikuti model manajemen kunci penyedia · Cabut kunci DKIM dan bedakan pencabutan dari data DNS yang hilang.