As part of a plan to overhaul some of our DNS infrastructure, we began assessing the current threat landscape and our exposure. We started with a table of potential attack vectors and clearly volumetric (DDoS) attacks aren’t the only problem. We have many classes of DNS-specific exploits (listed in red).
- What’s interesting here are the mitigations to some of these attacks.
DNS was designed to be a lightweight, fast and robust solution to the problem of having to remember dozens of numbers in the dotted notation format i.e. name-to-IP resolution but it lacks ‘authentication’ i.e. when a client queries a DNS server for a domain name, DNS by itself doesn’t really authenticate the parties involved in the exchange (i.e. Client ↔ Server). This has been exploited time and again to mount large-scale attacks (i.e. cache poisoning major ISP resolvers) against major parts of the Internet’s DNS infrastructure.
To deal with this inherent weakness and add some resilience to this part of the Internet’s infrastructure, the addition of extensions to DNS (via the ‘EDNS0’ mechanism) such as DNSSEC and DANE was proposed and ever since, there has been a gradual but steady increase in our reliance on the Internet’s DNS infrastructure.
Now whether that’s a good thing or a disaster waiting to happen is a raging debate. But for now, let’s weigh in on the pros and cons of these solutions. Here’s how they work in a nutshell
DNS security extensions or ‘dnssec’:
DNSSec allows domain owners to digitally sign resource records. Part of the design decision in DNSSec is that name servers do not implement any cryptography; signatures are generated offline, while resolvers check signatures.
- We start by signing a DNS zone file using asymmetric/public-key cryptography.
- And authentication of responses is offloaded onto resolvers
- Finally, the chain of trust is similar to TLS but the big difference is there are no 3 parties (CA’s), the chain of trust is embodied in the DNS’s hierarchical structure.
Pros and Cons:
- Although DNSSec is designed to improve Internet security by providing authentication and integrity protection for DNS, the addition of cryptographic signatures resulting in large DNS message sizes has been criticized as it could contribute to DNS amplification attacks.
- While DNSSec would potentially protect against DNS cache poisoning, it does so at the cost of increased susceptibility to DDOS attacks, an increased utility for DDoS amplification attacks.
- The computational overhead of authenticating every DNS response returned by every authoritative name server can become the object of an attack where an attacker can exploit the asymmetry in ‘work-done’ by the server Vs. a client (much like that SSL renegotiation attacks) [1] i.e. resolving www.example.com, the responses from the root, .com, and example.com name servers must each be authenticated independently.
- And even after all that work, all of this would be of no value if the clients don’t know how to ask a resolver, “are you sure that data are correct?” A client can set a CD (“checking disabled”) flag to tell its DNS server, "don’t bother checking the signatures on the records). The DNS server can set an AD (“authenticated data”) flag to say, “this data checked out”). But DNSSec-aware DNS servers always return their responses, even if the hashes did not match and the data could not be authenticated. It’s up to the client to read the AD flag to see whether to discard the data or not. If your client can’t read the flag, it uses the data as if it were good.
Domain-based authentication of named entities or ‘dane’:
"DANE works by embedding certificate information into DNS records so that a client can receive authentication data directly from domain owner. The system relies on DNSSec to ensure a secure connection between the client and the DNS server. This system allows clients to ask the domain owner about which certificates they should accept as credentials. The client validates the DNSSec chain by verifying each record until it hits a root, which it can identify as a trusted root. "[2]
In short, DANE allows us to add certificate information via a new DNS record (TLSA record) and retrieved by clients prior to establishing a secure TLS connection. Clients validate the TLS certificate chain obtained against that of DANE’s TLSA entries. If everything checks out, the HTTPS connection proceeds.
An example of a full certificate association using TLSA RR
_443._tcp.www.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020… )
Pro and cons:
- Although the system design localizes security issues and decreases the number of parties affected in the event that a compromise occurs, trust is placed into a single DNSSec root potentially creating a single point of failure for the entire system.
- This model also changes the traditional targets of DNS attacks from CA’s to Domain owners - the new targets in this proposed system who would have to face many of the problems currently seen by the CAs. Is every domain owner capable of securing themselves against attacks?
The big question:
Are we cramming too much into our DNS infrastructure in an attempt to quickly respond to a few attack vectors or is this the best solution for the changing security landscape?
References
[1] Alex Cowperthwaite, Anil Somayaji “The Futility of DNSSec” School of Computer Science, Carleton University
[2] Alexandra C. Grant, Senior Honors Thesis, Advisor: Charles C. Palmer “Search for Trust: An Analysis and Comparison of CA System Alternatives and Enhancements” Dartmouth Computer Science Technical Report