CS 557 - Lecture 22

DNS Security
DNS Security Introduction and Requirements,
RFC 4033, 2005

Fall 2013

The Domain Name System

Virtually every application uses
Root

the Domain Name System (DNS).

DNS database maps:
edu

Name to IP address

mil

ru

www.darpa.mil = 128.9.176.20
And many other mappings

isi

darpa

af

(mail servers, IPv6, reverse)

Data organized as tree structure.

Each zone is authoritative
for its local data.

nge

andrews

mil

DNS Query and Response

www.darpa.mil A?

End-user

www.darpa.mil
A 128.9.128.127

Root DNS Server

Caching
DNS Server

mil DNS Server

Actually www.darpa.mil = 192.5.18.195.

But how would you determine this?
darpa.mil DNS Server

DNS Vulnerabilities
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.

A Simple DNS Attack

Easy to observe UDP DNS query sent to
well known server on well known port.
www.darpa.mil A?

Root DNS Server

www.darpa.mil
A 192.5.18.19
Joes
Laptop

www.darpa.mil
A 128.9.128.127

Caching
DNS Server

mil DNS Server

Dans
Laptop

First response wins. Second response is

silently dropped on the floor.

darpa.mil DNS Server

A Response
More Complex Attack

Secure64
Caching Server

www.attacker.com
attacker.com
attacker.com
ns.attacker.com
www.google.com

www.google.com
= 128.9.128.127

A 128.9.128.127
NS ns.attacker.com
NS www.google.com
A 128.9.128.2
A 128.9.128.127
ns.attacker.com
Query
www.attacker.com

Query www.google.com

Secure64 Laptop

Remote attacker

Routing Based DNS Attacks

BGP Also Provides No Authentication
Faults and attacks can mis-direct traffic.
One (of many) examples observed from BGP logs.
Server could have replied with false DNS data.
originates route to
192.26.92/24
ISPs announced new path
for 20 minutes to 3 hours

Internet
BGP
monitor

c.gtld-servers.net
192.26.92.30

The Problem in a Nutshell

Resolver can not distinguish between
valid and invalid data in a response.
Idea is to add source authentication
Verify the data received in a response is equal to
the data entered by the zone administrator.
Must work across caches and views.
Must maintain a working DNS for old clients.

DNS Security Extensions

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

Secure DNS Query and

Response
Caching DNS Server

www.darpa.mil
Authoritative DNS Servers
End-user

www.darpa.mil =
192.5.18.195
Plus (RSA) signature by the
darpa.mil private key

Attacker can not forge this answer

without the darpa.mil private key.

Authentication of DNS
Responses
Each 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.

Learning DNS Public Keys

Public key is required to verify signature
RRSIG record identified the key name and key tag.
If you are pre-configured with key, then done.
UCLA resolver is configured with the ucla.edu key

Typical resolver does not have all the public keys.

Configure root key and perhaps some local keys
Query zone for the desired public
Query returns DNSKEY record and a signature from the
parent zone.

Example DNSSEC Records

name TTL class RRSIG type_covered Algorithm labels TTL expiration (
inception dates key_tag key_name signature )
www.darpa.mil. 82310
www.darpa.mil. 82310

IN A 192.5.18.195
IN RRSIG A 1 4 86400 20040226023910 (
20040127023910 468 darpa.mil.
Base 64 encoding of signature )

name TTL class DNSKEY FLAGS PROTOCOL Algorithm public key

darpa.mil. 81020
darpa.mil. 81020

IN DNSKEY 256 3 1 ( Base64 encoding of pub key )

IN RRSIG DNSKEY 1 3 86400 20040226023910 (
20040127023910 569 mil.
Base 64 encoding of signature )

Note the darpa.mil DNSKEY is

signed by the mil private key
(We later show why this doesnt work)

Authenticated Denial of
Existence
What if the requested record doesnt exist?
Query for foo.isi.edu returns No such name
How do you authenticate this?

Must meet a variety of operational constraints

Some zones refuse to store any keying information
online.
Some zones dont trust (all) of their secondary
servers.
Cant control which server a resolver contacts.

Some zones dont have compuational resources to

sign on the fly
Cant predict user would ask for foo.isi.edu

NSEC Records
Solution:
sign next name after a.isi.edu. is g.isi.edu.
foo.isi.edu. ?

Caching DNS Server

Authoritative DNS Servers

End-user

foo.isi.edu. does not exist

a.isi.edu NSEC g.isi.edu.
a.isi.edu RRSIG NSEC .

There is no magic fairy dust

Zone Walking and Monitoring

Solution:
sign next name after a.colostate.edu. is g.colostate.edu.
foo.colostate.edu. ?

Caching DNS Server

Authoritative DNS Servers

End-user

foo.colostate.edu. does not exist

a.colostate.edu NSEC g.colostate.edu.
a.colostate.edu RRSIG NSEC .

