[ DNS & domain ]

Verifikasi catatan otentikasi dengan Windows nslookup

Periksa dependensi SPF , DKIM , dan DMARC dengan Windows nslookup. Gunakan pertanyaan eksplisit dan pertahankan konteks respons agar penyerahan dukungan bermanfaat.

Oleh tim peneliti EmailAuth · 6 menit membaca

[Poin-poin penting]

  • Sintaks cakupan untuk dokumentasi Windows 11 dan Windows Server 2025.
  • Gunakan nama absolut dan server eksplisit jika reproduktifitas penting.
  • Bedakan pengaturan interaktif dari data DNS yang diperiksa.
  • Pertahankan kategori kesalahan dan batas rekaman asli.
Di halaman ini

Gunakan alat DNS Windows tanpa mengubah DNS

Windows nslookup dapat membantu operator dukungan memeriksa dependensi autentikasi tanpa membuka panel kontrol DNS . Output yang berguna adalah jawaban yang dapat diatribusikan pada nama dan tipe rekaman tertentu. Tangkapan layar yang berisi nama domain yang familier saja tidak cukup. Catat server, pertanyaan dan waktunya, lalu jelaskan bagaimana pengamatan tersebut berhubungan dengan identitas email yang sedang diselidiki.

Panduan ini tercakup dalam dokumentasi nslookup Microsoft untuk Windows 11 dan Windows Server 2025, yang ditinjau pada 8 November 2026. Panduan ini tidak mengklaim mencakup perilaku implementasi Unix dengan nama perintah yang sama. Semua contoh adalah permintaan DNS read-only yang diusulkan; tidak ada yang dijalankan untuk artikel ini. Alamat dokumentasi dan nama example.com harus diganti hanya dalam penyelidikan yang disetujui.

Pilih nama pemilik sebelum perintah

Mintalah konfigurasi pesan atau pengirim yang tepat yang mengidentifikasi ketergantungan. SPF biasanya menyangkut identitas SMTP yang mungkin berbeda dari alamat Dari yang terlihat. DKIM menggunakan pemilih dan menandatangani domain di tanda tangan untuk menemukan kuncinya. Mencari example.com TXT tidak memeriksa setiap kemungkinan pemilih di bawahnya. RFC 7208 RFC 6376

Untuk pemeriksaan kebijakan, _dmarc.example.com. adalah pemilik yang jelas untuk diselidiki, bukan bukti bahwa ini adalah satu-satunya permintaan penemuan kebijakan yang mungkin diperlukan oleh verifikator. Simpan penemuan otentikasi dan penyelarasan kesimpulan dengan pemilik surat. Tiket dukungan dapat melaporkan jawaban DNS secara akurat tanpa mendeklarasikan a DMARC lulus. RFC 9989

Akhiri nama yang diusulkan dengan tanda titik. Dokumentasi Microsoft menjelaskan bahwa nama tanpa terminator tersebut dapat dipengaruhi oleh pengaturan domain dan pencarian. Hal ini sangat relevan pada sistem Windows perusahaan, di mana konfigurasi sufiks dapat membuat pertanyaan yang tidak diinginkan tampak masuk akal. Pertahankan ejaan yang tepat daripada mengetik ulang dari ingatan. Microsoft nslookup

Lebih suka satu permintaan eksplisit untuk sebuah tiket

Kueri satu kali yang diusulkan adalah nslookup - type=TXT _dmarc.example.com . 192.0.2.53. Argumen terakhir menyebutkan nama server DNS ; menghilangkannya menggunakan server default. Alamat di sini adalah pengganti dokumentasi, bukan rekomendasi yang dapat digunakan. Pertanyaan DKIM yang cocok bisa jadi nslookup - type=TXT selector1._domainkey.example.com . 192.0.2.53, setelah memperoleh pemilih sebenarnya dari bukti yang sah. Microsoft nslookup

