Transfer zona menyalin data zona antara server DNS atau ke klien manajemen resmi. AXFR adalah protokol transfer penuh yang dijelaskan dalam RFC 5936 . Transfer yang tersedia secara tidak terduga mungkin mengungkapkan inventaris rekaman yang luas, namun keberadaannya tidak dengan sendirinya membuat otentikasi email lolos atau gagal. Menilai apa yang diungkapkan, apakah transfer memang disengaja, dan kontrol mana yang mengatur akses.
Tetapkan otoritas dan izin
Referensi: RFC 5936 §5.
Identifikasi zona yang tepat dan server resminya. Dapatkan otorisasi sebelum menguji transfer terhadap layanan produksi. Gunakan konfigurasi dan alat audit yang didukung penyedia terlebih dahulu jika tersedia. Jangan memindai domain yang tidak terkait atau mencoba mengabaikan transfer yang ditolak agar temuan tampak lebih dramatis.
Server sekunder yang sah mungkin memerlukan akses transfer. Layanan DNS otoritatif publik dan izin untuk mentransfer seluruh zona adalah keputusan terpisah. Tinjau klien yang diizinkan, mekanisme otentikasi, kontrol transportasi dan tujuan operasional. Daftar yang diizinkan hanya berdasarkan alamat tidak dapat dipertukarkan dengan autentikasi klien kriptografi.
Interpretasikan data yang dikembalikan dengan benar
Referensi: RFC 5936 §2.2, RFC 5936 §3.
AXFR mengembalikan konten zona sesuai dengan protokol, termasuk pembingkaian SOA awal dan akhir. Respons yang berhasil mungkin mengungkapkan nama-nama yang sudah dapat dikueri secara individual namun tidak dapat dihitung dengan mudah. Evaluasi apakah inventaris menunjukkan penamaan internal yang sensitif, layanan yang ditinggalkan, atau ketergantungan operasional. DNS publik tidak boleh digunakan sebagai penyimpanan rahasia.
Jangan samakan penolakan dengan zona aman sempurna. Catatan individual tetap dapat dikueri, dan inventaris mungkin tersedia melalui sertifikat, kebocoran konfigurasi, atau sumber lainnya. Sebaliknya, transfer publik yang disengaja tidak secara otomatis menimbulkan kerentanan; mengevaluasi kebijakan organisasi dan paparan aktual.
Pisahkan dampak email dari paparan inventaris
Referensi: RFC 6376 §3.1, RFC 5936 §1.
Transfer tidak berubah SPF otorisasi, ganti a DKIM kunci atau perubahan DMARC kebijakan. Menemukan a pemilih name tidak mengungkapkan kunci penandatanganan pribadinya. Kunci DKIM publik dirancang untuk diambil oleh verifikator. Jika suatu zona berisi nilai kredensial atau rahasia, itu adalah insiden penanganan data terpisah yang memerlukan responsnya sendiri.
Gunakan inventaris untuk memeriksa kepemilikan dan ketergantungan yang sudah usang tanpa mengklaim bahwa enumerasi membuktikan eksploitasi. Alias yang menggantung mungkin memerlukan penyelidikan, namun pengendalian sebenarnya bergantung pada layanan tujuan dan konfigurasi. Jangan mendaftarkan atau mengklaim sumber daya orang lain hanya untuk memperkuat laporan.
Reproduksi penilaian dengan aman
Pos pemeriksaan mencakup perlengkapan berbentuk transfer offline dengan SOA awal, penanda TXT , dan SOA akhir yang cocok. Pemeriksaan lokal memverifikasi pembingkaian sederhana dan memberi label pada bukti inventaris, bukan kegagalan otentikasi. Perlengkapan kedua berisi respons DITOLAK dan diberi label transfer ditolak, bukan zona aman.
Jalankan skrip yang disediakan untuk mereproduksi label tersebut. Ini bukan parser AXFR lengkap atau transfer jaringan. Untuk lab terisolasi resmi, konfigurasikan primer dan sekunder menggunakan dokumentasi resmi server yang dipilih, uji klien yang diizinkan dan klien yang ditolak, serta pertahankan respons aktual dan konfigurasi akses yang relevan. Implementasi penuh primer/sekunder dan pengujian kontrol akses masih belum dilakukan; pertukaran loopback skrip yang lebih sempit dan dipertahankan di bawah ini terpisah.
Remediasi dengan mempertimbangkan kesinambungan
Referensi: RFC 5936 §5, RFC 5936 §6.
Jika akses melebihi kebijakan, batasi transfer melalui kontrol server yang didukung sambil mempertahankan operasi sekunder yang sah. Tinjau pembatasan akses dan autentikasi daripada berasumsi bahwa yang satu menggantikan yang lain. Setelah perubahan, verifikasi menolak akses tidak sah dan melanjutkan transfer resmi, kesegaran zona, dan ketersediaan resmi.
Dokumentasikan cakupan catatan yang diungkapkan, klien yang dituju, remediasi yang tepat, dan batasan pengujian. Pisahkan hasil autentikasi email: pengujian pesan yang representatif dan kueri rekaman yang efektif masih diperlukan untuk menilai perilaku email. Laporan yang baik menyelesaikan paparan tanpa mengubah pengamatan administrasi DNS menjadi klaim keamanan email yang tidak didukung.
Bukti kawat sejarah yang disimpan
Berikut ini penjelasan pengambilan loopback 7 November 2026 yang dipertahankan, diperiksa tetapi tidak dijalankan kembali sebagai eksperimen jaringan untuk peninjauan ini. Pemeriksaan model offline baru dicatat secara terpisah.
Pos pemeriksaan yang dipertahankan mencatat permintaan DNS-over-TCP aktual terhadap server loopback minimalnya sendiri. Contoh yang diizinkan.test AXFR mengembalikan framing SOA yang cocok dan kebijakan TXT puncak v=spf1 -all ; kueri untuk zona other.test di luar cakupan mengembalikan REFUSED. Kueri UDP TXT terpisah mengambil kebijakan SPF yang sama. Ini memberi nama ketergantungan spesifik: evaluator SPF memerlukan kebijakan TXT yang dipilih pada domain envelope, sementara AXFR mengekspos inventaris yang lebih luas tanpa mengubahnya. Byte kabel kueri dan respons, titik akhir, dan waktu UTC dipertahankan. Server sengaja menggunakan daftar zona yang diizinkan sederhana, bukan autentikasi produksi atau implementasi AXFR yang lengkap.