DNS Security Technical Overview

1
DNS SecurityTechnical Overview

• Russ Mundy
• Principal Networking Scientist
• SPARTA, Inc.
• 7075 Samuel Morse Dr.
• Columbia, MD. 21046
• mundy_at_sparta.com
• mundy_at_tislabs.com

2
Domain Name System Background

• Created as scaleable method to replace original
  ARPANet host address file
  
• hosts.txt file distributed by SRI-NIC
• DNS was the first standards based name system
• Proved viability of interoperable infrastructure
  service based on specifications rather than
  implementations from a single vendor
  
• Originally, no attempt to identify DNS security
  requirements.
  
• DNS quickly became a critical service of the
  Internet infrastructure.

3
The DNS is .....

• What Internet users use to reference anything by
  name on the Internet
  
• The mechanism by which applications get
  translations of names to IP addresses and vice
  versa
  
• A lookup mechanism for translating one type of
  objects into other types of objects
  

4
The DNS is also

• A globally distributed, loosely coherent,
  scalable, reliable, dynamic database
  
• Comprised of two primary types of components
• The information itself, sometimes called the
  name space
  
• The moving parts that provide the means for
  users to get information - can be further divided
  to
  
• Resolvers (clients) which ask questions about DNS
  information
  
• Servers that provide answers to the DNS questions

5
The Domain Name System

• DNS database maps
• Name to IP addresswww.darpa.mil 128.9.176.20
• And many other mappings (mail servers, IPv6,
  reverse)
  
• Data organized as tree structure
• Each zone is authoritativefor its own data
• Minimal coordination between zone operators

Root
edu
mil
ru
darpa
isi
mil
usmc
nge
alpha
6
Another DNS tree
.
7
DNS Look up
Root Server
TLD Server
Zone Server
Other Servers

• How does data get into authoritative servers?
• There are other transfers to consider

"End" user
Local Server
8
Zone Data - Input Output
Master File Copy
Zone Master File
Zone Database
Master Server
Secondary Server
Server to Server Query(s)
Dynamic Update
"End" user
Local Server
Update Requester
End User Query
9
Why Worry About DNS Security???
10
Whats at Stake?

• Forged DNS data breaks most applications
• Web site can be replaced with a false site
  without ever touching the victim site
  
• E-mail can be re-routed or mis-delivered
• Login compromised through man in the middle
  attack
  
• DNS attacks are often a precursor to other
  attacks
  
• DNS attack tools readily available on the
  Internet, e.g., dsniff, dnshijack
  
• All parts of DNS hierarchy are vulnerable to
  attack, i.e., root level to lowest level resolver
  and client

11
More of Whats at Stake?

• Infrastructure problems present a challenge
• New capabilities must not disrupt old
  implementations
  
• Backward Compatibility essential to successful
  fielding
  
• Difficult for applications to counter
  infrastructure attack
  
• Typically, no alternative if DNS fails
• For most applications and end users, when their
  DNS service is not working correctly,
  
• the INTERNET IS DOWN

12
DNS Attack Motivators

• Anti-Spam and anti-phishing technologies
• Technologies that use the DNS to mitigate spam
  and phishing value for the Bad Guys
  
• StockTickers, RSS feeds
• Usually no source authentication but supplying
  false stock information via a stockticker or via
  a news feed can have benefit for attacker
  
• ENUM
• Mapping telephone numbers to services in the DNS
• As soon as there is some incentive

13
A Simple DNS Attack
Easy to observe UDP DNS query sent to well known
server on well known port.
www.darpa.mil A?
Root Server
www.darpa.mil A 192.5.18.19
Bills Laptop
Local Server
www.darpa.mil A 128.9.128.127
mil Server
Russs Laptop
First response wins. Second response is silently
dropped on the floor.
darpa.mil Server
14
What Does DNSSEC Do?

• Provides an approach so DNS users can
• Validate that data they receive came from the
  correct originator, i.e., Source Authenticity
  
