<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>TLSA on Nalar</title>
    <link>https://nalar.dev/tags/tlsa/</link>
    <description>Recent content in TLSA on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/tlsa/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>DANE TLSA Binds TLS Service Keys Through DNSSEC</title>
      <link>https://nalar.dev/dane-tlsa-binds-tls-service-keys-through-dnssec/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/dane-tlsa-binds-tls-service-keys-through-dnssec/</guid>
      <description>&lt;h1 id=&#34;dane-tlsa-binds-tls-service-keys-through-dnssec&#34;&gt;DANE TLSA Binds TLS Service Keys Through DNSSEC&lt;/h1&gt;&#xA;&lt;p&gt;TLS normally authenticates a server through certificate validation rules defined by the application and its trust model. DANE adds a DNS-based binding: a TLSA resource record associates a service endpoint with certificate or public-key material, while DNSSEC supplies authenticated DNS data for that association.&lt;/p&gt;&#xA;&lt;p&gt;The boundary is strict. A TLSA RRset that is insecure or has an indeterminate DNSSEC state cannot serve as an authenticated DANE association. DANE therefore depends on DNSSEC validation rather than treating ordinary DNS transport as sufficient evidence.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
