Skip to Content.
Sympa Menu

discuss - [opennic-discuss] DANE/DNSSEC Poisoning

discuss AT

Subject: Discuss mailing list

List archive

[opennic-discuss] DANE/DNSSEC Poisoning

Chronological Thread 
  • From: coyo AT
  • To: OpenNIC Discuss <discuss AT>
  • Subject: [opennic-discuss] DANE/DNSSEC Poisoning
  • Date: Wed, 12 Aug 2015 03:16:14 -0500

My understanding of how DANE/DNSSEC actually works is somewhat rudimentary, but the basic premise is pretty much the same as CA-based PKI, in that you have trust anchors, a list of ultimately trusted root certs that form the top level of trust, and then a chain of trust.

In DANE/DNSSEC, the root certs authenticate the root DNS zone, and each subdomain of the root zone is signed by one of the set of root certs. These certs are ultimately trusted, and you can import an ultimately trusted root cert to, for example, have a non-standard top level domain (TLD). .fur, for example, or perhaps .furry. you need a root zone cert that authenticates that .furry is authoritatively governed by a set of DNS nameservers serving that TLD, which in turn sign certs for any subdomains that that zone contains, which could be many.

In other words, DANE/DNSSEC has the same basic model as TLS CA PKI, except the DNS heirarchy performs the role of the root CAs, instead. Since the same basic model is used, and anyone can import root CAs, potentially for perfectly legitimate purposes, it shares the same weaknesses as the TLS CA-based PKI.

If a combination of poisoned routers performing IP-level redirection, IP masqurading with public IP addresses to redirect traffic to servers that don't actually have those IP addresses truly allocated to them, or confederate poisoned DNS servers...

Take for example that clients are configured to use and as their DNS servers. the gateway router has been compromised, and forwards any traffic destined for those IP addresses down a GRE tunnel or something to another confederate router, which then forwards the DNS ports to confederate DNS nameservers.

The client can't really know the difference, IF the client resolver has one or more ultimately trusted root zone certs that sign the .com zone, and have the google subdomain pointing to the confederate nameservers as authoriative. This means those nameservers can use poisoned DANE to falsely authenticate entities as having legitimate authentication when in fact the client is being subverted.

What this means is that even if DANE is used, it still uses the same basic model, and suffers the same weaknesses. My question is, assuming I have legitimate or just experimental/educational reasons to do something like this, is there anything I'm missing in terms of how to execute such a feat?

My comprehension of how exactly DNSSEC and DANE work is admittedly lacking.

Any protips, advice, comments or further information would be greatly appreciated, and thank you in advance for your time, contributions and patience.

  • [opennic-discuss] DANE/DNSSEC Poisoning, coyo, 08/12/2015

Archive powered by MHonArc 2.6.19.

Top of Page