Deploying Security for the Domain Name System

1
Deploying Security for the Domain Name System

• Steve Crocker
• Shinkuro, Inc
• steve_at_shinkuro.com

2
Overview

• Attacks via and against the DNS infrastructure
  are increasing
• Attacks are becoming costly and difficult to
  remedy
• A live one detected in March may be out there in
  your forwarders. More on this later.
• Trust in the Internet could decrease.
• The DNSSEC protocol provides a key ingredient in
  the defense against these attacks
• DNSSEC is ready to deploy
• Some service providers have begun operations

3
DNSSEC Status

• DNSSEC standard has been published
• RFCs 4033, 4034 and 4035
• Very well tested, implemented in BIND 9.3.1
• The Swedish Registry (.SE ccTLD) and RIPE reverse
  DNS Registry have deployed DNSSEC in production
• The Dutch registry (.NL) has stated 2006
• Others are close
• Linux/Unix systems provide some client support
• Discussions with Microsoft will probably lead to
  implementation of a client dumb API

4
DNSSEC Deployment Initiative

• DNS is critical to the Internet
• Critical to continuation and to growth
• The U.S. National Strategy to Secure Cyberspace
  (2003) recognized the DNS as a critical weakness
• It called for the Department of Homeland Security
  to coordinate public-private partnerships to
  encourage the adoption of improved security
  protocols
• The DNSSEC Deployment Deployment Coordination is
  a project of DHS Science and Technology it (we)
  contributed to coordination of an international,
  open public-private partnership, the DNSSEC
  Deployment Initiative
• https//www.dnssec-deployment.org

5
The Domain Name System
Root

• DNS database maps
• Name to IP addresswww.dnssec-deployment.org
  63.241.136.206
• 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

com
gov
cctld
agency
co
another
moto
unit
office
6
DNS Examples
.
domain
parent
child
7
DNS Look Up
Root Server
TLD Server
Zone Server
Other Servers

• Important Other servers include
• ISP
• Enterprise
• Exchange
• Public WLAN/hotel

Local DNS Server
"End" system
8
What Does DNSSEC Do?

• Provides an approach so DNS administrators and
  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 fits within the existing server
  infrastructure and user clients

9
Secure DNS Query and Response (simple case)
Root Server
Local Server
myhost.example.com
com Server
myhost.example.com
192.0.2.1 Plus signature for myhost.example.com
End-user
example.com Server
Attacker cannot forge this answer without the
associated private keys.
10
Whats New in DNSSEC?

• DNSSEC adds four new record types
• DNSKEY - carries public key
• RRSIG - carries signature of DNS information
• DS - carries a signed hash of key
• NSEC - signs gaps to assure non-existence
• May add one more, NSEC3
• This would be substituted for NSEC

11
Example of (real) Signed Response
a.ns.se. 172800 IN A 192.36.144.107
a.ns.se. 172800 IN AAAA 2001698930153
a.ns.se. 172800 IN RRSIG A 5 3 172800
20050919180951 ( 20050913070542
10217 se. vtnUJT0yBQNa4G6GfiMmv0l
ty8p5dDcfnnt8nryRRilm
1OoVnOIk93B6UgdDu1FkmBe7VIJlyXtIyPA77y4q3Z
6QA8s4C/AubUg5mpxxOnjFoQUeEaNRSCEcrDex5
K9GW4 7uJbNbHnC3jra4jcVRdUJJUeaw2
e/CUvJBz6bVo ) a.ns.se. 172800 IN RRSIG
AAAA 5 3 172800 20050919174432 (
20050913070542 10217 se.
ZRzot/TQl7YwOxZyhnKaKRobMHM8F8Sm/EI7XScs5xA
8fx3Smtdoad/BGOIkjO293w6FXFpkSTbKjg6d
6BoiCS GaomhQeMrkvSac4DtzuvODaibK
KqArMPbYMFlNPC27L
XxDdy9RVBN2UPllsi5Ft0My23FOgJYURjZknPHM )
Check out drill from Nlnet Labs
12
Attack Example
example
org
Attackers response wins. Second response is
dropped
4g.example.org A?
4g.example.org A 192.0.2.1
User Laptop
Local DNS server
4g.example.org A A 128.9.128.127
Attacker
4g.example.org
13
Recent Attack ISP Cache Poisoning

• DNS cache poisoning is old, but arises in new
  forms
• Symantec products found to be vulnerable in March
  2005
• Microsoft and BIND cache poisoning attacks in
  April 2005
• DNS bots in May 2005
• http//isc.sans.org/presentations/dnspoisoning.php

14
ISP Cache Poisoning - in Essence
Destinations serving Spyware, Spam or Other
Malware
Query bait address
Valid reply false .com server address installed
in ISP server by bug
Destinations
Attackers
End-user
ISP Server
Query any .com address
Cache poisoning
Install malware as well as relay valid reply
(possibly do man-in-the middle too)
15
ISP Cache Poisoning - Impacts

