Threat 1: Packet Interception
various forms of packet interception: monkey-in-the-middle attackes, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver.DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for the bad guy...
using TSIG or IPsec...would not be a very good solution for interception attackes... First, this approach would impose a fairly high processing cost per DNS message, as well as a very high cost associated with establishing and maintaining bilateral trust relationships between all the parties
..trust model is wrong since it would only provide hop-by-hop integrity check on DNS messages and would not provide any sort of end-to-end integrity check between the producer of DNS data and the consumer of DNS data.
DNSSEC deos provide end-to-end "data" integrity. of end-to-end
Threat 2: ID Guessing and Query Prediction
ID guessing is not enough to allow an attacker to inject bogus data, but combined with knowledge (or guesses) about QNAME's and QTYPEs for which a resolver might be querying, this leaves the resolver only weakly defended against injection of bogus responses....Threat 3: Name Chaining
Most name-based attacks can be partially mitigated by the long-standing defense of checking RRs in response messages for relevance to the original query....
but they all involved DNS RRS whose RADA portion
(right hand side) includes a DNS name...any such
RR is...a hook that lets an attacker feed bad data
into a victim's cache, thus potentially subverting
subsequent decisions based on DNS names....
examples are CNAME, NS, and DNAME RRs because they
can redirect a victim's query to a location of the
attacker's choosing
Threat 4: Betrayal By Trusted Server
the only difference between this sort of betrayal and a packe interception attack is that in this case the client has voluntarily sent its request to the attacker.Threat 5: Denial of Service
DNS is vulnerable to denial of service WHY?DNSSEC does not help this...since checking signatures both increases the processing cost per DNS message and in some cases can also increase the number of messages needed to answer a query.
Threat 6: Authenticated Denial of Domain Names
is there a requirement for authenticating the non-existence of a name.The issue is whether the resolver should be able to detect when an attacker removes RRs from a response.
Threat 7: Wildcards
What are wildcard DNS names?Weakness of DNSSEC
-
DNSSEC is complex to implement and includes some nasty edge cases
at the zone cuts
expired keys can cause serious problems for a DNSSEC-aware resolver - DNSSEC significantly increases the size of DNS response packets
- DNSSEC answer validation increases the resolver's work load
- DNSSEC's trust model is almost totally hierarchical
- key rollover at the root is really hard
- DNSSEC creates a requirement of loose time synch between the validating resolver and the entity creating the DNSSEC signatures.
- Possiblew existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably.
Future Work
- Interactions with other protocols
- Securing DNS Dynamic UPdate
- Securing DNS Zone Replication
Last Modified Thursday, 06-Apr-2006 10:03:58 PDT