CS Lecture 22 DNS Security

CS 557 - Lecture 22

DNS Security

DNS Security Introduction and Requirements,

RFC 4033, 2005

•  Virtually every application uses

the Domain Name System (DNS).

•  DNS database maps:

–  Name to IP address

www.darpa.mil = 128.9.176.20 –  And many other mappings

(mail servers, IPv6, reverse…)

•  Data organized as tree structure.

–  Each zone is authoritative for its local data.

Root

edu

mil

ru

darpa

isi

af

mil

nge

_andrews

DNS Query and Response

www.darpa.mil A?

www.darpa.mil

A 128.9.128.127

Actually www.darpa.mil = 192.5.18.195.

But how would you determine this?

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.

A Simple DNS Attack

www.darpa.mil A?

www.darpa.mil

A 128.9.128.127

Easy to observe UDP DNS query sent to

well known server on well known port.

www.darpa.mil

A 192.5.18.19

First response wins. Second response is

silently dropped on the floor.

A More Complex Attack

Routing Based DNS Attacks

Internet

•  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.

ISPs announced new path for 20 minutes to 3 hours

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.

DNS Security Extensions

Cryptography is like magic fairy dust,

we just sprinkle it on our protocols

and its makes everything secure

Secure DNS Query and

Response

www.darpa.mil

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

darpa.mil. 81020 IN DNSKEY

256

3 1 (

Base64 encoding of pub key

)

darpa.mil. 81020 IN RRSIG

DNSKEY

1 3 86400 20040226023910 (

20040127023910 569 mil.

Base 64 encoding of signature

)

name TTL class DNSKEY

FLAGS PROTOCOL

Algorithm

public key

Note the darpa.mil DNSKEY is signed by the mil private key (We later show why this doesn’t work)

name TTL class RRSIG

type_covered

Algorithm labels TTL expiration (

inception dates key_tag key_name signature )

www.darpa.mil. 82310

IN A 192.5.18.195

www.darpa.mil. 82310 IN RRSIG

A

1 4 86400 20040226023910 (

20040127023910 468 darpa.mil.

Authenticated Denial of

Existence

•

What if the requested record doesn’t 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 don’t trust (all) of their secondary

servers.

•  Can’t control which server a resolver contacts.

– 

Some zones don’t have compuational resources to

sign on the fly

NSEC Records

Caching DNS Server

End-user

foo.isi.edu. ?

foo.isi.edu. does not exist

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

a.isi.edu RRSIG NSEC ….

Authoritative DNS Servers

Solution:

Zone Walking and Monitoring

Caching DNS Server

End-user

foo.colostate.edu. ?

foo.colostate.edu. does not exist

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

a.colostate.edu RRSIG NSEC ….

Authoritative DNS Servers

Solution:

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

•  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

mil DNS Server

darpa.mil DNS Server

darpa.mil NS records

www.darpa.mil A record

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

darpa.mil DNSKEY (pub key 1)

darpa.mil DNSKEY (pub key 2)

darpa.mil RRSIG(A) by key 1

darpa.mil DS record (hash of pubkey 1)

darpa.mil SIG(DS) by mil private key

Can Change mil key without notifying darpa.mil

Can Change key 2 without notifying .mil

DNS Key Signing Key Roll-Over

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

darpa.mil DS record (hash of pubkey 1)

darpa.mil RRSIG(DS) by mil private

key

darpa.mil DNSKEY (pub key 3)

darpa.mil RRSIG(A) by key 3

darpa.mil DS record (hash of pubkey 3)

darpa.mil RRSIG(DS) by mil private

key

Objective: Replace

DNSKEY 1

with new DNSKEY 3

darpa.mil RRSIG(A) by key 1

darpa.mil RRSIG(A) by key 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.

Hidden DS Denial of Service

• 

DS Record is Stored Only at the Parent.

–  What if you ask ucla.edu for the ucla.edu DS?

• 

Early BIND Implementation Choice:

–  Server says “I’m 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:

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 can’t distinguish between the set

stored at the child and the set stored at the parent.

• 

DNSSEC Solution:

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 can’t sign NS set.

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.

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”

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

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

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)

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?

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

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

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….

Minimum and Maximum

Values

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

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

Addressing Lifetimes & Replays

•  With sufficient prediction, vulnerable records

can be avoided

–  Make signature lifetime match data lifetime

•  Dramatic Improvement Coincided With

Monitoring

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

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

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.