Perubahan alamat pengiriman penyedia dapat memperlihatkan daftar yang diizinkan sudah usang, konfigurasi yang tidak lengkap, atau rute yang tidak disadari aktif oleh siapa pun. Responsnya harus menentukan hal mana yang terjadi. Menambahkan IP yang ditunjukkan pada penolakan pertama dapat memulihkan satu sampel sambil membiarkan masalah pemeliharaan yang mendasarinya tetap utuh.
Konfirmasikan perubahan dan cakupannya
Kumpulkan bukti pesan yang terpengaruh dan tidak terpengaruh, termasuk waktu kejadian, IP yang diamati oleh penerima, dan identitas amplop yang dievaluasi. Periksa instruksi konsol terotentikasi penyedia saat ini, dokumentasi resmi, atau respons dukungan untuk layanan Anda. A membalikkan DNS Pencarian nama atau pemilik jaringan saja tidak menentukan bahwa suatu alamat diotorisasi untuk email penyewa Anda.
Tentukan apakah lalu lintas yang terpengaruh menggunakan layanan utama yang dikonfigurasi, wilayah yang baru diaktifkan, relai berbeda, atau rute khusus. Jangan menyimpulkan kejadian di seluruh penyedia dari perilaku satu aplikasi. Biarkan penjelasan yang belum dikonfirmasi diberi label sebagai hipotesis sampai bukti yang mendukungnya.
Identifikasi bagaimana kebijakan Anda mengikuti penyedia
Kebijakan berbasis ketergantungan dapat mencerminkan perubahan yang dilakukan pada kebijakan penyedia yang direferensikan. Rentang salinan statis memerlukan pembaruan. Generator terkelola memperkenalkan rantai tambahan antara sumber penyedia dan nilai yang Anda publikasikan. RFC 7208 bagian 5.2 menjelaskan meliputi evaluasi; itu tidak menjanjikan layanan penyegaran penyedia tertentu.
Bandingkan konfigurasi yang didukung penyedia, kebijakan yang Anda inginkan, dan jawaban DNS sebenarnya. Jika Anda menggunakan perataan, periksa kesegaran dan rentang yang ditambahkan dan dihilangkan menggunakan alur kerja salinan basi. Jika Anda menggunakan penyertaan penyedia, pastikan bahwa penyertaan tersebut merupakan penyertaan yang tepat untuk konfigurasi produk dan penyewa, dan periksa evaluasinya saat ini daripada berasumsi bahwa kata "penyertaan" menjamin kebenarannya.
Reproduksi satu kegagalan dengan tepat
Gunakan IP koneksi yang gagal dan domain envelope dalam evaluator yang sadar standar. Pertahankan jejak ketergantungan dan kategori hasil. Kegagalan asli berbeda dengan kesalahan yang disebabkan oleh persyaratan evaluasi yang berlebihan, kebijakan yang hilang, atau kegagalan DNS sementara. RFC 7208 §2.6 Dan RFC 7208 §4.6.4 memberikan perbedaan yang relevan.
Perhatikan kejadian ilustrasi ini. Layanan memindahkan sejumlah lalu lintas dari 192.0.2.10 ke 192.0.2.20 , sementara pelanggan menyimpan entri manual untuk layanan sebelumnya. Alamat dokumentasi ini hanyalah contoh saja. Koreksi yang tepat bergantung pada otorisasi yang didukung penyedia, bukan pada memperlakukan kedua pengamatan tersebut sebagai armada pengirim yang lengkap. Sertakan IPv6 dalam penyelidikan saat rute menggunakannya.
Pilih perbaikan yang didukung
Jika ketergantungan kebijakan yang terdokumentasi hilang atau salah, siapkan konfigurasi dukungan yang benar. Jika salinan yang diratakan sudah basi, perbaiki tahap penyegaran atau penerbitannya serta keluaran saat ini. Jika kebijakan penyedia yang dipublikasikan tampak tidak konsisten dengan rute pengirimannya, pertahankan kasus minimal yang dapat direproduksi untuk tim dukungannya dan hindari mencari solusi permanen.
Pengecualian sementara apa pun harus memiliki ruang lingkup yang dikonfirmasi, persetujuan, nama pemilik, dan kondisi kedaluwarsa atau peninjauan. Jangan mengotorisasi seluruh platform hosting karena alamat baru adalah miliknya. Pertahankan catatan yang ada dan periksa penggantian lengkap sintaksis, perilaku pencarian, dan perubahan otorisasi yang tidak diinginkan sebelum dipublikasikan.
Verifikasi pemulihan dan cegah terulangnya kembali
Uji aplikasi yang terpengaruh melalui rute biasa dan periksa hasil penerima yang tepercaya. RFC 8601 adalah referensi untuk menafsirkan pernyataan autentikasi melintasi batas kepercayaan. Ulangi pengujian di seluruh rute yang relevan daripada mengekstrapolasi dari satu pesan yang berhasil.
Simpan bukti penyedia, perbedaan DNS yang tepat, hasil pesan yang diterima, dan pengecualian yang tersisa dalam catatan insiden. Hapus entri sementara ketika perbaikan tahan lama yang didukung diverifikasi. Tambahkan pemantauan untuk tahapan yang gagal: perubahan sumber, kesegaran generator, kesalahan penerbitan, atau perutean yang tidak terduga. Tujuannya bukan untuk memperpanjang daftar darurat yang diperbolehkan. Ini adalah jalur otorisasi yang dapat dipelihara yang mengikuti layanan yang sebenarnya Anda gunakan.
Tuliskan keputusannya
Untuk pesan hipotetis yang gagal, pertahankan satu baris untuk instruksi/versi penyedia, domain amplop yang diinginkan, IP/keluarga yang diamati, kebijakan sumber pada waktu pengambilan, nilai yang dihasilkan, jawaban yang dipublikasikan, dan hasil penerima. Jika sumber penyedia menyertakan alamat baru tetapi generator tidak, selidiki pembuatannya; jika pembuatannya terkini tetapi DNS sudah lama, selidiki status publikasi dan penyelesainya. Ini adalah kasus diagnostik bersyarat, bukan temuan tentang penyedia yang disebutkan namanya.