<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DANE on Nalar</title>
    <link>https://nalar.dev/id/tags/dane/</link>
    <description>Recent content in DANE on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/dane/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC</title>
      <link>https://nalar.dev/id/dane-tlsa-mengikat-key-layanan-tls-melalui-dnssec/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/dane-tlsa-mengikat-key-layanan-tls-melalui-dnssec/</guid>
      <description>&lt;h1 id=&#34;dane-tlsa-mengikat-key-layanan-tls-melalui-dnssec&#34;&gt;DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC&lt;/h1&gt;&#xA;&lt;p&gt;TLS biasanya mengautentikasi server melalui aturan validasi sertifikat yang ditetapkan aplikasi dan trust model-nya. DANE menambahkan binding berbasis DNS: resource record TLSA mengasosiasikan endpoint layanan dengan material sertifikat atau public key, sedangkan DNSSEC menyediakan data DNS terautentikasi untuk asosiasi tersebut.&lt;/p&gt;&#xA;&lt;p&gt;Batasnya tegas. RRset TLSA yang berstatus insecure atau memiliki status DNSSEC indeterminate tidak dapat menjadi asosiasi DANE terautentikasi. Karena itu, DANE bergantung pada validasi DNSSEC dan tidak menganggap transport DNS biasa sebagai bukti yang memadai.&lt;/p&gt;</description>
    </item>
    <item>
      <title>TLS-RPT Menampilkan Kegagalan TLS SMTP sebagai Laporan Agregat</title>
      <link>https://nalar.dev/id/tls-rpt-menampilkan-kegagalan-tls-smtp-sebagai-laporan-agregat/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/tls-rpt-menampilkan-kegagalan-tls-smtp-sebagai-laporan-agregat/</guid>
      <description>&lt;p&gt;Keamanan transport SMTP memiliki persoalan observabilitas. Domain penerima dapat memublikasikan kebijakan MTA-STS atau record DANE TLSA, tetapi banyak kegagalan terjadi pada sistem pengirim di luar kendalinya: validasi sertifikat dapat gagal, host MX dapat tidak terjangkau, negosiasi STARTTLS dapat bermasalah, atau kebijakan transport yang dipublikasikan dapat tidak valid. Penerima memerlukan telemetri dari pengirim tersebut untuk membedakan deployment yang berfungsi dari kebijakan yang tanpa terlihat menghambat pengiriman.&lt;/p&gt;&#xA;&lt;p&gt;SMTP TLS Reporting, yang umum disebut TLS-RPT, menetapkan kanal telemetri tersebut dalam RFC 8460. Domain penerima memublikasikan record DNS TXT yang menyebut satu atau beberapa tujuan laporan. Sistem pengirim yang mendukung mekanisme ini kemudian menghasilkan laporan agregat mengenai sesi TLS yang berhasil memenuhi kebijakan dan kegagalan yang ditemui saat mengirim email ke domain tersebut.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
