[ DNS & domain ]

Jawaban DNS otoritatif dan rekursif dibandingkan

Bedakan jawaban otoritatif suatu zona dari jawaban penyelesai sehingga ketidaksepakatan DNS mengarah pada penyelidikan autentikasi yang tepat.

Oleh tim peneliti EmailAuth · 6 menit membaca

[Poin-poin penting]

  • Observasi otoritatif langsung dan observasi rekursif menjawab pertanyaan yang berbeda.
  • RD dan RA tidak menunjukkan bahwa suatu respons baru saja diselesaikan.
  • Nama, titik akhir, waktu, bendera, dan transportasi yang konsisten membuat perbandingan menjadi berguna.
Di halaman ini

Tanyakan siapa yang menghasilkan jawabannya

Dua pencarian DNS bisa berbeda pendapat tanpa salah satu alatnya rusak. Seseorang mungkin bertanya kepada server resmi tentang data terkini zona tersebut; yang lain mungkin menanyakan penyelesai rekursif yang memiliki jawaban sebelumnya. Investigasi autentikasi yang berguna mencatat jalur mana yang menghasilkan setiap observasi alih-alih memperlakukan tanda centang hijau dari situs pencarian mana pun sebagai status akhir domain.

Server otoritatif menjawab dari zona yang dilayaninya. Resolver rekursif bekerja atas nama klien, berkonsultasi dengan server lain atau menggunakan kembali informasi cache. Penyelesai rintisan umumnya meneruskan pertanyaan ke layanan rekursif. Perangkat lunak yang sama dapat menjalankan lebih dari satu peran, jadi kenali peran respons khusus ini daripada mengandalkan nama produk. RFC 1034 , bagian 4.3.1 dan 5.3.1.

Pembedaan ini penting bila baru diterbitkan pemilih DKIM muncul di alat host DNS tetapi tetap tidak tersedia untuk pemverifikasi. Otoritas dapat menentukan apa yang saat ini dilayani oleh server; hasil rekursif membantu menjelaskan apa yang mungkin dilihat oleh jalur penerima. Tidak ada observasi yang menggantikan observasi lainnya.

Tetapkan delegasi sebelum memilih titik akhir

Mulailah dengan pemilik sebenarnya dan ketik yang terkait dengan pesan atau instruksi layanan. Ikuti delegasi ke zona yang bertanggung jawab atas pemilik tersebut. Zona anak dapat memiliki server otoritatif yang berbeda dari induknya, dan alias penyedia dapat mengarah ke zona yang berbeda lagi. Host DNS yang ditampilkan pada tiket lama mungkin bukan lagi host yang didelegasikan. RFC 1034 , bagian 4.2.1–4.2.2.

Siapkan daftar nama server resmi dan alamatnya, lalu tanyakan langsung server yang relevan. Simpan alamat mana yang dihubungi. Jika otoritas yang berbeda mengembalikan catatan yang berbeda, selidiki masalah publikasi DNS atau penyajian zona terlebih dahulu. Seorang penyelesai dapat secara sah menghadapi otoritas apa pun yang tersedia; memilih server dengan jawaban yang diinginkan tidak menyelesaikan ketidakkonsistenan.

Pelacakan dapat membantu memeriksa jalur delegasi, namun ini merupakan observasi terpisah. Itu tidak mereproduksi jalur cache penerima, konfigurasi penerusan, jaringan sumber atau DNSSEC perilaku validasi. Beri label jejak sebagai jejak, bukan menampilkannya sebagai riwayat kueri penyedia email.

Tafsirkan bendera beserta batasannya

Bendera AA mengidentifikasi jawaban otoritatif dalam respons DNS . RD mencatat bahwa rekursi diminta; RA mengiklankan ketersediaan rekursi. RD dan RA tidak membuktikan bahwa server melakukan pencarian baru untuk respons ini. Server rekursif dapat memenuhi permintaan dari cache. RFC 1035 , bagian 4.1.1.

Untuk pemeriksaan otoritas langsung, jangan minta rekursi dan periksa balasan sebenarnya. Respons tanpa AA, rujukan, DITOLAK, atau batas waktu memerlukan interpretasi; alamat server saja tidak membuat setiap balasan menjadi resmi. Jika alias muncul, jaga agar setiap pemilik dan target tetap terlihat dan identifikasi zona mana yang menyediakan data akhir. Kewenangan terhadap pemilik alias tidak serta merta membentuk kewenangan terhadap sasarannya.

