DNS Workshop @CaribNOG12 Mark Kosters Carlos Martnez {ARIN, - - PowerPoint PPT Presentation

DNS Workshop @CaribNOG12

Mark Kosters – Carlos Martínez {ARIN, LACNIC} CTO

DNS Refresher and Intro to DNS Security Extension (DNSSEC)

Outline

• Introduction
• DNSSEC mechanisms

– to establish authenticity and integrity of data

• Quick overview
• New RRs
• Using public key cryptography to sign a single

zone

• Delegating signing authority ; building chains of

trust

• Key exchange and rollovers
• Conclusions

DNS Resolving

Resolver Question: www.arin.net A

www.arin.net A ?

Caching forwarder (recursive) root-servers

www.arin.net A ? “go ask net server @ X.gtld-servers.net” (+ glue)

gtld-servers

www.arin.net A ? “go ask arinserver @ ns1.arin.net” (+ glue)

arin-server

www.arin.net A ? “192.168.5.10” 192.168.5.10 1 2 3 4 5 6 7 Add to cache 9 8 10 TTL

DNS: Data Flow

master Caching forwarder resolver

Zone administrator

Zone file Dynamic updates

1 2

slaves

3 4 5

DNS Vulnerabilities

master Caching forwarder resolver

Zone administrator

Zone file Dynamic updates

1 2

slaves

3 Server protection 4 5

Corrupting data Impersonating master Unauthorized updates Cache impersonation Cache pollution by Data spoofing

Data protection

DNS Protocol Vulnerability

• DNS data can be spoofed and corrupted on

its way between server and resolver or forwarder

• The DNS protocol does not allow you to check

the validity of DNS data

• Exploited by bugs in resolver implementation

(predictable transaction ID)

• Corrupted DNS data might end up in caches and

stay there for a long time (TTL)

• How does a slave (secondary) knows it is

talking to the proper master (primary)?

Motivation for DNSSEC

• DNSSEC protects against data spoofing

and corruption

• DNSSEC (TSIG) provides mechanisms to

authenticate servers

• DNSSEC (KEY/SIG/NXT) provides

mechanisms to establish authenticity and integrity of data

• A secure DNS will be used as a public key

infrastructure (PKI)

Now for the Meat

l We will be talking now how to solve

cache pollution

l It is quite complicated

Overview

l

We will talk about:

è

The problems that DNSSEC addresses

èThe protocol and implementations èThings to take into account to deploy DNSSEC èThe practical problems tied to real-world deployment

Contents

l

Scope of the problem

lDNS reminders lBasics of DNSSEC lDeployment & operations lIssues (what isn't solved) & other aspects lStatus of DNSSEC today

What's the problem?

So what are the issues?

DNS Cache Poisoning

−Forgery: respond before the intended nameserver −Redirection of a domain's nameserver −Redirection of NS records to another target domain

DNS Hijacking

−Response to non-existent domains −Rogue DNS servers

These have been spotted in the wild – code IS available...

MX hijacking

What's the problem?

What risks ?

l l

See Dan Kaminsky's slides for the extent of the risks

• MANY case scenarios

è èEntire domain redirection èTake a large .COM offline èComplete spoofing of a bank's DNS info èMore fun stuff

A great illustrated guide

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

Refresher

DNS reminders

l

ISC BIND zone file format is commonly used, and we will use this notation here.

• zone. SOA nsX.zone. hostmaster.zone.

( 2009022401 ; serial 1d ; refresh 12h ; retry 1w ; expire 1h ) ; neg. TTL

NS NS MX

A

ns.zone. ns.otherzone. 5 server.otherzone. 1.2.3.4 zone. zone. www.zone. ...

DNS reminders

l

Record structure:

NAME [TTL] TYPE DATA (type specific)

• host.zone. 3600 A 10.20.30.40

sub.zone. 86400 MX 5 server.otherzone.

DNS reminders

l

Multiple resource records with same name and type are grouped into Resource Record Sets (RRsets):

mail.zone. mail.zone. server1.zone. server1.zone. server1.zone. MX MX A A A 5 server1.zone. 10 server2.zone. 10.20.30.40 10.20.30.41 10.20.30.42 server1.zone. server1.zone. AAAA 2001:123:456::1 AAAA 2001:123:456::2 server2.zone. A 11.22.33.44 RRset RRset RRset RRset

DNS points of attack

DATA ATTACK VECTORS

STUB

resolver

caching resolver

(recursive) MASTER SLAVES

DNS Data Flow

Points of attack zone file

(text,

DB)

dynamic updates man in the

middle cache

poisoning modified

data Zone

Transfer

spoofing master

(routing/DoS) spoofed updates corrupted

data

DNSSEC concepts

DNSSEC quick summary

l

Data authenticity and integrity by signing the Resource Records Sets with a private key

lPublic DNSKEYs published, used to verify the

RRSIGs

lChildren sign their zones with their private key

−Authenticity of that key established by signature/checksum by the parent of the (DS) delegation signer record

l

Repeat for parent...

lNot that difficult on paper

−Operationally, it is a bit more complicated

DNSSEC overview

DNS SECurity extensions

l

Concepts

lNew Resource Records (DNSKEY, RRSIG,

NSEC/NSEC3 and DS)

lNew packet options (CD, AD, DO) lSetting up a Secure Zone lDelegating Signing Authority lKey Rollovers

DNSSEC concepts

l

Changes DNS trust model from one of ”open” and ”trusting” to one of ”verifiable”

lExtensive use of public key cryptography to provide:

−Authentication of origin −Data integrity −Authenticated denial of existence

l

No attempt to provide confidentiality

lDNSSEC does not place computational load on the

authoritative servers ( != those signing the zone)

lNo modifications to the core protocol

−Can coexist with today's infrastructure è…kind of (EDNS0)

DNSSEC concepts

l

Build a chain of trust using the existing delegation- based model of distribution that is the DNS

l

Note: the parent DOES NOT sign the child zone.

The parent signs a pointer (hash) to the key used to sign the data of child zone (important!)

lDon't sign the entire zone, sign a RRset

ORG NSRC WS “.”

New Resource Records

Implementing the Trust Chain

• New resource records

– RRSIG: resource record signatures – DNSKEY: DNS public key – DS: delegation signature – NSEC: denial of existence

New Resource Record: RRSIG

• Example:

27

~ carlosm$ dig +dnssec www.nic.se dig +dnssec www.nic.se ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; ANSWER SECTION: www.nic.se. 60 IN A 212.247.7.218 www.nic.se. 60 IN RRSIG A 5 3 60 20101021132001 20101011132001 23369 nic.se. HeeUZ5h5iExK5uU1SuNRIf2Dbmh2/ aWV8FkjmzixUzTAVrHv39PfmfnG DHdHoZxoz85hqqYiWb +t9EZh5+iqxQk8AxRDic9Nn6WxifOoWeS+IUKQ rVyqXf1NtkZvu1A325vwa8obtbeVGVkhqg6bDIjKYeHixjlQ4cRoFcEW Izk= ;; AUTHORITY SECTION: nic.se. 2974 IN NS ns3.nic.se. nic.se. 2974 IN NS ns2.nic.se. nic.se. 2974 IN NS ns.nic.se. nic.se. 3600 IN RRSIG NS 5 2 3600 20101021132001 20101011132001 23369 nic.se. GSzAUC3SC3D0G/ iesCOPnVux8WkQx1dGbw491RatXz53b7SY0pQuyT1W eb063Z62rtX7etynNcJwpKlYTG9FeMbDceD9af3KzTJHxq6B+Tpmmxyk FoKAVaV0cHTcGUXSObFquGr5/03G79C/YHJmXw0bHun5ER5yrOtOLegU IAU=

New Resource Record: DNSKEY

• Example:

28

aruba:~ carlos$ dig @8.8.8.8 DNSKEY lacnic.net. ;; Truncated, retrying in TCP mode. ;; QUESTION SECTION: ;lacnic.net. IN DNSKEY ;; ANSWER SECTION: lacnic.net. 6272 IN DNSKEY 257 3 8 AwEAAb6YDZrhzHo3gu48uNvxFpvQ/I0TvaqGlYFE9VkplBkexiXwMHfm BVZF4SU7zSBcdX23jnotHmJd6Jicbhpk0ZVXS5szwbuC2TXaifx6bTOj fd0z8/zsk62tpvGDROQVgOTUNKmb1oZamX2Vm4Q58oFXQKkZm21sCeuR 6KhZo+pDkUWlDgI/gPLj1MFiorN9EWjUWbfHnnwVAldD6ftZ6KmhWlxm 7ynJ4Q3Glu5BX8ySh6l5JdFNyoVltfPXrwXJ4nqEaAEmPo8Vic++V3l5 2aQIgUnLmZ6mdfOxCT/YGcMIqUaiXRA0CpOMUr+K7GIvJIVyacOzIfe0 FKV/MreaVOk=

Trust Chains

• How do clients verify a zone's RRSets?

– It queries for the corresponding DNSKEY – The necessary computations are carried

• ut and then compared with the

signature in the RRSIG

• If they match the signatures are valid
• But, how can we trust the DNSKEY? It

listed on the same zone we want to verify!

– We need to validate the trust chain

29

Trust Chains (ii)

• DS Record “Delegation Signature”

– DS records "sign" the keys in their child zones – In this way one can also verify the DNSKEY as it is signed when the parent zone is signed

• DS records contain a hash of the

public key

– That is a hash of the DNSKEY's record content

• DS records in the parent zone are

30

New Resource Record: DS

• Example:

31

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 DS lacnic.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 68 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;lacnic.net. IN DS ;; ANSWER SECTION: lacnic.net. 21599 IN DS 57814 8 1 10B742924448BD70481CACDDB1D21E5B0DBC8802

Denial of Existence

• What happens when you ask DNS

about something that does not exist?

– NXDOMAIN!

• However, in an NXDOMAIN response

the ANSWER section is empty, there is nothing to sign

• Remember: negative answer are also

cached, so they can be a DoS vector

Negative Responses

• Sample NXDOMAIN response:

33

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 A holy-molly.lacnic.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6541 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;holy-molly.lacnic.net. IN A ;; AUTHORITY SECTION: lacnic.net. 1799 IN SOA NS.lacnic.net. Hostmaster.lacnic.net. 2014090443 7200 3600 648736 172800

Signed Negative Responses

• Sample signed NXDOMAIN response:

34 aruba:~ carlos$ dig +dnssec @8.8.8.8 A holy-molly.lacnic.net. ; <<>> DiG 9.8.3-P1 <<>> +dnssec @8.8.8.8 A holy-molly.lacnic.net. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47977 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;holy-molly.lacnic.net. IN A ;; AUTHORITY SECTION: lacnic.net. 1426 IN SOA NS.lacnic.net. Hostmaster.lacnic.net. 2014090443 7200 3600 648736 172800 lacnic.net. 1426 IN RRSIG SOA 8 2 7200 20141028162504 20140928152504 25014 lacnic.net. EMkejVSEa3CvVzA2e3ap1n7QlgVUEPonIeBH4vcWjk..(snip) lacnic.net. 21226 IN NSEC 18.lacnic.net. A NS SOA MX AAAA RRSIG NSEC DNSKEY TYPE65534 lacnic.net. 21226 IN RRSIG NSEC 8 2 172800 20141018160452 20140918155519 25014 lacnic.net. JivHI2aMXlX1l9cL5L+33LH/HlJb8JPvasGi85..(snip) ftp.lacnic.net. 21226 IN NSEC d.in-addr-servers.lacnic.net. CNAME RRSIG NSEC ftp.lacnic.net. 21226 IN RRSIG NSEC 8 3 172800 20141018152542 20140918142919 25014 lacnic.net. XeUME57RIh5g4HyPZUG+RPUNBZVc+wxXq6Thtj8Q5nkkN +UoBuVcFeOQ UpM5ycNxMHPASgdplJlsQ2q28U85OZftVDxsILSTUg9…(snip)

Using DNSSEC

Response Validation

• Signing zones is just half of the picture
• For DNSSEC to be actually useful,

responses need to be validated

• This is the job of the recursive DNS

servers

• Validation is usually just a configuration

switch

• Need to make sure the root zone key is

installed

Security Status of Data

(RFC4035 § 4.3)

l

Secure

− Resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted

security anchor to the RRset

l

Insecure

− Resolver knows that it has no chain of signed DNSKEY and DS RRs from any

trusted starting point to the RRset

l

Bogus

− −

Resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so May indicate an attack but may also indicate a configuration error or some form

• f data corruption

l

Indeterminate

− Resolver is not able to determine whether the RRset should be signed

DNSSEC: new fields

l

Updates DNS protocol at the packet level

lNon-compliant DNS recursive servers should ignore

these:

−CD: Checking Disabled (ask recursing server to not perform

validation, even if DNSSEC signatures are available and verifiable, i.e.: a Secure Entry Point can be found)

−AD: Authenticated Data, set on the answer by the validating

server if the answer could be validated, and the client requested validation

l

A new EDNS0 option

−DO: DNSSEC OK (EDNS0 OPT header) to indicate client

support for DNSSEC options

Thank You