Hasil pemeriksa hijau dan pesan yang gagal keduanya bisa akurat. Pemeriksa mungkin telah memeriksa kebijakan DNS saat ini untuk satu nama, sementara penerima mengevaluasi domain Dari yang berbeda, menggunakan jawaban cache sebelumnya, atau menerima pesan tanpa tanda tangan selaras yang diinginkan.
Mulailah dengan membandingkan kedua observasi tersebut. Pertahankan hasil asli sebelum mengubah konfigurasi. Kemudian tanyakan secara pasti apa yang diperiksa oleh masing-masing sistem dan kapan.
Tuliskan apa yang sebenarnya diperiksa oleh pemeriksa
Catat domain yang dimasukkan, nama kueri yang tepat, jenis kueri, stempel waktu, pemecah masalah, dan kumpulan rekaman yang dikembalikan. Simpan penjelasan yang ditampilkan serta warna hasilnya. Tentukan apakah alat tersebut hanya memeriksa DNS atau benar-benar mengevaluasi pesan yang diberikan.
Untuk kebijakan yang dipublikasikan di _dmarc.example.com , pencarian positif akan menetapkan kebijakan yang diamati pada nama tersebut. Itu tidak menetapkan SPF atau DKIM identitas pada pesan aplikasi. Hal ini juga tidak membuktikan bahwa alat tersebut mengikuti aturan penemuan yang sama seperti penerimanya.
Jaga agar asumsi spesifikasi tetap terlihat. Saat ini RFC 9989 §4.10 menggunakan aturan penelusuran pohon DNS untuk penemuan dan domain organisasi. Implementasi warisan dapat menggunakan asumsi yang berbeda, khususnya untuk yang santai penyelarasan. Jangan menggambarkan ketidaksepakatan sebagai kesalahan DNS sampai perbandingannya mendukung kesimpulan tersebut.
Mulai penyelidikan penerima dari pesan tersebut
Untuk contoh yang disampaikan, pertahankan pesan asli yang diterima dan identifikasi sistem penerima yang tepercaya Authentication-Results. Catat domain From yang terlihat, identitas SPF yang dievaluasi, setiap nilai d dan s DKIM , hasil autentikasi, penyelarasan dan kebijakan yang berlaku.
Di bawah RFC 8601 §7.1, perlakukan pernyataan autentikasi yang tidak tepercaya sebagai konten pesan, bukan pengganti kerja sistem penerima. Nama penyedia di header juga tidak menetapkan bahwa organisasi Anda menyetujui akun yang menggunakannya.
Untuk penolakan, mungkin tidak ada pesan terkirim untuk diperiksa. Simpan teks SMTP yang dikembalikan secara lengkap, referensi pesan atau transaksi, akun pengirim, domain penerima, dan stempel waktu. Gabungkan data tersebut dengan catatan peristiwa sistem pengirim dan pesan asli yang dikirimkan.
Kumpulkan perbandingan DNS dengan konteks
Paket investigasi harus mencakup:
- Pengamatan: Jawaban otoritatif lengkap untuk nama pemilik sebenarnya; Mengapa menyimpannya: Menampilkan data zona penayangan pada waktu pengumpulan
- Pengamatan: Jawaban rekursif yang relevan, termasuk status dan TTL; Mengapa menyimpannya: Menampilkan tampilan penyelesai dan kemungkinan status cache
- Pengamatan: Alias atau jalur delegasi apa pun; Mengapa mempertahankannya: Menjelaskan otoritas dan nama mana yang terlibat
- Pengamatan: Penuh catatan TXT batasan; Mengapa menyimpannya: Membedakan satu data multi-string dari beberapa kandidat kebijakan
- Pengamatan: Waktu pengumpulan UTC dan riwayat perubahan terkini; Mengapa menyimpannya: Menghubungkan data saat ini dengan waktu evaluasi pesan
Hindari hanya menyimpan + keluaran singkat ketika kode respons, informasi otoritas, atau ketidakhadiran penting. Menggunakan panduan catatan yang hilang untuk menelusuri nama dan wewenangnya.
Jawaban resmi saat ini adalah bukti berharga, namun tidak dapat merekonstruksi cache historis penerima jarak jauh. Nyatakan kesenjangan tersebut daripada menyatakan bahwa penerima pasti menggunakan jawaban hari ini.
Atasi ketidakcocokan sintetis
Kasus fiktif ini menunjukkan mengapa pencocokan cakupan itu penting:
- Item: Pemeriksa pada 14:10 UTC; Pengamatan yang diambil: Kebijakan yang valid untuk example.com
- Item: Pesan gagal pada 14:04 UTC; Pengamatan yang diambil: Dari alerts@notices.example.com
- Barang: Tanda tangan pengirim; Pengamatan yang diambil: d=mailer.example.net memverifikasi
- Hal: Sumber bukti kebijakan; Pengamatan yang diambil: Aplikasi menggunakan domain amplop yang dikontrol penyedia
- Barang: Konfigurasi subdomain; Pengamatan yang diambil: Ada kebijakan eksplisit untuk notices.example.com
Pemeriksa domain root belum menetapkan kebijakan atau penyelarasan untuk pesan tersebut. Tanda tangan penyedia yang lewat juga tidak terkait dengan domain Dari dalam contoh ini. Selidiki kebijakan subdomain dan konfigurasi selaras yang didukung aplikasi.
Kasus yang berbeda mungkin mengungkapkan bahwa identitas yang benar sudah selaras tetapi waktu pencarian kebijakan yang diperlukan telah habis; RFC 9989 §5.3.6 tidak mengklasifikasikan pemeriksaan yang tidak lengkap itu sebagai lulus atau gagal. Warna pemeriksa yang sama akan menghasilkan perbaikan yang berbeda.
Jaga agar kategori respons DNS tetap berbeda
Jawaban sukses yang berisi data relevan berbeda dengan NXDOMAIN , respons tanpa data lengkap, SERVFAIL , REFUSED, dan batas waktu. Pengamatan ini tidak semuanya berarti “tidak catatan DMARC”. RFC 1035 §4.1.1 mendefinisikan kode respons DNS ; RFC 2308 §2.1 Dan RFC 2308 §2.2 bedakan NXDOMAIN dan NODATA .
Periksa nama yang ditanyakan sebelum menafsirkan ketidakhadiran. NXDOMAIN untuk _dmarc.example.com , tanpa komplikasi alias, menjelaskan nama pemilik yang ditanyakan; hal ini tidak dengan sendirinya menyatakan bahwa example.com tidak ada.
Di bawah RFC 2308 §5, cache negatif dapat mempertahankan ketidakhadiran sebelumnya sebuah rekor ditambahkan. Caching positif dapat mempertahankan nilai sebelumnya setelah pengeditan. Pertahankan konteks respons dan waktu pengumpulan sehingga penjelasan dapat dinilai.
Pilih perbaikan dari bukti yang cocok
Jika alat dan penerima memeriksa nama yang berbeda, perbaiki ruang lingkup penyelidikan. Jika pesan tidak memiliki jalur yang selaras, perbaiki konfigurasi pengiriman yang didukung. Jika jawaban berbeda di antara server resmi, selidiki konsistensi zona. Jika resolusi rekursif gagal, periksa jalur penyelesai, delegasi, validasi, dan transportasi.
Pengeditan kebijakan bukanlah perbaikan otomatis untuk setiap perbedaan. Ubah konfigurasi terkecil yang relevan dan pertahankan alasannya. Menggunakan panduan penyelarasan ketika otentikasi mentah lolos untuk domain yang tidak selaras.
Ulangi tes terkontrol dan tutup perbandingannya
Setelah perbaikan, ambil observasi DNS baru dan pesan representatif melalui akun dan rute aplikasi yang sama. Bandingkan hasil baru dengan paket sebelumnya dan jelaskan bukti yang diubah.
Satu percobaan ulang yang berhasil menunjukkan upaya tersebut. Lanjutkan pemeriksaan tingkat layanan yang ditentukan ketika insiden melibatkan beberapa rute atau penerima.
Kesimpulan yang berguna adalah laporan yang cocok mengenai ketidaksepakatan: apa yang diperiksa, apa yang dievaluasi oleh penerima, perbedaan apa yang penting dan perbaikan apa yang mengubah hasilnya.
Buatlah keputusan berikutnya secara eksplisit
Untuk pemeriksa 14:10 dan perlengkapan pesan 14:04, pertama-tama selaraskan Domain Penulis yang ditanyakan dan rekonstruksi identitas pesan; jangan mengaitkan perbedaan enam menit dengan cache tanpa bukti. Kesalahan DNS yang diperlukan dan kurangnya penyelarasan adalah temuan yang berbeda. Jawaban basi yang memenuhi syarat dapat melampaui masa berlaku TTL di bawah RFC 8767 §4. Pengamatan yang diilustrasikan adalah fiksi, bukan log yang diambil.