Catat stempel waktu UTC secara terpisah, edisi dan versi Windows, serta konteks jaringan aktif. Sertakan seluruh hasil, bukan hanya nilai teks. Jika perubahan VPN atau adaptor terjadi di antara pengamatan, catatlah; pertanyaan tersebut mungkin mengikuti jalur yang berbeda. Bagikan hanya bagian konfigurasi jaringan yang relevan, karena paket dukungan yang luas dapat mengungkapkan nama dan alamat internal yang tidak terkait.

Menggunakan nslookup - type=NS example.com . 192.0.2.53 sebagai pertanyaan yang diajukan tentang server nama catatan. Perlakukan hasilnya sebagai salah satu masukan untuk mengidentifikasi otoritas, bukan bukti bahwa server rekursif yang dipilih adalah otoritatif. Alamat yang diperoleh dari tangkapan layar yang belum diverifikasi tidak boleh menjadi tujuan kueri berikutnya tanpa memeriksa domain dan sumbernya.

Gunakan mode interaktif ketika diperlukan detail ekstra

Untuk penyelidikan yang disetujui yang memerlukan beberapa pertanyaan terkait, entri yang diusulkan adalah nslookup - 192.0.2.53. Pada prompt interaktif, masukkan atur type=TXT, Kemudian atur debug, Kemudian _dmarc.example.com., dan akhirnya KELUAR. Masing-masing adalah masukan terpisah. Instruksi ini bukan keluaran dan tidak menggambarkan sesi yang dijalankan. Microsoft mendokumentasikan pengaturan tipe dan mode debug secara terpisah. Tipe set Microsoft Microsoft mengatur debug

Mode debug memberikan lebih banyak detail paket dan respons untuk interpretasi. Itu tidak mengubah zona atau mengesahkan jawabannya. Pertahankan status respons, tanda, TTL, dan informasi otoritas apa pun yang diberikan oleh keluaran aktual. Jika bukti tidak cukup untuk a DNSSEC atau kesimpulan delegasi, mintalah gambaran diagnostik yang lebih sesuai daripada mengisi kesenjangan dari harapan.

Atur ulang pertanyaan dengan sengaja saat mengubah jenis rekaman. Kesalahan dukungan yang umum adalah melanjutkan sesi interaktif dengan asumsi pengaturan sebelumnya tidak lagi berlaku. Lebih memilih perintah sekali pakai yang baru ketika tiket memerlukan contoh yang dapat direproduksi yang dapat dipahami oleh operator lain tanpa merekonstruksi riwayat sesi.

Menafsirkan label dan kegagalan dalam konteks

Jawaban yang tidak otoritatif tidak serta merta salah. Ini bisa berupa respons rekursif normal yang berisi data cache. Respons otoritatif memberikan sudut pandang yang berbeda, bukan hasil autentikasi ujung ke ujung. Bidang otoritas dan status header DNS menjelaskan respons, dan maknanya harus tetap berbeda dari teks TXT yang dikembalikan. RFC 1035

Microsoft membedakan batas waktu, tidak ada catatan untuk jenis yang dipilih, tidak ada domain dan kegagalan server. Pisahkan kategori-kategori tersebut dalam insiden tersebut. Batas waktu memerlukan penyelidikan terhadap keterjangkauan dan respons server, bukan pembuatan segera a catatan TXT. Hasil tanpa catatan memerlukan pemeriksaan pemilik dan jenis sebenarnya sebelum mempertimbangkan perubahan. Microsoft nslookup

Jika pemilih adalah a CNAME, pertahankan alias dan selidiki targetnya di bawah cakupan pemilik yang tepat. Jika teks TXT dibagi menjadi string yang dikutip, pertahankan batas rekaman aslinya. String yang ditempelkan dan secara diam-diam menggabungkan catatan sumber daya terpisah dapat menyembunyikan kesalahan konfigurasi atau membuatnya. RFC 1035

Akhiri dengan perbandingan dan penyerahan yang jujur

Temuan dukungan fiktif mungkin mengatakan bahwa server rekursif perusahaan dan otoritas terverifikasi mengembalikan nilai yang berbeda untuk pemilik TXT yang sama pada waktu yang tercatat. Itu mendukung cache lebih lanjut atau melihat penyelidikan. Ini tidak menentukan nilai kotak surat jarak jauh yang digunakan, dan tidak membenarkan pengeditan zona tanpa peninjauan pemilik DNS .

Pisahkan nslookup dari pemeliharaan cache. Pencarian bukanlah pembersihan cache lokal; Utilitas ipconfig Microsoft yang terpisah mendokumentasikan operasi itu. Jangan menambahkan perintah modifikasi ke investigasi read-only hanya karena hasilnya tidak nyaman. Microsoft ipconfig

Tiket yang sudah jadi harus mencakup pertanyaan yang tepat, tanggapan aktual, stempel waktu, identitas, dan pertanyaan lainnya. Di sini observasi operasional tersebut tidak ada, sehingga bukti publikasi masih belum lengkap. Sintaks yang diperiksa berdasarkan dokumentasi merupakan persiapan yang berguna, namun hanya tangkapan nyata yang diotorisasi yang dapat memenuhi gerbang kueri asli.

[ Membawa pergi ]

Pilih identitas autentikasi yang tepat terlebih dahulu, lalu catat pertanyaan DNS dan server yang tepat. Pencarian tidak mengubah DNS atau membuktikan pesan telah disampaikan.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Meja layanan Windows

Buat catatan dukungan yang dapat direproduksi

Meja layanan dapat mengurangi waktu eskalasi dengan mengirimkan pertanyaan yang tepat dan observasi lengkap, bukan tangkapan layar tanpa label. Jauhkan data adaptor dan jaringan internal yang tidak terkait dari tiket umum.

Langkah selanjutnya

  1. Catat versi Windows, waktu UTC, dan konteks jaringan aktif.
  2. Gunakan pemilik dan jenis persisnya yang disediakan oleh investigasi surat.
  3. Sertakan server tujuan dan respons lengkap yang relevan.

administrator DNS

Verifikasi otoritas dan struktur catatan

Pemilik DNS harus memutuskan apakah respons mencerminkan publikasi, cache, atau tampilan lain. Pencarian dukungan tidak mengizinkan pengeditan rekaman secara langsung.

Langkah selanjutnya

  1. Verifikasi tujuan resmi secara mandiri.
  2. Bandingkan nama dan jenis yang sama di berbagai sudut pandang yang dipilih.
  3. Pertahankan alias dan batas data TXT selama peninjauan.

Pimpinan dukungan email

Terjemahkan bukti DNS menjadi klaim terbatas

Pencarian yang berfungsi membantu mengidentifikasi ketergantungan tetapi tidak menyelesaikan keselarasan atau perilaku penerima. Jelaskan perbedaannya kepada pemilik kejadian tanpa kehilangan hasil yang bermanfaat.

Langkah selanjutnya

  1. Hubungkan setiap pencarian ke domain SMTP , tanda tangan, atau pemilik kebijakan.
  2. Pisahkan data yang hilang dari batas waktu dan kegagalan server.
  3. Minta bukti tingkat pesan sebelum menyatakan autentikasi telah diperbaiki.

[ FAQ ]

Pertanyaan yang sering diajukan

Bisakah saya menggunakan panduan ini untuk perintah Unix nslookup?

Sintaks dan perilaku yang terdokumentasi di sini mencakup Windows 11 dan Windows Server 2025. Periksa manual untuk implementasi sebenarnya sebelum mentransfer perintah atau menafsirkan konvensi tampilannya. Nama alat yang identik tidak menjamin perilaku yang sama.

Mengapa nama kueri diakhiri dengan titik?

Titik membuat nama yang dimaksud menjadi mutlak. Pencarian dokumen Microsoft dan pengaturan domain yang dapat memengaruhi nama tanpanya. Menjaga ejaan kueri yang tepat membantu mencegah akhiran perusahaan membingungkan penyelidikan.

