Baca tanggal status sebelum mengevaluasi proposal
Kerangka Kebijakan Hubungan Domain mengusulkan cara bagi domain untuk menggambarkan dan saling mengkonfirmasi hubungan. Hal ini dapat memberikan informasi yang lebih eksplisit kepada pihak yang mengandalkan dibandingkan logo serupa, desain situs web bersama, atau dugaan asosiasi perusahaan. Apakah informasi tersebut akan memengaruhi keputusan email bergantung pada otoritas, aturan validasi, dan perilaku konsumen, bukan hanya pada publikasinya.
Proyek itu halaman status, yang diperiksa pada tanggal 9 November 2026, secara eksplisit menetapkan tanggal statusnya menjadi 1 Juli 2024. Dokumen ini menjelaskan kerangka kerja yang diusulkan untuk pertimbangan publik dan mencantumkan pengajuan Draf Internet deskriptif sebagai langkah berikutnya. Tanggal-tanggal tersebut harus tetap terpisah: halaman yang dapat dibaca hari ini tidak menjadikan pernyataan statusnya terkini. Belum ada status proyek yang pasti, hasil standar atau adopsi penerima yang diverifikasi untuk penilaian ini.
Itu beranda proyek menjelaskan pengembangan ad-hoc dan mengetahui detail penerapan yang hilang. A Akun pengembang Februari 2024 oleh J. Trent Adams juga menyebut pekerjaan itu sebagai proposal awal. Bahasanya tentang standardisasi harus dibaca dalam konteks itu. Artikel ini mengevaluasi model yang terdokumentasi; itu tidak mengumumkan standar yang diterapkan atau menentukan catatan DNS produksi.
Pisahkan mekanisme penemuan dari makna kebijakan
Yang diusulkan arsitektur memiliki pernyataan DNS TXT yang kecil dan, jika diperlukan, dokumen kebijakan yang lebih kaya. Pernyataan dapat mengungkapkan hubungan dasar atau membantu menemukan kebijakan terperinci. Dokumen tersebut membedakan metadata dari konten kebijakan dan memungkinkan kosakata untuk menggambarkan berbagai jenis hubungan. Sebagian besar pekerjaan interpretasi adalah milik pihak yang mengandalkan.
Pemisahan itu penting. Menemukan suatu dokumen tidak membuktikan bahwa dua konsumen menafsirkan kosakatanya secara identik. Konsumen memerlukan profil yang disepakati untuk hubungan yang sedang dievaluasi, termasuk persyaratan yang didukung dan perilaku untuk persyaratan yang tidak diketahui. Halaman-halaman yang tersedia menggambarkan kemungkinan-kemungkinan daripada menetapkan satu tata bahasa lengkap yang dapat dioperasikan. Deskripsi mereka yang berbeda mengenai konten pernyataan minimal tidak boleh diselesaikan secara diam-diam ke dalam format wajib yang dibuat-buat.
Satu penjelasan arsitektural juga memerlukan kualifikasi DNS . RFC 1035 bagian 3.3 dan 3.3.14 mendefinisikan data TXT sebagai satu atau lebih karakter-string, masing-masing dengan panjang satu oktet. Batas konten 255 oktet berlaku untuk string individual, bukan batas maksimum universal 255 karakter untuk seluruh data sumber daya TXT . Koreksi ini tidak menyediakan profil publikasi atau penguraian DRPF yang hilang.
Periksa konfirmasi timbal balik sebagai klaim spesifik
Akun pengembang menjelaskan konfirmasi dalam dua arah: pernyataan yang menamai domain lain harus memiliki pernyataan yang sesuai dari domain tersebut. Hal ini menantang klaim asosiasi secara sepihak. Itu tidak secara independen menetapkan kepemilikan sah, integritas akun kedua administrator, atau keamanan instruksi pembayaran yang diterima melalui email.
Penilai harus mengidentifikasi otoritas apa yang sebenarnya dikontrol oleh masing-masing penerbit dan bukti apa yang melindungi pengambilan. Dua pernyataan yang saling konsisten dari sistem yang dikompromikan tetap menjadi masalah yang berbeda dari satu domain yang membuat klaim yang tidak didukung. Oleh karena itu, tinjauan keamanan memerlukan model ancaman, asumsi keaslian, dan penanganan kegagalan yang pasti. Itu adalah persyaratan evaluasi di sini, bukan kemampuan yang ditunjukkan oleh proposal atau implementasi yang diuji untuk artikel ini.
Petakan hubungan merek fiksi dari ujung ke ujung
Pertimbangkan domain fiksi brand.example dan parent.example . Administrator merek akan mempublikasikan pernyataan bawahan; administrator induk akan menerbitkan konfirmasi yang sesuai. Aplikasi keamanan hipotetis adalah konsumen. Tugas yang diusulkan adalah membandingkan dua pernyataan terarah untuk hubungan yang sama, sambil menjaga asosiasi bisnis yang diklaim terpisah dari otentikasi pesan.
Proyek itu kasus penggunaan domain terkait mengilustrasikan dua pendekatan penemuan. Konsumen dapat menemukan kebijakan induk melalui pernyataan induk, atau mengikuti lokasi kebijakan yang diberikan secara lebih langsung oleh anak. Halaman ini juga mengilustrasikan dokumen JSON-LD terstruktur. Ini adalah contoh konseptual, bukan bukti bahwa bisnis yang disebutkan tersebut menerapkan DRPF atau bahwa label sampel mereka membentuk format kabel yang stabil.
Untuk peta fiksi ini, konsumen akan mencatat dokumen dan interpretasi mana yang mendukung hubungan pada titik tertentu. Jika orang tua menarik konfirmasi, hubungan tersebut tidak lagi memiliki dukungan timbal balik yang sama. Tidak ada catatan yang dipublikasikan atau diambil untuk domain fiksi ini, dan tidak ada parser, validasi tanda tangan, atau perilaku pihak yang mengandalkan yang telah diuji.
Membutuhkan siklus hidup di luar kemampuan untuk menarik diri
Arsitekturnya menggambarkan pemutusan hubungan dengan mengubah konfirmasinya. Ini merupakan mekanisme pencabutan konseptual yang berguna, namun mekanisme ini tidak dapat langsung melakukan penarikan di semua tempat. Pernyataan yang disimpan dalam cache, dokumen kebijakan yang disimpan, dan penerbit yang tidak tersedia untuk sementara memerlukan penanganan eksplisit sebelum konsumen dapat membuat keputusan yang dapat diandalkan.
Peninjau harus menanyakan berapa lama bukti masih dapat digunakan, apa yang terjadi jika hanya satu pihak yang berubah, dan apa perbedaan kebijakan yang tidak tersedia dengan penarikan yang disengaja. Pemulihan setelah kompromi penerbit dan rantai kebijakan yang bertentangan juga memerlukan hasil yang pasti. Pertanyaan-pertanyaan ini harus menghasilkan aturan siklus hidup yang terdokumentasi dan pengujian resmi, bukan asumsi optimis yang diselesaikan oleh publikasi timbal balik setiap transisi keadaan berikutnya.
Pisahkan autentikasi email dan persetujuan bisnis
Hubungan administratif yang dinyatakan antara dua domain berbeda tidak berubah DMARC penyelarasan dengan sendirinya. RFC 9989 bagian 4.4 mendefinisikan keselarasan antara pengidentifikasi yang diautentikasi dan Domain Penulis. Klaim hubungan tidak mengubah tanda tangan yang tidak terkait menjadi tanda tangan yang selaras, dan penilaian ini tidak menetapkan aturan penerima yang memperlakukan DRPF sebagai pengecualian.
Demikian pula, tidak ada manfaat penempatan kotak masuk, warisan reputasi, atau otorisasi untuk membayar pemasok. Jika calon konsumen menggunakan informasi hubungan, dokumentasikan keputusan tepat yang memengaruhinya dan pertahankan kontrol independen untuk autentikasi pesan dan persetujuan bisnis. Sinyal yang mungkin muncul di masa depan tidak boleh diam-diam menjadi daftar yang diizinkan atau alasan untuk melemahkan kebijakan yang ada.
Catat apa yang masih belum dikonfirmasi
Peta hubungan yang diusulkan diberikan sebagai artefak analitis, sementara persyaratan status tetap terbuka. Persyaratan sebenarnya adalah: Memetakan satu hubungan yang diusulkan, penerbitnya, konsumen, model validasi dan pencabutannya; konfirmasi status proyek saat ini. Gerbang komisioningnya adalah: Verifikasi proyek saat ini dan status adopsi. Jelaskan proposal tersebut tanpa menyajikannya sebagai standar IETF yang diadopsi.
Akun sosial tertaut dan penelusuran Datatracker tidak dapat diakses dan tidak dicoba ulang atau dilewati. Absennya pencarian tidak dapat membuktikan bahwa tidak ada karya selanjutnya. Konfirmasi status saat ini, tinjauan spesialis, uji implementasi dan interoperabilitas, tinjauan presentasi langsung, dan persetujuan pemilik masih diperlukan sebelum kesimpulan atau publikasi yang lebih kuat.