Lesson: Where Does Your Browser's "Trust" Actually Come From?
Here's a question worth sitting with: when your browser shows a padlock icon next to a website, what is it actually trusting?
It's not trusting the website. It's trusting a Certificate Authority — a third-party company that vouches for the website by issuing it a certificate. Your browser ships with a built-in list of a few hundred CAs it's told to trust automatically. If any one of those CAs is compromised, tricked, or coerced, every certificate it has ever issued becomes suspect.
That's the system almost the entire internet runs on today. It works, but it has a single point of failure baked into its foundation: trust is delegated to a small number of institutions, and you have no say in which ones your software trusts.
Today's lesson is about an alternative model — DANE — and why Handshake names are a natural home for it.
Step 1: What DANE Actually Does
DANE stands for DNS-Based Authentication of Named Entities. The idea is simple once you see it: instead of asking a Certificate Authority to vouch for a website's certificate, you publish the certificate information directly in the DNS record for that domain, using a record type called TLSA.
When a client connects, it can check the TLSA record and confirm the certificate matches — without needing a Certificate Authority in the loop at all. The domain's own DNS becomes the source of truth for its cryptographic identity.
Step 2: Why This Only Works If the DNS Itself Is Trustworthy
Here's the catch, and it's the part most explanations skip: DANE is only as trustworthy as the DNS system carrying the TLSA record. If the DNS itself can be tampered with, spoofed, or centrally controlled, then trusting a TLSA record just moves the single point of failure — it doesn't remove it.
This is exactly why DANE never saw mass adoption on the legacy DNS. Traditional DNS depends on a hierarchy of registries, registrars, and resolvers, any of which can be pressured, hacked, or misconfigured. Publishing your trust anchor inside a system that isn't itself tamper-resistant doesn't solve the underlying problem.
Step 3: See How Handshake Changes the Equation
A Handshake name's root record lives on a decentralized blockchain, secured by proof-of-work consensus rather than a central registry. When a TLSA record is published under an HNS name, it inherits that same tamper-resistance. There's no registrar who can be served a takedown request to alter it, no single database that can be quietly edited.
This is the missing piece that makes DANE actually meaningful: a cryptographic trust anchor published in a place that is itself cryptographically secured, rather than administratively secured.
Step 4: Where This Shows Up in Practice
I've written previously about DANE/TLSA-based credential issuance in the context of digital identity and voter verification — the same logic that lets a domain vouch for its own certificate can let a Handshake name vouch for a credential, a device identity, or a piece of self-issued documentation, all without a Certificate Authority as a middleman.
The pattern generalizes: anywhere you currently need a trusted third party to vouch for something, a Handshake name can let the thing vouch for itself. It's another example of the structural layer I mapped out in the Iceberg of the Internet series — trust infrastructure most people never look at directly, but that shapes everything built on top of it.
Summary of the Lesson
- DANE lets DNS records replace Certificate Authorities as the source of cryptographic trust.
- DANE only works as well as the DNS carrying it — which is why it stalled on the legacy, centrally-administered DNS.
- Handshake names give DANE a foundation that matches its ambition: a trust anchor secured by cryptography, not by institutional goodwill.
How to Explore This Yourself
The most direct way to see HNS-anchored trust in action is through the SkyInclude Browser, which resolves Handshake names — and the records they carry — natively.
NIHON — Handshake Infrastructure & Web3 Identity.