Bagaimana cara meminta TXT alih-alih catatan alamat?

Gunakan opsi tipe yang terdokumentasi dalam kueri sekali pakai, atau setel type=TXT dalam sesi interaktif. Jaga agar jenis yang dipilih tetap terlihat di tiket; jawaban alamat bukan bukti tentang otentikasi data TXT .

Apakah jawaban yang tidak otoritatif merupakan tes yang gagal?

Belum tentu. Server rekursif biasanya memberikan jawaban tanpa mengklaim otoritas untuk zona tersebut. Bandingkan hasilnya dengan otoritas terverifikasi bila diperlukan, dengan tetap memperhatikan waktu cache dan status respons. Labelnya saja tidak menyatakan apakah nilainya benar.

Apa yang ditambahkan mode debug?

Microsoft mendokumentasikan informasi tambahan tentang paket yang dikirim dan jawaban yang dihasilkan. Gunakan ketika keluaran biasa tidak memiliki konteks, dan pertahankan tampilan sebenarnya. Itu tidak menyebarkan catatan, melakukan validasi DNSSEC lengkap atau membuktikan pengiriman email.

Haruskah batas waktu diperbaiki dengan membuat data TXT lain?

Tidak. Batas waktu berarti respons yang diharapkan tidak muncul sesuai dengan perilaku pengaturan waktu alat. Selidiki tujuan, keterjangkauan, dan respons server sebelum mempertimbangkan perubahan publikasi. Menambahkan catatan tidak menentukan mengapa waktu kueri habis.

Bisakah saya menggabungkan setiap segmen TXT yang dikutip menjadi satu nilai?

Hanya setelah mempertahankan batas-batas catatan sumber daya. Beberapa string dalam satu data TXT berbeda dengan beberapa data TXT . Pertahankan keluaran asli dengan nilai yang diinterpretasikan sehingga peninjau dapat memeriksa transformasinya.

Apakah nslookup menghapus cache DNS lokal?

Tidak ada langkah pembersihan cache yang disertakan dalam panduan ini. Dokumen Windows yang beroperasi secara terpisah melalui ipconfig. Pertanyaan DNS read-only tidak boleh diperluas secara diam-diam menjadi prosedur pemecahan masalah lokal yang memodifikasi.

[ Sumber ]

Sumber

  1. Microsoft nslookup mengatur debug
  2. Ipconfig Microsoft Windows
  3. Pencarian Microsoft Windows
  4. Jenis kumpulan Microsoft nslookup
  5. RFC 1034 : Nama domain: konsep dan fasilitas
  6. RFC 1035 : Nama domain: implementasi dan spesifikasi
  7. RFC 6376 : Tanda Tangan Email yang Diidentifikasi DomainKeys
  8. RFC 7208 : Kerangka Kebijakan Pengirim untuk Otorisasi Penggunaan Domain di Email
  9. RFC 9989 : Otentikasi, Pelaporan, dan Kesesuaian Pesan Berbasis Domain

[ Glosarium ]

Glosarium

Kueri noninteraktif
Pemanggilan nslookup satu kali yang argumennya menyatakan pertanyaan dan secara opsional server DNS .
Sesi interaktif
Prompt nslookup yang berkelanjutan di mana pengaturan kueri tetap ada hingga diubah atau sesi berakhir.
Modus debug
Pengaturan nslookup yang memaparkan informasi lebih lanjut tentang paket permintaan dan jawaban yang dihasilkan.
Akhiran pencarian
Komponen domain yang mengonfigurasi perilaku pencarian nama dapat ditambahkan ke nama yang tidak absolut.
Jawaban tidak otoritatif
Respons yang tidak mengklaim bahwa server yang merespons adalah otoritatif untuk nama yang ditanyakan; itu masih dapat berisi data rekursif yang berguna.

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