DNSSEC and TLSA PoC Site
Home Page
What is this all about?
DNSSEC is a method to secure your DNS against faking, spoofing and redirecting.
DNS Records secured by DNSSEC can be verified directly by asking your DNS server.
The core DNSSEC RFCs 4033, 4034 and 4035 were established in 2005.
DANE is a method to publish certificates, checksums and valid signers on your DNSSEC-protected DNS server.
Any client on the internet can then verify the certificate by directly asking your DNS server.
This means that you can provide your own certificates instead of buying them.
The core DANE RFC 6698 was established in 2012.
TLSA is a method to verify a transport certificate on your DNS, e.g. for HTTPS or SMTP/TLS.
The core TLSA RFC 6698 was updated by 7218 and was established in 2012, the RFC 7672 for SMTP in 2015.
OPENPGPKEY and SMIMEA are methods to publish or verify an e-mail certificate on your DNS.
While RFC 7929 for OPENPGPKEY was specified in 2016, RFC 8162 for SMIMEA was established in 2017.
Unfortunately, the industry has no interest to delegate this kind of power to the domain owners.
Instead, they are pulling a "Big Brother" on us:
"Trusted Certificate Authorities" are forcing us to buy certificates from them, making sure that...
...Browser software companies are verifying certificates against "Trusted CAs" only.
The arguments are always the same:
Keeping the power in "trustworthy" hands (power is addictive and will sooner or later get abused).
The standard is too new (they already wasted ten years without giving us the tools to use it).
Minimizing the risk of compromise (so if one CA is compromised, all of its customers are, too).
Security should be maintained by professionals (the Arc was built by amateurs, the Titanic by professionals).
Additive security (where is the point in verifying a compromised certificate by using TLSA?).
The common DNS operator is incapable of handling these complex mechanisms (but they are?).
Keeping the complexity from the end users (as we all like to be told what is best for us).
The private keys would be kept unprotected on the DNS servers (now they are on the web servers, so what?).
The DNSSEC keychain is less trustworthy than a Public CA (why, the mechanism is exactly the same).
You need a public CA to revoke compromised certificates (wrong - you can publish valid signers, including your private CA).
They cannot guarantee our security (better take your security in your own hands than depend on their whims).
... and other lame excuses.
Help pushing for DNSSEC
Users: Ask your IT staff to provide safe DNS lookups and demand DANE support from your browser software
Managers: Reduce TCO by doing the right thing
IT staff: Implement DNSSEC validation on your DNS servers and establish DNSSEC on your domains
ISP staff: Implement DNSSEC validation on your DNS servers and provide the tools for
domain users to maintain their DNSSEC-protected domains
Browser companies: Implement RFC 6698 and give us the choice to accept TLSA without "trusted CA"
Trusted CA companies: Stop patronizing the internet community. Stop deferring DNSSEC and DANE.