Prioritaskan konsekuensinya, bukan warna peringatannya
Pemeriksa kesehatan DNS dapat menggabungkan kegagalan protokol, rekomendasi ketahanan, dan fitur opsional menjadi satu skor yang mengkhawatirkan. Operator surat memerlukan urutan yang berbeda: keputusan apa yang terpengaruh, rute mana, dan dengan bukti apa? Aktif tidak tersedia DKIM kunci dan rekomendasi untuk TTL yang lebih rendah tidak secara otomatis menerima prioritas insiden yang sama.
Mulailah dengan menangkap peringatan yang tepat, nama pengujian dan jenis rekaman, waktu, penyelesai atau sudut pandang, dan penjelasan alat. Klasifikasikan hal tersebut sebagai kegagalan yang teramati, risiko yang masuk akal, atau rekomendasi yang bersifat nasihat. Jika alat hanya menyediakan label, pertahankan batasan tersebut. Jangan publikasikan catatan autentikasi lain hanya untuk membuat dasbor menjadi hijau.
Tetapkan apakah nama yang diuji termasuk dalam jalur email
Hilangnya catatan DKIM hanya berarti terkait dengan pemilih dan menandatangani domain yang sebenarnya digunakan oleh layanan yang sedang diselidiki. RFC 6376 bagian 3.6.2.1 mendapatkan nama pencarian dari nilai tanda tangan. Pemindai yang menebak pemilih mungkin melewatkan kunci valid yang diterapkan atau memperingatkan tentang nama yang tidak digunakan. Minta bukti pesan yang representatif sebelum menganggap ketidakhadiran yang diduga sebagai kegagalan produksi.
Terapkan disiplin yang sama pada SPF. Alat yang memeriksa domain Dari yang terlihat mungkin tidak memeriksa identitas SMTP yang dievaluasi oleh penerima. RFC 7208 bagian 2 membedakan identitas tersebut. Tentukan rute dan nama sebenarnya yang dievaluasi sebelum memutuskan pemilik mana yang harus memperbaiki peringatan.
Temukan otoritas yang saat ini didelegasikan, termasuk delegasi atau alias zona anak yang relevan. Panel kontrol adalah bukti konfigurasi yang dimaksudkan hanya jika hubungannya dengan otoritas tersebut diketahui. Pertahankan perbedaan antara catatan yang tidak ada, nilai pada nama yang salah, dan edit pada akun hosting yang salah.
Interpretasikan respons sebelum mengubah catatan
NXDOMAIN menunjukkan tidak adanya nama yang ditanyakan, sedangkan hasil NODATA menunjukkan bahwa data yang diminta tidak ada pada nama yang ada. Caching negatif dapat mempertahankan hasil sebelumnya, seperti yang dijelaskan dalam RFC 2308 bagian 2 dan 5. Oleh karena itu, rekaman yang baru dibuat mungkin muncul di otoritas sebelum jalur rekursif tertentu menunjukkannya.
SERVFAIL malah menggambarkan kegagalan resolusi dan tidak membuktikan bahwa kebijakan tersebut tidak ada. RFC 9520 bagian 2.1 membahas banyak kemungkinan penyebabnya. Selidiki delegasi, keterjangkauan, dan bukti validasi. Menambahkan rekaman duplikat saat resolusi rusak dapat menimbulkan masalah kedua setelah kegagalan awal diperbaiki.
Peringatan tentang dukungan TCP layak mendapatkan lebih dari sekadar penolakan sekadarnya. RFC 7766 bagian 5 memerlukan implementasi DNS tujuan umum untuk mendukung UDP dan TCP. Pencarian kecil yang berhasil tidak membuktikan bahwa respons yang lebih besar atau jalur lain berfungsi dengan benar. Tindak lanjut yang tepat adalah diagnosis transportasi yang tercakup, bukan klaim bahwa setiap pesan saat ini telah gagal.
Pisahkan dampak langsung dari risiko laten
Temuan langsung yang berdampak pada email menghubungkan masalah DNS yang diamati ke rute aktif: misalnya, kegagalan penyelesai untuk pemilih yang diperlukan penerima pada waktu verifikasi. Masalah keandalan yang laten mungkin membuat pengujian saat ini gagal dan mengurangi ketahanan. Temuan yang disarankan mungkin berkaitan dengan fitur yang diinginkan yang ketidakhadirannya tidak membatalkan protokol yang sebenarnya diterapkan.
Klasifikasikan dengan dua dimensi: keyakinan pada observasi dan konsekuensi jika kondisi terus berlanjut. Kecurigaan yang berdampak besar dengan bukti yang tidak lengkap mungkin memerlukan penyelidikan segera tanpa memerlukan pernyataan pemadaman. Pengecualian nasihat yang sudah kadaluarsa harus menerima pemilik dan tanggal peninjauan daripada menghilang secara diam-diam dari laporan.
Hindari label menyeluruh seperti “DNSSEC hilang berarti otentikasi email rusak.” DNSSEC dapat menambahkan data DNS yang diautentikasi, sedangkan SPF , DKIM dan DMARC mempunyai persyaratan dan hasil tersendiri. Di mana DANE SMTP dikerahkan, DNSSEC memiliki peran langsung dalam desain transportasi di bawah RFC 7672 bagian 2.1. Oleh karena itu, peringatan yang sama dapat menimbulkan konsekuensi berbeda di seluruh layanan.
Contoh karya fiksi dari tiga peringatan
Pemeriksa fiktif example.com melaporkan pemilih yang tidak ada yang disebut default, pencarian TCP yang gagal ke satu titik akhir otoritatif, dan rekomendasi TTL. Inventaris yang ditemukan oleh tim email mengidentifikasi Juni sebagai pemilih yang digunakan oleh rute faktur aktifnya. Oleh karena itu, peringatan pertama memerlukan konfirmasi pemilih daripada pembuatan catatan segera.
Peringatan kedua ditujukan kepada pemilik DNS dengan titik akhir yang diuji, waktu, dan detail respons yang terpengaruh. Ini mewakili masalah transportasi meskipun satu permintaan UDP kecil berhasil. Rekomendasi TTL menjadi diskusi perencanaan perubahan: mengurangi TTL mungkin membantu perubahan di masa depan, namun hal ini tidak membuktikan kegagalan pengiriman saat ini atau segera memperpendek entri yang sudah di-cache dengan nilai yang lebih lama.
Tidak ada kueri atau pesan yang dieksekusi untuk skenario ini. Prioritas yang diusulkan menggambarkan bagaimana menghindari memperlakukan skor dasbor yang beragam sebagai keputusan teknis. Klasifikasi yang sebenarnya memerlukan retensi hasil otoritatif dan rekursif serta bukti yang menghubungkan catatan yang diuji dengan layanan.
Catat keputusan yang dapat ditinjau
Untuk setiap peringatan, catat ketergantungan yang terkena dampak, bukti, keyakinan, pemilik, tindakan selanjutnya, dan kondisi penutupan. “Periksa ulang nanti” tidaklah lengkap tanpa mengidentifikasi apa yang berubah dan apa yang harus ditetapkan oleh pengamatan selanjutnya. “Risiko yang dapat diterima” harus mencakup siapa yang menerimanya dan kapan keputusan tersebut akan dipertimbangkan kembali.
Setelah perbaikan resmi, ulangi pengamatan yang relevan dan verifikasi layanan dependen daripada hanya menyegarkan skor asli. Pertahankan perbedaan yang belum terselesaikan antara otoritas, jalur rekursif, dan hasil pesan. Gerbang bukti asli tetap terbuka sampai jawaban otoritatif dan rekursif yang diberi stempel waktu mengidentifikasi nama pemilik sebenarnya dan jenis rekaman. Naskah ini tidak menyediakan observasi atau sertifikasi kesehatan domain.