Revising DNS Key

Management
Operational Problems in RFC 2535 DNSSEC
USC/ISI led one of the first multi-administion testbeds.
Identified fundamental key management & scaling issues.
Revision now at the end of the standards process
Provide a coherent design that meets needs of vendors/operators
Currently co-editor of the IETF revision [1].

Basic Principles Behind the DNS Revision

The DNS succeeded by de-coupling zones.
But authentication chains require coordination.

Store a hash (copy) of the child key at the parent.

Overcomes the DNS atomic RRset problem.
Manages authentication chains using operations similar to those
currently used for maintaining server chains.

Revised DNS Key Management

Can Change mil key without
notifying darpa.mil

darpa.mil NS records

darpa.mil DS record (hash of pubkey 1)

darpa.mil SIG(DS) by mil private key
mil DNS Server
darpa.mil DNS Server

darpa.mil DNSKEY (pub key 1)

darpa.mil DNSKEY (pub key 2)
darpa.mil RRSIG(A) by key 1

www.darpa.mil A record
www.darpa.mil RRSIG(A) by key 2

Can Change key 2 without

notifying .mil

DNS Key Signing Key Roll-Over

darpa.mil DS record (hash of pubkey 3)
darpa.mil RRSIG(DS) by mil private
key
darpa.mil DS record (hash of pubkey 1)
darpa.mil RRSIG(DS) by mil private
key
mil DNS Server
darpa.mil DNS Server

darpa.mil DNSKEY (pub key 1)

darpa.mil DNSKEY (pub key 2)
darpa.mil DNSKEY
key13)
RRSIG(A)(pub
by key
darpa.mil RRSIG(A) by key 31
darpa.mil RRSIG(A) by key 3

}
}}

Objective: Replace
DNSKEY 1
with new DNSKEY 3

Minimal Requirements

Parent must indicate how to reach the child.

NS records at parent MUST identify at least one
valid name server for child.

Parent must identify a trusted key at child.

DS record at parent MUST match a valid KEY
stored at the child.

Protocol Complications
Building on an existing system
Objective is to strengthen the system.
But additions also add stress to weak points.

Some example cases:

Denial of service added by the DS record.
NS records stored at the parent.
Over use of the KEY record.

Hidden DS Denial of Service

DS Record is Stored Only at the Parent.
All DS records should be sent to parent.
What if you ask ucla.edu for the ucla.edu DS?

Early BIND Implementation Choice:

Server says Im not authoritative for this data.
Resolver hears Not authortitative for ucla.edu

The Resulting Under-Specification Attack

Ask resolver to send DS query to each ucla.edu server.
Each server declared not authortiative for ucla.edu!
Query for www.ucla.edu now returns:
cache says all ucla.edu servers are broken

Flaws in the DNS Design (glue)

Parent (edu) stores NS records for child (isi.edu)
Provides a hint on how to reach the child

Child also stores a copy of the same NS RRset.

Child (isi.edu) is the authoritative source.

Implications for Authentication:

Parent is not the authoritative source of the data.
Child data is not available if parent is wrong.
Resolver/cache cant distinguish between the set
stored at the child and the set stored at the parent.
DNSSEC Solution:
Only the child signs its NS RRset

NS records stored at the

Parent
Edu server stores NS records for ucla.edu
Tells a resolver where to find ucla.edu servers.

Ucla.edu server also stores ucla.edu NS set.

Ucla.edu is the authoritative source.
Parent and child differ due to various reasons
SeePappas SIGCOMM 2004

Loose coordination works since only requires

some overlap in parent/child NS.
Security assumes identical.
Security also says parent cant sign NS set.
Parent is not the authoritative source of the data.

Over Use of KEY Record

Original KEY record used for DNSSEC
and IPSEC, email, TLS, etc.
Resolver looking for DNSSEC key gets all
possible keys.
Data (ipsec key) should be separate from control
(DNSSEC) key.
Fixed in RFC 3449 that limits KEY to DNSSEC.

Wild Cards
Authenticated denial further complicated by
wildcards.
Must prove b.darpa.mil does not exist
Must also prove no wildcard would match.

Algorithm for computing necessary wildcards

now available in revised specification.
Pathological cases require many NXT records.
Motivates one further change

Proposal to add bit indicating:

next (signed?) name after a is c
and no wildcards apply in between

Moving DNSSEC to the End Host

DNS security design worked with DNS resolvers and servers.
Default was to send DNSSEC data.
Verified old resolvers and servers ignore it.

But DNS interacts with many other pieces.

Firewalls did not ignore the extra records.

Our subcontract was blackholed by DARPA.

DARPA firewall thought the SIG records were an attack!

DNSSEC OK bit added to protocol

Resolver sets this bit indicated DNSSEC data is okay.

Who is Deploying DNSSEC?