• Validate that data they receive is the data the
  originator put into the DNS, i.e., Data
  Integrity
  
• Approach integrates with existing server
  infrastructure and user clients
  
• Maximize benefit when application software can
  determine if DNS data was received with
  authenticity and integrity

15
Isnt SSL All Thats Needed?

• SSL is not the magic bullet
• (Neither is DNSSEC)
• SSL wont be used everywhere
• Usage Problem Users offered a choices they may
  not understand
  
• alerts happen frequently
• users are not surprised but annoyed
• Not the technology but the implementation and
  user interface makes SSL vulnerable
  
• Some examples follow

16
Example 1 Common Name mismatch
17
Example 2 Certificate Authority Unknown
Unknown Certificate Authority
18
Are You Secure or Subverted?
19
How does DNSSEC come into this picture?

• DNSSEC secures the name to address mapping before
  the certificates are needed
  
• DNSSEC provides an independent trust path.
• The person administering https is most probably
  a different person from the one that does
  DNSSEC
  
• The chains of trust are most probably different
• See acmqueue.org article Is Hierarchical
  Public-Key Certification the Next Target for
  Hackers?
  
• DNSSEC counters attacks on applications that
  begin with an attack on DNS

20
Some DNS Vulnerabilities
Forged/compromised data
Local Server
www.darpa.mil
Zone Servers
Attackers
www.darpa.mil 128.9.128.127
End-user
Man in the Middle
Cache poisoning
Actually www.darpa.mil 192.5.18.195. But how
do you determine this?
21
Secure DNS Query and Response
Local Server
www.darpa.mil
Root Server
www.darpa.mil
192.5.18.195
Plus signature by darpa.mil
End-user
mil Server
Attacker can not forge this answer without the
darpa.mil private key.
darpa.mil Server
22
DNS Security Hypersummary

• Each DNS zone signs their data with their private
  key.
  
• Signing should be done with zone data
  preparation
  
• User queries are answered with
• the requested information
• plus DNSSEC data for the requested information.
• Users authenticate responses with trusted key(s)
• At least one trusted public key is
  pre-configured
  
• Validation done with pre-configured key or keys
  learned via a sequence of queries to the DNS
  hierarchy.
  
• Enables and supports other security technologies

23
QUESTIONS????
Questions, comments and other feedback can be
sent to mundy_at_sparta.com
24
(No Transcript)
25
Resources

• Reference
• /doc /arm/Bv9ARM.html
• DNS and BIND, Albitz Liu, O Reilly
  Associates
  
• FAQ http//www.nominum.com/resources/faqs/bind-fa
  qs.html
  
• RFCs
• /doc/rfc/
• http//www.ietf.org
• ftp//ftp.ripe.net/rfc/
• Drafts
• http//www.ietf.org
• ftp//ftp.ripe.net/internet-drafts/

26
Additional Resources

• http//www.nlnetlabs.nl/dnssec/
• http//www.dnssec.net/
• http//www.ripe.net/disi/
• http//dnssec-deployment.org/
• Papers from the 5th USENIX UNIX Security
  Symposium, Salt Lake City, Utah, June 1995
  
• P. Vixie DNS and BIND Security Issues
• http//www.usenix.org/publications/library/proceed
  ings/security95/vixie.html
  
• S. Bellovin Using the DNS for Break-ins
• http//www.usenix.org/publications/library/proceed
  ings/security95/bellovin.html

27
Related mailing lists

• dnssec_at_cafax.se
• operators and developers working on dnssec
• namedroppers_at_ops.ietf.org
• DNSEXT IETF working group (DNS protocol
  development)
  
• dnsop_at_cafax.se
• DNSOP IETF working group (operational DNS
  issues)
  
• techsec_at_ripe.net
• RIPE Technical Security working group
• dns-wg_at_ripe.net
• RIPE DNS working group

28
Questions???
send questions and feedback to
olaf_at_ripe.net or mundy_at_sparta.com