bk99.de entertain the web since 1997

bk99.de
Lutz Donnerhacke · DNSSECCurated

DirectAccess breaks DNSSEC

Summary

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.

Ideas

  • DNS64 changes answers and therefore predictably collides with DNSSEC signatures.
  • Enforced validation makes manipulated answers visible instead of silently usable.
  • Native IPv6 destinations avoid the need to synthesise IPv6 addresses.
  • DirectAccess can still pass on signed native answers incompletely.
  • Successful connectivity does not prove successful cryptographic name validation.
  • Lab setups make interactions between transition technologies reproducible.

Insights

  • Compatibility mediation and end-to-end authenticity often pursue opposite goals.
  • Security functions often fail because of intermediate layers rather than the protocol itself.
  • Negative tests reveal resolver errors more reliably than successful name resolution.

Quotes

  • Nein, der DirectAccess-Resolver macht DNSSEC kaputt. (“No, the DirectAccess resolver breaks DNSSEC.”) – Lutz Donnerhacke

Habits

  • Donnerhacke checks positive and negative DNS answers separately for signatures.

Facts

  • A native AAAA answer did not reach the DirectAccess client correctly either.

References

Critique

  • The specific finding applies to the DirectAccess setup and software version of the time.
  • The article does not fully separate resolver, client and policy errors from each other.

Remarks

  • DirectAccess is historical, but DNS rewriting remains relevant in transition networks.
  • The experiment shows the value of cryptographically verifiable error messages.

Recommendations

  • Test DNSSEC with positive, negative and deliberately altered answers.
  • Document every resolver and every rewrite in the query path.
  • Prefer native IPv6 when DNS64 creates avoidable complexity.

Read the original article

Search the Web Archive

RFC · 2012

RFC 6698: DANE: Binding TLS keys via DNSSEC

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.

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 · 2026

Misconfiguration as a Service: Answering undeliverable traffic sensibly

Lutz Donnerhacke intercepts misrouted customer traffic to private addresses and examines safe responses that calm faulty devices and make misconfigurations visible. Among other things, DNS, LDAP, ICMP and solar inverter control traffic was observed. The provider network itself used 100.64.0.0/10 for its customers.