Security and Information Assurance for the DNS

1
Security and Information Assurancefor the DNS

• Dan Massey
• USC/ISI

2
The Domain Name System

• Virtually every application uses the Domain Name
  System (DNS).
• DNS database maps
• Name to IP addresswww.isc2033.com
  207.127.135.80
• And many other mappings (mail servers, IPv6,
  reverse)
• Data organized as tree structure.
• Each zone is authoritativefor its local data.

Root
edu
mil
com
darpa
isi
icc2003
usmc
nge
quantico
3
Current State Data Availability

• Original DNS design focused on data availability
• DNS zone data is replicated at multiple servers.
• A DNS zone works as long as one server is
  available.
• DDoS attacks against the root must take out 13
  root servers.
• But the DNS design included no authentication.
• Any DNS response is generally believed.
• No attempt to distinguish valid data from
  invalid.
• Just one false root server could disrupt the
  entire DNS.

4
Limitations of Availability
Easy to observe UDP DNS query sent to well known
server on well known port.
www.icc2003.com?
Root DNS Server
www.icc2003.com 192.5.18.19
Manus Laptop
Caching DNS Server
www.darpa.mil 128.9.128.127 First response wins!
com DNS Server
Dans Laptop
Second response is silently dropped.
Icc2003.com DNS Server
5
New Approach Add Authentication

• Each DNS zone signs its data using a private key.
• Recommend signing done offline in advance
• Query for a particular record returns
• The requested resource record set.
• A signature (SIG) of the requested resource
  record set.
• Resolver authenticates response using public key.
• Public key is pre-configured or learned via a
  sequence of key records in the DNS heirarchy.

6
Secure DNS Query and Response
Caching DNS Server
www.icc2003.com
Authoritative DNS Servers
www.icc2003.com
192.5.18.195 Plus (RSA) signature by icc2003.com
End-user
Attacker can not forge this answer without the
icc2003.com private key.
DNS Security Extensions add public key
signatures to the protocol manage/learn DNS
public keys
7
So Why Arent We There Yet

• Deployment in Existing Infrastructure is Hard
• Strengthen some aspects, but add stress to
  existing weak points (ex NS record consistency
  in DNS)
• Original Design (RFC 2535) was fatally flawed
• Key management was an after thought.
• Operations must be simple if hope to deploy.
• Ignored operations and business model issues.
• Cryptography alone is not the answer.
• Adds new DoS due to crypto errors attacks
• Must first ensure data availability
• View as one fence that enables other services.

8
Questions
Cryptography is like magic fairy dust, we just
sprinkle it on our protocols and its makes
everything secure - See IEEE Security and
Privacy Magazine, Jan 2003