[ DNS & domain ]

Catatan DNS TXT : kutipan, banyak string, dan batas catatan

Pertahankan perbedaan antara satu data TXT yang berisi beberapa string dan beberapa data TXT independen saat menerbitkan autentikasi email.

Oleh tim peneliti EmailAuth

[Poin-poin penting]

  • Satu data TXT dapat berisi beberapa string karakter yang diurutkan.
  • SPF menggabungkan string tanpa menambahkan spasi dan tidak menggabungkan kebijakan terpisah.
  • Verifikasi byte dan nama pemilik, lalu verifikasi jalur email sebenarnya.
Di halaman ini

Editor DNS dapat menampilkan beberapa fragmen yang dikutip tanpa membuat beberapa catatan. Sebaliknya, dua baris dapat terlihat seperti satu kebijakan bagi seseorang, namun tetap menjadi dua catatan independen bagi penerima. Periksa nilai pasti dan batas rekaman sebelum menyatakan rekaman autentikasi benar.

Baca representasi DNS

Referensi: RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 7208 §3.3.

RFC 1035 mendefinisikan data TXT sebagai satu atau lebih string karakter. Setiap string dibatasi hingga 255 oktet, belum tentu 255 karakter yang ditampilkan. Nilai yang lebih panjang dapat menempati beberapa string dalam satu record. Aplikasi mendefinisikan bagaimana data tersebut diinterpretasikan. Untuk SPF, RFC 7208 secara eksplisit memerlukan penggabungan string di dalamnya sebuah rekor tanpa menyisipkan spasi.

Tanda kutip dalam string pembatas presentasi file zona. Mereka tidak secara otomatis menjadi tanda kutip literal dalam nilai DNS . Formulir penyedia mungkin mengharapkan teks mentah, sintaks file zona yang dikutip, atau daftar string terstruktur. Ikuti format masukan yang terdokumentasi dan periksa jawaban yang dihasilkan daripada menambah atau menghapus tanda kutip hingga layar tampak familier.

Pertahankan ruang dan catatan independen

Referensi: RFC 7208 §4.5.

Jika nilai SPF dipisahkan tepat sebelum mekanisme, pertahankan ruang pemisah di dalam salah satu string. Dua string yang berdekatan berisi v=spf1 Dan ip4:192.0.2.10 -all akan direkonstruksi sebagai urutan token yang tidak valid tanpa spasi itu. Dalam contoh yang salah format ini, awalan yang direkonstruksi adalah v=spf1ip4, yang bukan merupakan token versi SPF yang valid. Jika tidak ada data lain yang dipilih sebagai kebijakan SPF , hasil SPF tidak ada. Pertahankan sintaks aplikasi yang tepat daripada berasumsi setiap konsumen TXT menangani spasi secara sama.

Jangan bergabung secara terpisah catatan TXT hanya karena parser mengembalikannya dalam satu koleksi. Beberapa data TXT yang tidak terkait pada pemilik yang sama adalah hal yang normal. Beberapa catatan yang dipilih sebagai kebijakan SPF pada pemilik tersebut tidak: SPF mengembalikan kesalahan permanen daripada menggabungkan daftar otorisasinya. Pertahankan jawaban lengkap dan aturan pemilihan aplikasi dalam diagnosis.

Mereproduksi tes batas

Perlengkapan zona sintetis A berisi satu catatan: example.com . 300 DALAM TXT " v=spf1 ip4:192.0.2.10" " -all ". Rekonstruksi stringnya secara berurutan tanpa menambahkan byte. Teks SPF yang diharapkan adalah v=spf1 ip4:192.0.2.10 -all. Alamat dokumentasi hanya bersifat ilustratif dan tidak boleh digunakan untuk mengotorisasi pengirim produksi.

Perlengkapan B menggantikan A dengan dua catatan: example.com . 300 DI TXT " v=spf1 ip4:192.0.2.10 -all " Dan example.com . 300 DALAM TXT " v=spf1 ip4:192.0.2.20 -all ". Pemilihan SPF yang diharapkan adalah beberapa catatan kebijakan dan kesalahan permanen. Perlengkapan C mempertahankan A dan menambahkan example.com . 300 DI TXT "verifikasi situs=sintetis"; catatan verifikasi yang tidak terkait bukan merupakan kebijakan SPF tambahan.

Muat setiap perlengkapan secara terpisah di zona pengujian terisolasi. Pertanyaan gali @AUTH example.com . TXT +tidak ada kutukan, menggantikan otoritas lab untuk AUTH. Pertahankan satu objek rekaman sumber daya per rekaman yang dikembalikan dan daftar string yang diurutkannya. Harness yang setia harus membedakan A dari B meskipun tampilannya menampilkan output yang panjang. Ini adalah hasil yang diharapkan, bukan hasil tes langsung yang dilaporkan.

Verifikasi nilai yang dipublikasikan