• Documented three waves of attack lucrative
  spam, spyware and click-for-pay outcomes were
  motives
• In addition, in just one of the site samples,
  hundreds of DNS names were poisoned, including
• americanexpress.com, citicards.com, dhl-usa.com,
  fedex.com, walmart.com, sabre.com
• Many more (see report)
• Any of these may have had man-in-the-middle
  attacks such as stolen passwords or intercepted
  traffic
• Not all data was published

16
ISP Attack - Resolution

• Targets were especially service providers (DSL,
  cable) because they tend to run forwarders and
  caching servers
• The attacks were set up for profit
• Meant not to be detected
• One variant failed, its exploit was identified,
  other variants were then found
• Bugs will always arise. One can have fundamental
  protections, or handle them piecemeal
• DNSSEC would have detected this
• This attack almost certainly still running
  undetected in places

17
Real Attack Home Reading

• On our DNSSEC Deployment web site
• http//www.dnssec-deployment.org
• Its 10 PM, do you know where your secondaries
  are?
• (26 Sep 2005)

18
Steps in Deployment

• To get DNSSEC in place for protection, there are
  infrastructure requirements and costs.
• Local steps
• Sector steps
• Deployment should not await global action, though
  zones are most protected when there is global
  DNSSEC

19
Islands of Trust in DNSSEC
Root
example

• DNSSEC provides for
• Incremental adoption anywhere in the hierarchy
• Production use at early stages
• Out-of-band distribution of zone public keys
• Pictured the blue zones can do DNSSEC among
  themselves
• Detect attacks against their communications

gov
cctld
com
another
co
agency
moto
unit
office
20
End Systems Perspective - Early DNSSEC Deployment
DNSSEC-capable
Root Server
TLD Server
Zone Server
Cache Servers

• End systems are harmed by infrastructure attacks
  outside their frame of reference
• DNSSEC initial deployment in service providers
  (mostly not in end systems) is effective
• Transition of end systems and applications can
  follow

"End" system
Local DNS Server
21
DNSSEC Operations

• Each DNS zone signs its data with a private key
• Signing is done with zone data preparation
• Update is incremental (new record does not
  require signing of whole zone)
• The operator must plan key management
• The key generation, testing tools, and guidelines
  exist
• Operational experience is still rare
• The parent zones must obtain and sign child DS
  records
• This is the chain of delegation
• If there is a registrar-like function, this
  interaction needs to become DNSSEC-capable

22
DNSSEC Cost

• A number of studies of DNSSEC performance,
  carefully characterizing by shadowing and by
  thoughtful modeling
• Look for references on www.dnssec-deployment.org
  (google search box coming)
• Adds about small multipliers to size of packets
  and memory footprints
• Public key encryption-side (slow) is pre-computed
• Still, security has costs
• Risk-benefit is an important metric
• Cost if this security is not applied

23
DNSSEC Users

• Phasing in of end systems
• Some end systems use binary responses (simple
  API)
• Some end systems make no DNSSEC transition or
  only a very late one
• Some end systems authenticate responses with
  trusted key(s)
• At least one trusted public key is
  pre-configured, more in islands of trust
• Validation is done with pre-configured key or
  keys learned via a sequence of queries to the
  root (but this may never be done by an
  application, only by a server on the
  user/applications behalf)
• DNSSEC has much protective value while the end
  system benefits are still being settled, as long
  as at least some simple APIs appear
• Several potential cost-benefits emerge here
• ENUM, Domain-Key, SRV and other DNS uses in SIP,
  GSM

24
Operational Guidelines Online

• A number of guides (though not yet turn-key) are
  out there now. The Operational Guidelines page
  (http//www.dnssec-deployment.org/og.php) charts
  these, including
• NIST Secure Domain Name Systems Operation Guide
• RIPE DNSSEC How To
• IETF DNSOP DNSSEC Operational Practices
• More are in the pipeline. Other sites to go to
• http//www.dnssec.org
• http//www.nlnetlabs.nl/dnssec/
• http//www.dnssec-tools.org

25
DNSSEC - Summing up

• Both the loss from the attack and trust are
  rising
• While cost to attackers is low or nothing
• Costs of software, performance, operational
  changes, coordination
• Versus the risk-benefits
• DNSSEC deployment decisions that are occurring
  show this equation is starting to tip
• Questions?
• Im steve_at_shinkuro.com
• http//www.dnssec.org
• http//www.dnssec-deployment.org

26
Acknowledgements

• Shinkuro colleagues Allison Mankin and Amy
  Friedlander co-authored these materials.
• Our work is supported under contract with U.S.
  Department of Homeland Security, Science and
  Technology, HSARPA
• The DNSSEC Deployment Working Group has provided
  discussions, ideas, themes and in some cases,
  graphics used here. A partial list to thank Olaf
  Kolkman, Ed Lewis, Bill Manning, Dan Massey, Russ
  Mundy, and Marcus Sachs