Domain Name System Security

1
Domain Name System Security
2
Outline

• Brief overview of DNS
• DNS Vulnerabilities
• DNSSEC solution
• Conclusions

3
You are here

• DNS Overview
• DNS Vulnerabilities
• DNSSEC
• Conclusions

4
What is the DNS?

• Distributed naming service
• Name resolution
• names to IP address
• IP address to names
• Hierarchical organization as a rooted tree
• Domains sub-trees of the tree
• Zones administrative cut of the namespace

5
DNS Tree Example
root
.
domain
.nl
.com
top level
6
Typical DNS name resolution
Question www.microsoft.com
star.cs.vu.nl
. NS
Local name server
www.microsoft.com A ?
host.cs.vu.nl
IP address of .com name server
Resolver
www.microsoft.com A ?
Query cache
.com NS
www.microsoft.com A ?
Answer xxx.xxx.xxx.xxx
cache
IP address of microsoft.com name server
add Answer to cache
www.microsfot.com A ?
Answer xxx.xxx.xxx.xxx
microsoft.com NS
www.microsoft.com
7
DNS Components

• DNS Database
• Collection of files
• Zone file contains all Resource record of ALL
  nodes in the zone
• Resource records
• A Address record
• PTR Reverse lookup record
• NS Name server record
• CNAME Symbolic link record

8
What does the Zone file look like?

• Example Zone file
• cs.vu.nl 7200 IN SOA star.cs.vu.nl.(2001061
  501, 43200, 14400,345600,7200)
• cs.vu.nl 7200 IN NS star.cs.vu.nl.
• Cs.vu.nl 7200 IN NS solo.cs.vu.nl.
• star.cs.vu.nl 3600 IN A 192.31.231.42
• solo.cs.vu.nl 3600 IN A 192.31.231.66
• host.cs.vu.nl 2600 IN A 192.31.231.25

Label
ttl
class
type
rdata
9
You are here

• DNS Fundamentals
• DNS Vulnerabilities
• DNSSEC
• Conclusions

10
DNS message format
Contains 16 bits Message ID
Which server is authoritative of this info
Extra information that may be handy, optimization
BIND uses a very basic algorithm to generate IDs
increment sequentially
11
Cache poisoning example
www.evil.com A?
www.evil.com A 192.5.18.19 Additional info
www.microsoft.com CNAME star.evil.com
Victims DNS Server
Attackers DNS server
www.evil.com A?
Attackers machine

• - The Attacker has an authoritative DNS server
  for a domain. E.g. evil.com
• - The Attacker makes a DNS request for his domain
  against the target DNS server.
• The victim requests the attackers DNS server.
• The DNS server send the legitimate answer but
  also adds some incorrect hints. The victims cache
  is poisoned.

12
ID Spoofing example
Easy to observe UDP DNS query sent to well known
server on well known port.
www.vu.nl A?
www.vu.nl A 192.5.18.19
Victim's machine
Local Server
Flood the victim with messages with ID, ID1,
ID2, www.vu.nl A 128.9.128.127
Bad guy
First response wins. Second response is silently
dropped on the floor.
13
DNS Vulnerability points

• Name resolution

.com NS
Local name server
Resolver
Rogue NS
add Answer to cache
Man in the middle sending incorrect responses to
client
Rogue server can poison resolver cache. All
requests will get the wrong answers for the TTL
interval
Rogue server sending incorrect response to client
14
DNS Vulnerability points Contd.

• Zone Transfer
• Dynamic Updates

Master NS
Slave NS
Dynamic updates
Rogue master server sending incorrect data to
slaves
Need data integrity and origin authentication
Unauthorized updates to Zone file
15
What is at stake?

• Compromised 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
• Denial of service
• All parts of DNS hierarchy are vulnerable to
  attack, i.e., root level to lowest level resolver
  and client

16
DNS Security requirements

• DNS Data origin authentication and integrity can
  you trust the RRs in the DNS message.
• DNS Transaction security is this response to a
  legitimate query from a legitimate server?
• Interoperability with non-security aware
  implementations
• Confidentiality and access control may not be
  provided

17
You are here

• DNS Overview
• DNS Vulnerabilities
• DNSSEC
• Conclusions

18
What is DNSSEC?

• Described in RFC 2065 and 2535 (1999)
• Provides data origin authentication and data
  integrity for DNS data through digital
  signatures.
• Concepts
• New RRs
• Signing and verification
• Chain of trusts
• Authenticated denial
• Transaction security

19
New Resource Records

• Key RR
• Public key of the zone, name server or a normal
  host. Needed for verifying the signature
• SIG RR
• Digital signature over RRsets using zones
  private key
• NXT RR
• Authenticated non-existence of data, indicates
  which RRset is next in the zone.

20
Signing and verification of DNS data

• The DNS servers sign with the zones private keys
• Signature encryptzones private key(hash of
  RRSet)
• Public KEYs can be used to verify the SIGs
• Verification decryptzones public key(hash)
  hash of received RRSet

21
Secured query response example
22
Establishing the chain of trust

• How do you trust the key used to Sign an RRset?
• Keys are signed by parents zone
• Verify a Key signature using parent zone key.
• If you trust the parent, great! Else move up the
  tree, up until the root zone.
• Roots public key or at least one trusted key is
  pre-configured in all the resolvers

23
Authenticated denials and replay attacks
temp.vu.nl A?
NXDOMAIN, Signed SOA
cs.vu.nl A?
Victim's machine
Local Server
Records this info
NXTDOMAIN, Signed SOA
Bad guy
24
NXT resource record

• Points to the next domain name in the zone
• also lists what are all the existing RRsets for
  name
• query for popserver.ripe.net would return
• NXDOMAIN, SOA, authority mailbox.ripe.net. NXT
  www.ripe.net. A NXT SIG
• Next query for apple.ripe.net

25
Complete picture Signing a Zone

• Generate the public keys and include them in the
  zone file.
• Sign the zone
• Sort the zone (using canonical names of the
  labels)
• Insert NXT records
• Insert SIG-s containing a signature over each
  RRset made with the zones private key
• Distribute the Public KEY to those that need to
  be able to trust your zone
• Zones private key is kept offline

26
Signed Zone file example
27
DNS Transaction security why is it needed?

• Resolver is a simple application we dont want
  to encumber it with public-key signature
  verification or caching capabilities.
• Local name servers verify signatures and
  authenticated communication between servers and
  resolver.
• Also used between slaves and master name servers
  for zone transfers.

28
Transaction Signature - TSIG

• A keyed hash is applied to the DNS message
  timestamp
• Shared key has to be exchanged using some
  out-of-band mechanism
• RFC 1321 specifies that HMAC-MD5 algorithm be
  used.

29
DNSSEC Issues

• Zone file size has increased tremendously
• Normal address records are 4bytes long
• SIG RRs are at least 128 bytes
• Key RRs for 1024-bit RSA
• DNS traffic increases tremendously due to the
  presence of SIGRRs and KeyRR
• More computation at the name servers for
  verification.
• Key distribution and rollover
• New flavours of DNS security based on symmetric
  key certificates have been suggested.

30
Conclusions

• DNSSEC provides mechanisms to protect DNS and
  solve some vulnerabilities.
• Further work
• DNSSECbis refers to updated DNSSEC published in
  March 2005
• DNSSECbis is considered more practical to be
  deployed
• As of (June 2005) only handful DNSSEC-enabled
  zones existed.
• What are the obstacles?

31
References

• See
• http//www.nic.uk/tech/dnssectest/faq/
• http//www.dnssec.net/
• http//www.dnssec-deployment.org/