Domain Name System Security

Extensions
(DNSSEC)

USTTI Workshop
October 2010

Presented by:
Steve Conte (conte@isoc.org)
The Internet Society
http://www.isoc.org
 Domain Name System

•  Critical part of the Internet Infrastructure

•  Converts names to IP address and vice
versa
•  Hierarchal data type (tree model)
•  Relies heavily on caching to avoid asking
the same query over and over
•  Efficient but unprotected
•  No method to authenticate and answer

http://www.isoc.org
 DNS Exploits

The Man in the Middle

o  You send out a DNS query

o  Before the Authoritative resolver answers,
your query is intercepted and answered by a
resolver claiming to be authoritative
o  Your resolver will accept the first answer back
that it receives
o  Not all of these are malicious. Some hotels
or public Internet access points will try to be
“helpful”

http://www.isoc.org
 DNS Exploits

Cache Poisoning

o  You send out a DNS query

o  The response you get returns the requested
data
o  The response includes data in the
“additional” section that includes bogus data
to another zone
o  The “additional” section is usually used to
send “glue” data.. Required information that
is not within the zone that’s responding

http://www.isoc.org
 Enter DNSSEC

•  Authenticates the origin of an answer to a

DNS query via keys that are recorded one
layer up in the DNS hierarchy
•  This layer of keys (trust anchors) creates a
Chain of Trust that will eventually move all
the way up to the root zone

http://www.isoc.org
 DNS Data Flow
Points of attack
zone
file
(text,
MASTER
DB)‫‏‬
DATA

caching
STUB resolver Zone dynamic
resolver (recursive)‫‏‬ Transfer updates

SLAVES
SLAVES
VECTORS
ATTACK

man in spoofing
the cache modified master spoofed
poisoning data updates corrupted
middle (routing/DoS)‫‏‬
data

http://www.isoc.org
 Fighting the good fight

•  If data is received that is not signed

(assuming that you have DNSSEC aware
software), it will discard the information or
notify you that it is receiving non-signed
data
•  Because keys are placed one level up in
the DNS hierarchy, there is no way for a
response to be “spoofed”, thus creating
the Chain of Trust
http://www.isoc.org
 DNSSEC

•  Created out of the DNS Extensions working

group of the IETF
•  “Defining” documents were published in
March 2005:
–  RFC 4033
–  RFC 4034
–  RFC 4035
–  RFC 5155 (Mar 2008) which among some other
items, introduces the NSEC3 resource record
which provides methods to avoid “zone walking”

http://www.isoc.org
 DNSSEC: Preventative Medicine

By receiving signed answers to a DNS

query, the end user (local resolvers) has
established a Chain of Trust. This
accomplishes the following:
•  User knows that the data sent is from the source
that was originally queried (authenticated)
•  User knows that the data that is sent is what the
sender intended you to receive

http://www.isoc.org
 What DNSSEC Doesn’t Do

•  DNSSEC isn’t a silver bullet

•  Will not prevent bad data
•  Will not encrypt data
•  Will not stop DDoS attacks (though could
help in post-analysis)
•  Won’t do the laundry

http://www.isoc.org
 Deploying DNSSEC

•  Install a DNSSSEC “aware” resolver

–  Bind, Unbound, NSD, ANS, CNS, Secure64
DNS, etc
•  Some supply tools to sign zones and
records
•  Try a test-bed resolver to gain comfort in
managing DNSSEC prior to putting on
production server

http://www.isoc.org
 Planning

•  Planning your DNSSEC process will make

the rollout much smoother
•  Key Management is not entirely an
automated event
•  Protect your keys (KSK and ZSK)
•  Create a procedure to roll the keys on a
regular basis
•  Plan (and test!!) a process to perform an
emergency key rollover

http://www.isoc.org
 The Ground, Up

•  Sign your zone

•  If your TLD is signing their zone, coordinate with
them (or your registrar) on submitting your key
•  If your TLD hasn’t started signing their zone yet,
ask them what their plan is
•  The more zones that are signed shows that people
are embracing DNSSEC
•  ICANN to have root zone signed and operational
by 01 July 2010
–  They were close! The root was officially signed and
published on 15 July 2010

http://www.isoc.org
 Workshop Overview

09:30 – 10:30 The Organisations of the Internet

10:30 – 12:00 The IETF
12:00 – 13:00 Lunch
13:00 – 14:00 Internet Collaboration
14:00 – 15:00 DNSSEC
15:00 – 15:15 Break
15:15 – 16:15 IPv4, IPv6 and Address Allocation
16:15 – 17:30 Open Forum for Topical Discussions

http://www.isoc.org