Simpan bagian pertanyaan, jawaban, dan otoritas secara lengkap. Perintah yang hanya mencetak string TXT menyembunyikan konteks yang diperlukan untuk membedakan data cache lama, rujukan, alias, dan respons ketidakhadiran. Output pendek berguna untuk membaca cepat setelah catatan diagnostik lengkap disimpan.

Bandingkan sepasang pengamatan penyelesai fiksi

Bayangkan seorang pemilih fiksi blue._domainkey.example.com. Pada pukul 10:00 UTC, dua server otoritatif yang relevan mengembalikan rekaman kunci publik yang baru dimaksudkan. Pada 10:02, Resolver A mengembalikan kunci lama dengan sisa waktu 420 detik, sedangkan Resolver B mengembalikan kunci baru. Saat ini, hasil dan TTL diciptakan untuk menggambarkan penalaran; tidak ada pengukuran jaringan yang dilakukan.

Pola tersebut konsisten dengan riwayat cache yang berbeda, namun observasi saja tidak membuktikan penyebabnya. Periksa apakah semua pertanyaan menggunakan nama, jenis, dan kelas yang sama, bahwa titik akhir server dicatat, dan tidak ada tampilan terpisah atau kebijakan penerusan yang mengubah jawabannya. Jika Resolver A kemudian di-refresh dari otoritas yang tidak konsisten, menunggu saja mungkin tidak menyelesaikan masalah.

Catatan insiden yang diusulkan akan menyatakan: “Pihak berwenang yang dijadikan sampel menyetujui kunci baru; Resolver A masih mengembalikan kunci lama; hasil penerima belum diamati.” Ini tidak menyatakan bahwa setiap penerima diperbarui atau otentikasi sekarang lolos. Jaga ketersediaan kunci publik lama dan transisi penandatanganan pengirim di bawah rencana rotasi yang terkoordinasi daripada menghapus catatan untuk membuat layar pencarian terlihat rapi.

Pisahkan masalah data dari masalah keterjangkauan

SERVFAIL rekursif tidak menetapkan hal itu sebuah rekor tidak ada. Otoritas mungkin tidak dapat dijangkau, delegasi mungkin gagal, atau validasi DNSSEC mungkin menghalangi penyelesai untuk menerima jawabannya. Jawaban langsung dari satu server mempersempit penyelidikan namun tidak membuktikan bahwa semua dependensi sehat untuk penyelesai rekursif.

Transportasi juga penting. DNS memerlukan dukungan TCP, dan respons UDP yang terpotong mungkin memerlukan percobaan ulang TCP. Bandingkan yang diusulkan gali @AUTH_IP blue._domainkey.example.com . TXT +tidak ada kutukan dengan kueri yang sama menggunakan +tcp ketika transportasi terlibat. Jangan mengubah pengaturan firewall atau keamanan hanya agar tes tersebut lulus; mintalah operator yang bertanggung jawab meninjau jalur yang didiagnosis. RFC 7766 , bagian 5–6.

Jadikan perbandingannya dapat direproduksi

Gunakan satu baris lembar kerja per kueri: stempel waktu UTC, lokasi operator, titik akhir server, pilihan rekursi, pemilik, jenis, kelas, kode respons, bendera, catatan, TTL, dan transportasi. Ulangi pengamatan yang dipilih pada interval yang terdokumentasi dan pertahankan baris sebelumnya. Cache DNS berevolusi, jadi menimpa hasil pertama menghilangkan bukti waktu yang berguna.

Selesaikan dengan pesan terkontrol melalui pengirim yang terpengaruh dan simpan identitas serta hasil penerima tepercaya. Perbandingan DNS dapat menjelaskan ketergantungan; itu tidak dapat menunjukkan penempatan kotak masuk atau pencarian internal penerima tertentu. Artikel ini memberikan alur kerja yang diusulkan dan perbandingan fiksi. Jawaban otoritatif dan rekursif dengan stempel waktu asli tetap diperlukan sebelum gerbang bukti katalognya dapat ditutup.

[ Membawa pergi ]

Identifikasi peran server dan selesaikan konteks kueri sebelum menafsirkan dua jawaban DNS yang berbeda.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Operator DNS

Pisahkan otoritas yang tidak konsisten dari cache

Resolver hanya dapat mengambil data dan jangkauan yang ditawarkan oleh jalur DNS yang ditemuinya.

