bk99.de entertain the web since 1997

bk99.de
RFC · DNSSECStandard explained

RFC 6698: DANE: Binding TLS keys via DNSSEC

Summary

RFC 6698 introduces TLSA records with which DNSSEC-secured domains name certificates or keys for TLS. DANE partly moves trust decisions into the DNS hierarchy. Additional trust paths increase both options and operational responsibility.

Ideas

  • TLSA links service, port and transport with certificate data.
  • DNSSEC protects the origin of the record.
  • Usage modes determine the relationship to the public PKI.

Remarks

  • RFC 6698 has the status “Proposed Standard”; current errata and successor documents should also be checked.

Recommendations

  • Validate DNSSEC before every DANE decision.
  • Plan certificate changes with overlapping TLSA data.

References

Read the RFC at the RFC Editor

Search the Web Archive

RFC · 2005

RFC 4033: DNSSEC: Authenticated DNS data

RFC 4033 introduces DNSSEC and explains the chain of trust, signed answers and validating resolvers. DNSSEC protects data origin, not confidentiality. Key and delegation operations decide its practical reliability.

Lutz Donnerhacke · 2017

DirectAccess breaks DNSSEC

In the lab, Lutz Donnerhacke shows how DirectAccess, DNS64 and policy-based name resolution can prevent valid DNSSEC checks. DNSSEC initially recognised the answer altered by DNS64 as insecure. The test distributed trust anchors and validation policies via group policy.

RFC · 2026

RFC 9846: TLS 1.3: The consolidated current specification

RFC 9846 replaces RFC 8446 and consolidates TLS 1.3 with the corrections and updates published up to then. Security standards occasionally need a consolidated new edition instead of many scattered updates. Superseding the document changes the reference, not the goal of a smaller, secure protocol.