Bandingkan masukan editor, setiap jawaban otoritatif dan jawaban rekursif. Periksa nama pemilik apakah ada akhiran zona yang berulang secara tidak sengaja. Gunakan perpustakaan DNS yang mempertahankan struktur catatan saat mengotomatiskan pemeriksaan; goresan teks berorientasi garis dapat membingungkan pembungkusan dengan batas rekaman.

Pertahankan nilai dan persetujuan sebelumnya sebelum perubahan produksi. Setelah publikasi, uji jalur email yang relevan dengan konten yang tidak berbahaya dan ambil bukti autentikasi. Sintaks TXT yang benar menetapkan prasyarat DNS ; hal ini tidak membuktikan bahwa suatu layanan menandatangani pesan atau bahwa penerima menerimanya.

Usahakan ruang lingkup bukti tetap eksplisit

Penggabungan string lokal mengonfirmasi bahwa ruang yang dipertahankan menghasilkan v=spf1 ip4:192.0.2.10 -all ; menghilangkannya menghasilkan awalan v=spf1ip4 yang tidak dipilih. Ini adalah ilustrasi teks/pilihan, bukan evaluator SPF yang dijalankan atau kueri DNS langsung.

[ Membawa pergi ]

Satu data TXT dapat berisi beberapa string karakter yang diurutkan. SPF menggabungkan string tanpa menambahkan spasi dan tidak menggabungkan kebijakan terpisah. Verifikasi byte dan nama pemilik, lalu verifikasi jalur email sebenarnya.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Bandingkan byte dan batas catatan

Fragmen string di dalam rekaman dan rekaman terpisah dalam jawaban harus tetap dapat dibedakan.

Langkah selanjutnya

  1. Periksa string yang dipesan dan catat batasnya.
  2. Uji kebijakan duplikat dan perlengkapan string terpisah.
  3. Bandingkan jawaban otoritatif dan rekursif.

CISO / Detik

Lindungi jalur publikasi kebijakan

Kontrol yang berarti adalah data DNS yang diotorisasi dan dapat diverifikasi, bukan tangkapan layar yang meyakinkan.

Langkah selanjutnya

  1. Tinjau siapa yang dapat mengubah DNS otentikasi.
  2. Membutuhkan bukti sebelum dan sesudah yang tepat.
  3. Pisahkan pemeriksaan sintaksis dari bukti pesan.

Pendiri / Non-teknis

Perlakukan publikasi DNS sebagai perubahan layanan

Kesalahan pemformatan kecil dapat mengganggu email meskipun pengaturan penyedia sudah selesai.

Langkah selanjutnya

  1. Memerlukan daftar periksa publikasi yang teruji.
  2. Sebutkan pemilik setiap layanan pengiriman.
  3. Jaga agar persetujuan pemulihan tetap tersedia.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah 255 oktet merupakan ukuran rekaman TXT maksimum?

Tidak. Ini adalah batas per karakter-string; satu data TXT dapat berisi beberapa string, tergantung pada batasan ukuran DNS .

RFC 1035 §3.3 RFC 1035 §3.3.14

Apakah SPF menyisipkan spasi antar string?

Tidak. Sertakan setiap spasi yang diperlukan dalam string sebenarnya.

RFC 7208 §3.3

Bisakah dua data SPF digabungkan oleh satu penerima?

Tidak. Beberapa data SPF yang dipilih menyebabkan kesalahan permanen.

RFC 7208 §4.5

Bisakah data TXT yang tidak terkait ada secara berdampingan?

Ya. Aplikasi memilih rekaman berdasarkan sintaksisnya sendiri dan nama pemiliknya.

RFC 7208 §4.5

Haruskah saya menempelkan karakter kutipan ke dalam formulir DNS ?

Gunakan format masukan penyedia yang terdokumentasi, lalu periksa nilai DNS sebenarnya.

Bisakah tampilan terbungkus membuktikan ada dua catatan?

Tidak. Periksa batasan catatan sumber daya, bukan batas garis visual.

Mengapa catatannya ada pada nama yang salah?

Beberapa editor menambahkan akhiran zona ke nama relatif. Tanyakan kepada pemilik yang memenuhi syarat dan dituju.

Apakah pencarian TXT yang benar membuktikan DMARC lolos?

Tidak. Otentikasi dan penyelarasan harus diperhatikan pada pesan yang representatif.

RFC 9989 §5.3.5

[ Sumber ]

Sumber

  1. RFC 9989

    Bagian §5.3.5

  2. RFC 7208

    Bagian §3.3 · §4.5

  3. RFC 1035

    Bagian §3.3 · §3.3.14

  4. Referensi penggalian ISC BIND

    Bagian Sintaks, -x pencarian terbalik, opsi kueri norecurse

[ Glosarium ]

Glosarium

String karakter TXT
String yang panjangnya dibatasi hingga 255 oktet data; TXT RR berisi satu atau lebih string tersebut.

RFC 1035 §3.3 RFC 1035 §3.3.14

Batas rekaman
Perbedaan antara catatan sumber daya terpisah dan string dalam satu catatan; Pemilihan SPF tidak menggabungkan kebijakan yang terpisah.

RFC 7208 §3.3 RFC 7208 §4.5

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