Langkah selanjutnya

  1. Bandingkan titik akhir otoritatif yang relevan dengan rekursi yang dinonaktifkan.
  2. Tingkatkan jawaban zona yang berbeda sebelum menyatakan penyelesai sudah basi.

Insinyur dukungan perpesanan

Pertahankan jalur yang menghadap penerima

Situs pencarian publik tidak dapat mengungkapkan riwayat pencarian internal penerima yang terpengaruh.

Langkah selanjutnya

  1. Catat pemilih dan domain penandatanganan yang tepat dari pesan yang terpengaruh.
  2. Beri label pada setiap titik akhir rekursif dan pertahankan hasil lengkapnya.

Koordinator insiden

Tulis kesimpulan pada skala bukti

Insiden ini memerlukan pernyataan terbatas tentang jalur sampel, bukan klaim propagasi global.

Langkah selanjutnya

  1. Nyatakan otoritas dan penyelesai mana yang diperiksa dan kapan.
  2. Pertahankan pemulihan DNS dan verifikasi pesan yang berhasil sebagai pencapaian terpisah.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah jawaban rekursif selalu berasal dari cache?

Tidak. Resolver dapat menggunakan data cache atau melakukan penyelesaian. Peran dan tanda rekursinya tidak dengan sendirinya mengungkapkan seberapa baru mereka menghubungi pihak berwenang.

Apa yang AA katakan kepada saya dalam respons server langsung?

AA menandai jawaban yang berwibawa. Periksa respons aktual dan konteks alias daripada berasumsi bahwa titik akhir berwenang untuk setiap nama yang Anda kirimkan.

Apakah RA berarti penyelesai baru saja mengambil kunci DKIM saya?

Tidak. RA menunjukkan rekursi tersedia; RD mencatat permintaan rekursi. Tidak ada bendera yang merupakan tanda terima kesegaran.

Mengapa menanyakan lebih dari satu server otoritatif?

Server yang berbeda mungkin menyajikan data yang tidak konsisten atau berbeda dalam jangkauannya. Penyelesai rekursif mungkin menghadapi otoritas lain, sehingga satu jawaban yang diinginkan tidak menyelesaikan perselisihan.

Bisakah dig +trace mereproduksi pencarian penerima email?

Tidak. Jejak memeriksa jalur delegasi dari lingkungannya sendiri. Itu tidak merekonstruksi cache penerima, aturan penerusan, jaringan atau perilaku validasi.

Mengapa server nama zona induk mungkin menjadi server yang salah untuk ditanyakan?

Pemilik yang diminta mungkin berada di dalam zona anak yang didelegasikan secara terpisah. Alias ​​juga dapat melakukan pencarian ke target di zona lain.

Apa yang dibuktikan oleh jawaban positif langsung ditambah SERVFAIL rekursif?

Hal ini menunjukkan bahwa otoritas sampel menyediakan data sementara jalur rekursif tersebut gagal. Hal ini tidak mengidentifikasi penyebab unik atau menetapkan bahwa validasi dan otoritas lainnya adalah hal yang sehat.

Kapan perbandingan TCP bermanfaat?

Ketika pemotongan atau keterjangkauan transportasi terlibat. Ulangi nama, tipe dan server yang sama dengan TCP dan pertahankan kedua hasil; Dukungan TCP adalah bagian dari persyaratan DNS .

[ Sumber ]

Sumber

  1. RFC 1034 : Nama domain: konsep dan fasilitas
  2. RFC 1035 : Nama domain: implementasi dan spesifikasi
  3. RFC 7766 : Transportasi DNS melalui TCP: Persyaratan Implementasi

[ Glosarium ]

Glosarium

Server resmi
Server DNS yang menyajikan data untuk zona yang memiliki otoritasnya.
Penyelesai rekursif
Layanan yang menyelesaikan pertanyaan klien dengan berkonsultasi dengan server lain atau menggunakan informasi cache.
Penyelesai rintisan
Komponen penyelesai yang biasanya bergantung pada layanan rekursif untuk melakukan penyelesaian atas namanya.
bendera AA
Bendera respons DNS mengidentifikasi jawaban otoritatif, ditafsirkan dalam konteks tanya jawab.
Rujukan
Respons DNS mengarahkan resolusi ke server yang bertanggung jawab atas zona yang didelegasikan, bukan menyediakan data akhir yang diminta.

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan