Pertahankan struktur DNS sebelum menafsirkan teks
Pemeriksa DNS TXT harus menunjukkan catatan sumber daya mana yang dikembalikan, bagaimana string karakter setiap catatan disusun dan server mana yang menyediakan jawabannya. Meratakan semua teks yang ditampilkan ke dalam satu baris dapat menghapus perbedaan antara satu rekaman panjang dan beberapa rekaman yang bersaing. Perbedaan tersebut penting untuk kebijakan autentikasi, token verifikasi, dan aplikasi berbasis TXT lainnya. Tugas pertama inspektur adalah mengamati dengan setia, bukan memberi label izin umum.
RFC 1035 mendefinisikan format TXT RDATA sebagai satu atau lebih string karakter. Ini adalah struktur DNS , terpisah dari makna yang diberikan protokol tingkat tinggi pada teks. Artikel ini mengusulkan persyaratan penerimaan alat dan tidak mengklaim bahwa EmailAuth menyediakan inspektur yang berfungsi. Tidak ada kueri domain pengguna, perubahan penyelesai, atau modifikasi DNS yang dilakukan.
Tampilkan catatan dan string sebagai batas yang berbeda
Tampilkan setiap data sumber daya TXT yang dikembalikan sebagai item terpisah. Di dalamnya, pertahankan urutan karakter-string dan berikan nilai rekonstruksi yang diberi label jelas jika protokol yang menggunakannya membutuhkannya. String karakter berformat kawat memiliki batasan panjang, sehingga data aplikasi yang panjang dapat direpresentasikan menggunakan beberapa string dalam satu record. Itu tidak menciptakan banyak independen SPF atau DMARC kebijakan.
Kutipan dan pelolosan presentasi bisa menjadi bagian dari format tampilan alat, bukan nilai yang disimpan. Seorang inspektur yang berguna harus menjelaskan cara penyajiannya dan menyimpan bukti mentah untuk ditinjau. Jangan beritahu pengguna untuk menghapus setiap tanda kutip hanya karena konsol DNS menampilkan tanda kutip, atau untuk menggabungkan catatan terpisah hanya karena teksnya terlihat terkait. Protokol aplikasi menentukan bagaimana nilai yang direkonstruksi diinterpretasikan setelah batas DNS dipertahankan.
Catat sumber pertanyaan dan jawaban yang tepat
Pertahankan nama pemilik yang sepenuhnya memenuhi syarat, jenis kueri, kelas, penyelesai atau server, transportasi jika relevan, stempel waktu, dan status respons. Kueri untuk puncak zona bukan kueri untuk a pemilih atau pemilik polis di bawahnya. Alat tersebut harus menampilkan nama persis yang ditanyakan, termasuk bagaimana masukan relatif diperluas, sehingga akhiran duplikat atau subdomain yang salah akan terlihat.
RFC 1035 mendefinisikan bidang pesan DNS dan catatan sumber daya, termasuk TTL dan tanda respons. Pemeriksa harus mempertahankan kode respons dan konteks otoritas alih-alih hanya mengekstraksi teks dari jawaban yang tampak berhasil. Batas waktu jaringan, kesalahan server, dan jawaban yang tidak berisi data TXT merupakan pengamatan yang berbeda dan memerlukan penjelasan yang berbeda.
Bedakan observasi otoritatif dan observasi rekursif
Server otoritatif menjawab zonanya, sementara penyelesai rekursif dapat menyediakan data cache atau mengikuti rantai resolusi. Seorang pemeriksa harus mengidentifikasi jenis bukti yang dikumpulkannya daripada memberi label pada setiap jawaban yang otoritatif. Jika ia menemukan dan menanyakan server resmi, pertahankan jalur penemuan dan server sebenarnya yang dihubungi. Jika hanya menggunakan penyelesai rekursif yang dikonfigurasi, nyatakan batasan tersebut.
Kedua perspektif tersebut dapat berbeda pendapat karena waktu, status cache, masalah delegasi, atau data otoritatif yang tidak konsisten. Pertahankan perbedaan pendapat daripada diam-diam memilih jawaban mana yang sesuai dengan kebijakan yang diharapkan. TTL yang ditampilkan dalam respons rekursif mungkin mencerminkan sisa masa pakai cache, bukan nilai konfigurasi asli. Alat tersebut harus menjelaskan pengamatan tersebut tanpa mengklaim bahwa semua penyelesai di seluruh dunia sudah melihat keadaan yang sama.
Jaga agar jawaban negatif dan kegagalan tetap berbeda
Respons kesalahan nama berbeda dengan respons sukses tanpa rekaman jenis yang diminta. Keduanya berbeda dari batas waktu atau kegagalan server. Pemeriksa harus menyimpan kode respons dan informasi otoritas yang relevan dan menghindari mengubah setiap hasil kosong menjadi “catatan hilang.” Apabila perusahaan tidak dapat menentukan penyebabnya, perusahaan harus melaporkan ketidakpastian daripada menebak bahwa domain tersebut tidak ada.
DNSSEC validasi adalah dimensi terpisah lainnya. RFC 4033 menggambarkan keadaan aman, tidak aman, palsu dan tidak menentu. Jawaban TXT dapat terlihat tanpa sumber yang tervalidasi dengan aman, dan kegagalan validasi tidak boleh dianggap sebagai respons kosong biasa. Jika alat tersebut melaporkan validasi, alat tersebut harus mendokumentasikan konteks kepercayaan penyelesai dan bukti aktual yang didukung, bukan berasumsi bahwa satu tanda saja sudah cukup secara universal.
Pisahkan pemeriksaan DNS dari validasi protokol
Seorang inspektur dapat menunjukkan banyak hal catatan TXT tanpa memutuskan bahwa seluruh nama pemilik tidak valid. Catatan aplikasi yang berbeda dapat hidup berdampingan secara sah. RFC 7208 mendefinisikan bagaimana SPF memilih datanya dan menangani beberapa kebijakan SPF . RFC 9989 mendefinisikan format dan penemuan kebijakan DMARC . Itu adalah interpretasi khusus protokol yang diterapkan setelah mengamati kumpulan data DNS .
Oleh karena itu, suatu alat harus membedakan keluaran DNS mentah dari SPF opsional, DMARC , atau interpretasi lainnya. Teks verifikasi yang tidak terkait tidak secara otomatis merupakan kebijakan autentikasi duplikat. Sebaliknya, beberapa catatan kebijakan yang relevan tidak boleh digabungkan secara diam-diam menjadi satu string yang tampak valid. Pertahankan kandidat terpilih dan aturan yang digunakan untuk menafsirkannya, dengan versi protokol dan parser terlihat.
Perhitungkan konvensi editor penyedia dengan cermat
Dokumentasi catatan Azure DNS menjelaskan model kumpulan rekor dan penanganan string TXT . Ini adalah contoh penyedia resmi, bukan aturan editor universal. Seorang pengguna dapat memasukkan label relatif di satu antarmuka dan nama yang sepenuhnya memenuhi syarat di antarmuka lain. Pemeriksa harus melaporkan pemilik dan byte yang dipublikasikan, sementara saran pengeditan apa pun tetap tercakup dalam format masukan yang didukung penyedia sebenarnya.
Jangan menyimpulkan publikasi hanya dari tangkapan layar editor. Formulir yang tampak disimpan dapat mewakili konfigurasi yang diinginkan tanpa membuktikan bahwa server resmi menerbitkannya. Alur kerja yang diusulkan membandingkan referensi konfigurasi resmi dengan observasi aktual, dengan tetap menjaga stempel waktu dan sumber. Tidak ada konsol penyedia yang diakses untuk artikel ini, dan tidak ada rekaman tersimpan atau perubahan yang disebarkan yang diklaim.
Lembar kerja perlengkapan hasil yang diharapkan
Buat lembar kerja dengan masukan asli, nama kueri yang diperluas, pilihan server, batas rekaman yang diharapkan, kategori respons yang diharapkan, dan referensi observasi aktual. Menyertakan perlengkapan untuk satu data TXT dengan beberapa string, beberapa data TXT independen, teks protokol yang tidak terkait dan relevan, kesalahan nama, tidak ada data, dan DNS tidak tersedia. Tambahkan kasus perselisihan yang otoritatif dan rekursif di mana lingkungan yang terkendali dapat menghasilkan perselisihan tersebut dengan aman.
Catat versi alat, waktu observasi, transkrip mentah dan penjelasan setiap kesalahan. Gunakan nama sintetis di lingkungan perlengkapan yang terisolasi daripada menanyakan domain pelanggan tanpa persetujuan. Hasil yang diharapkan dan hasil yang diamati harus tetap terpisah. Sebuah alat tidak berfungsi hanya karena contoh statis telah ditulis; Katalog ini memerlukan masukan dan observasi aktual yang disimpan, yang tidak disediakan oleh draf ini.
Diagnosis fiktif: dua kebijakan ditampilkan sebagai satu
Seorang inspektur fiksi menggabungkan setiap string TXT dan merekam ke dalam satu baris. Pengguna melihat apa yang tampak sebagai satu kebijakan autentikasi yang panjang, meskipun jawaban yang mendasarinya berisi dua catatan kebijakan terpisah. Tes penerimaan yang diusulkan akan mempertahankan jawaban mentah dan mengharuskan antarmuka untuk menampilkan setiap catatan secara terpisah sebelum interpretasi protokol apa pun. Masalah tampilan dapat menyembunyikan kesalahan pemilihan kebijakan yang sebenarnya.
Tim akan memperbaiki representasi alat dan mengevaluasi catatan aktual berdasarkan protokol yang relevan sebelum mengusulkan perubahan DNS . Itu tidak akan menggabungkan atau menghapus catatan produksi secara otomatis. Skenario ini fiktif: tidak ada kerusakan alat yang teramati, tidak ada perlengkapan yang dijalankan, dan tidak ada catatan yang diubah. Ini menggambarkan bagaimana struktur yang setia merupakan prasyarat untuk nasihat yang dapat dipercaya.
Rilis hanya dengan jejak bukti yang berfungsi
Katalog memerlukan alat yang berfungsi dengan perlengkapan hasil yang diharapkan, masukan asli, waktu pengamatan dan kesalahan yang dapat dijelaskan. Bukti asli itu masih terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Naskah ini memberikan desain penerimaan dan diagnosis fiktif, bukan inspektur yang bekerja atau observasi DNS yang dilaksanakan. Contoh yang dapat dipublikasikan harus menunjukkan batasan yang dijelaskannya dan dengan jelas memisahkan fakta DNS mentah dari kesimpulan protokol.