Monitoring Started From Close to Day One
DNSSEC RFCs published in March 2005
Monitoring launched in October 2005

Find Zones Using Crawling and User Submissions

Continually crawl DNS looking for secure zones
Allow users to submit the names of secure zones

DNSSEC Deployment

Oct 16, 2007: 10,319 Secure Zones

Deployment Observations
(Undirected) Crawling DNS Finds Few Secure Zones
Vast DNS + tiny DNSSEC => low (near 0) hit rate for
crawler
User Submissions Drive Current Monitoring
SecSpider is well publicized => high submission rate
Augment secure zones with parent/child and popular sites

Trend is positive, but still very small deployment overall

Some top level domains deploying or deployed (e.g. se
zone)
Not yet at critical mass for DNSSEC

A Closer Look at Secure

Zones
Monitor Closely Tracks All Secure Zones
Frequent Queries to Monitor Changes
Exploit DNSSEC zone walking
Still tractable due to relativley small DNSSEC deployment

Monitoring Reveals Many Challenges

DNSSEC deployment is not simple after all
Challenge in Islands of Security
Challenge in Key Management
Challenge in Preventing Replays

Challenge 1: Islands of Security

DNS relies on the tree herarchy to learn public keys
Everyone knows root public key
But how would this happen and who manages it?

Root key used to sign edu public key

But neither root or edu have public keys now.

edu key used to sign colostate.edu key

But no hierarchy leads to the public key?

How does a resolver learn a secure zones public key?

Challenge 1: Islands of Security

Island of Security: DNS sub-tree where every zone in the
sub-tree has deployed DNSSEC
Design envisioned a single island of security
All zones deploy DNSSEC and manually configure the root key

Monitoring reality shows disconnected deployments

DNSSEC deployed in isolated subtrees and must manually
configure the public key for each island of security

Islands of Security

Vast majority of secure zones are

single zone islands.
Small number of large islands
but this includes testbeds.

Addressing Islands of Security

Deploy DNSSEC at all zones or at least from root down
Has yet to happen operationally..

Develop an Alternative PKI?

DLV provides some service to store and report public keys

Can we trust the public keys visible at the monitor?

Must ensure keys came from monitor
Must ensure monitor was not tricked
But can rely on distributed services and checking by actual
admins.

Challenge 2: Key Management

Design is Relatively Simple, But Operations are complex
Establish key pair and sign the zone
Relatively straight-forward, but issues below add challenges..

Establish an Authentication Chain with a Secure Parent

Cross-domain coordination with a different administration

Update the key pair periodically

Due to planned changes or key compromise

Simple concept of parent private key signs the child public key.
But many complex details

Minimum and Maximum

Values

Average Key Lifetimes

Addressing Key Management

Manual operation of complex steps is unrealistic
Need to improve management tools and increase automation
Possible, but need to overcome off-line key issues

Match operations with monitoring

Must have monitoring to provide external view of zone
Must have some form of correctness check
Monitoring data can aide in the automation process by checking which
steps have been done
Ex: detect when the DS record at the parent has changed

Challenge 3: Lifetimes&Replays
Each cryptographic signature has a fixed lifetime
Ex: Signature for www.colostate.edu edu expires on Oct 31.

What if the addresses changes today?

Actions Taken in the DNS

Server removes changed record and replaces with new copy
But attacker can still replay the old record and signature

Vulnerable Records: data has changed, but the signature on

old copy has not yet expired
Vulnerable records can be replayed and resolver will
authenticate the old copy

Vulnerable DNS Record Sets

Addressing Lifetimes & Replays

With sufficient prediction, vulnerable records
can be avoided
Make signature lifetime match data lifetime

Dramatic Improvement Coincided With

Monitoring
Vulnerable records greatly reduced in current data

The Role of Monitoring

Monitoring is essential is large-scale systems
Monitoring illustrates extent of known issues in deployment
Monitoring identifies new challenges in deployment

SecSpider Monitoring Benefits DNSSEC

Illustrates progress and documents scale of known issues
Identifies new challenges
Allows zone admins to see how others perceive them
Various examples of how monitoring led to changes

Monitoring is the solution to many challenges

Future Directions
Challenge 1: Islands of Security
Monitor can be used to bootstrap public key information
Challenge is to authenticate public keys came from monitor and
limit chance monitor data is subverted by attacer
Challenge 2 and 3: Cryptographic Management
Given an external view of data, zone admins can adapt
Monitoring can verify key management is working
Monitoring can aide in automating DNS key management
Current work is using SecSpider data to identify new challenges and
practically solve existing challenges

http://secspider.cs.ucla.edu

Summary
DNSSEC is useful example.
Protocol evolved when it hit operations.
Lesson highlight flaws
So do we abandon DNSSEC?

The solution is multiple fences.

If DNSSEC is the solution, it failed.
If DNSSEC is part of the solution, it succeeds.