dnssec deployment - internet society · dnssec evangelist of the day ¥nlnet labs Ðnot for profit...

CC-TLD Workshop, Sofia© 24 October 2006 Stichting NLnet Labs

http://www.nlnetlabs.nl/

DNSSEC Deployment

Olaf M. [email protected]

CC-TLD Workshop, Sofiahttp://www.nlnetlabs.nl/

page 2

NLnetLabs

DNSSEC evangelist ofthe day

• NLnet Labs– Not for profit Open Source Software lab

• Developed NSD

– DNS and DNSSEC research• Protocol and software development

• Deployment engineering

• Active IETF participant– co-chair of the IETF DNSEXT working group

– member of the Internet Architecture Board

– RFC3757 and RFC4061


page 3

NLnetLabs

Outline

• purpose and protocol

• Current Developments/problem areas

• Deployment, system architecture


page 4

NLnetLabs

Why DNSSEC


page 5

NLnetLabs

Bourtange, source Wikipedia


page 6

NLnetLabs

Why DNSSEC

• Defense layers– Multiple defense rings in physical secured

systems

– Multiple ‘layers’ in the networking world

• DNS infrastructure– Providing DNSSEC to raise the barrier for

DNS based attacks

– Provides a security ‘ring’ around many systemsand applications


page 7

NLnetLabs

The Problem• DNS data published by the registry is being replaced on its

path between the “server” and the “client”.

• This can happen in multiple places in the DNSarchitecture

– Some places are more vulnerable to attacks then others

– Vulnerabilities in DNS software make attacks easier(and there will always be software vulnerabilities)


page 8

NLnetLabs

ISP

DNS service

DNS Provider

DNS Architecture

Registry DB

primary

secondary

Cache server

Registrars/

Registrants

client

DNS ProtocolProvisioning

secondary


page 9

NLnetLabs

DNS Architecture

Registry DB

Server compromise

Registrars

Registrants


Inter-server

communicationCache Poisoning


page 10

NLnetLabs

Astrophysics

Mail ServerAstrophysics

Mail Server

Example:Unauthorized mail

scanning

DNSDNS

Central Admin

Mail ServerCentral Admin

Mail Server

Where?

There!

Subject: tenure


page 11

NLnetLabs

Astrophysics

Mail ServerAstrophysics

Mail Server

Example:Unauthorized mail

scanning

DNSDNS

Central Admin

Mail ServerCentral Admin

Mail Server

Where?Elsewhere

Bad GuyBad Guy

Subject: tenure


page 12

NLnetLabs

Targets; Where do DNS andeconomics meet?

• SPF, DomainKey and family

– Technologies that use the DNS to mitigate spam and phishing:$$$ value for the black hats

• Stock tickers, RSS feeds

– Usually no source authentication but supplying false stockinformation via a stock ticker and via a news feed can have $$$value

• ENUM

– Mapping telephone numbers to services in the DNS


page 13

NLnetLabs

Where Does DNSSECCome In?

• DNSSEC secures the name to addressmapping

– Tranport and Application security are justother layers.


page 14

NLnetLabs

Solutiona Metaphor

• Compare DNSSEC to a sealed transparentenvelope.

• The seal is applied by whoever closes theenvelope

• Anybody can read the message

• The seal is applied to the envelope, not tothe message


page 15

NLnetLabs

DNSSEC protection

Registry DB

Registrars

Registrants


‘envelope sealed’ ‘Seal checked’

‘Seal checked’


page 16

NLnetLabs

DNSSEC hypersummary

• Data authenticity and integrity by signingthe Resource Records Sets with private key

• Public DNSKEYs used to verify the RRSIGs

• Children sign their zones with their privatekey– Authenticity of that key established by

signature/checksum by the parent (DS)

• Ideal case: one public DNSKEY distributed


page 17

NLnetLabs

New Resource Records

• Three Public key crypto related RRs

– RRSIG Signature over RRset made usingprivate key

– DNSKEY Public key, needed for verifying aRRSIG

– DS Delegation Signer; ‘Pointer’ for building chains of authentication

• One RR for internal consistency

– NSEC authenticated non-existence of data


page 18

NLnetLabs

DNSSEC secondarybenefits

• DNSSEC provides an “independent” trustpath– The person administering “https” is most

probably a different from person from the onethat does “DNSSEC”

– The chains of trust are most probably different

– See acmqueue.org article: “Is HierarchicalPublic-Key Certification the Next Target forHackers?”


page 19

NLnetLabs

More benefits?

• With reasonable confidence performopportunistic key exchanges

– SSHFP and IPSECKEY Resource Records

• With DNSSEC one could use the DNS fora priori negotiation of securityrequirements.

– “You can only access this service over a securechannel”


page 20

NLnetLabs

DNSSEC properties

• DNSSEC provides message authentication andintegrity verification through cryptographicsignatures

– Authentic DNS source

– No modifications between signing and validation

• It does not provide authorization

• It does not provide confidentiality

• It does not provide protection against DDOS


page 21

NLnetLabs

DDOS and the DNS

• Reflector attacks– Recently Open recursive servers used to amplify traffic

– several Gbits/second traffic to critical infrastructure

– Source addresses at DDOS target are valid, packetformat valid

• an UDP problem

• DNS has nice amplification characteristics

• ‘closing open resolvers’ helps, but authoritativeservers will do to

• You make the packets smaller? We’ll just wake upmore zombies


page 22

NLnetLabs

Remedy: Ingressfiltering (BCP38)

Zombie botnet

Drop packets ifsource address is‘strange’ to thenetwork

http://www.ietf.org/rfc/rfc2827.txt(BCP38)

“Network Ingress Filtering:Defeating Denial of Service Attacks whichemploy IP Source Address Spoofing”


page 23

NLnetLabs

Outline





page 24

NLnetLabs

Main Problem Areas

• “the last mile”

• Key management and key distribution

• NSEC walk

improvement


page 25

NLnetLabs

The last mile

` APP

STUB

• How to get validation results back tothe user

• The user may want to make differentdecisions based on the validationresult

– Not secured

– Time out

– Crypto failure

– Query failure

• From the recursive resolver to thestub resolver to the Application

validating


page 26

NLnetLabs

Last MileCurrent Work

• A lot of vapor and brain ware

• Only one java-based prototype for secureresolving

– Used for studying API issues

– NLnet Labs started work on a port to C

• Cooperation with Nominet and Verisign


page 27

NLnetLabs

Problem Area

` APP

STUB

Key Management

• Keys need to propagate fromthe signer to the validatingentity

• The validating entity willneed to “trust” the key to“trust” the signature.

• Possibly many islands ofsecurity

signing

validating


page 28

NLnetLabs

Secure Islands and keymanagement

net.

money.net.kids.net.

geerthecorp

dev market dilbert

unixmacmarnick

nt

os.net.

com.

.


page 29

NLnetLabs

Secure Islands

• Server Side– Different key management policies for all these islands

– Different rollover mechanisms and frequencies

• Client Side(Clients with a few to 10, 100 or more trust-anchors)

– How to keep the configured trust anchors in sync withthe rollover

– Bootstrapping the trust relation


page 30

NLnetLabs

Key ManagementCurrent Work

• Rolling configured keys automatically

– Final stages of DNSEXT WG.

• Last call on draft-ietf-dnsext-trustupdate-timers andan accompanying requirement document

• Key distribution mechanisms have beenproposed

– None get very much traction


page 31

NLnetLabs

Key ManagementCurrent Work

• BIND 9.4 includes DLV• When a zone turns out to be signed and the key is

not available the validator looks in a dedicated partof the namespace maintained by the DLV registry

• Not designed to last, not brought to the IETF bythe implementors

– draft-weiler-dnssec-dlv

– Last call IETF, informational

– Follows implementation(?)


page 32

NLnetLabs

DLVsecure entry points stored in dlv.isc.org

net.

money.net.kids.net.

geerthecorp

dev market dilbert

unixmacmarnick

nt

os.net.

com.

.

dlv.isc.org

org.


page 33

NLnetLabs

NSEC walk

• The record for proving the non-existence of dataallows for zone enumeration

• Providing privacy was not a requirement forDNSSEC

• Zone enumeration does provide a deploymentbarrier

• Work starting to study possible solutions– will be co-existing with DNSSEC-BIS !!!

– Until then on-line keys will do the trick.


page 34

NLnetLabs

NSEC walkCurrent Work

• Online creation and signing of NSEC RRsthat cover the query name– RFC4470 and RFC4471

• NSEC3– Hashed based denial of existence

– draft-ietf-dnsext-


page 35

NLnetLabs

NSEC3 Features

• Interaction with DNS wildcards– Multiple proofs of non-existence needed

• OPT-out bit added– Changes security model of DNSSEC somewhat

• Delegations ranges can be opted out: delegationswithin that range are not proven not to exist.

– Needed for deployment in .com• 40 Million NSEC/NSEC3 RRs with signature

information is painful


page 36

NLnetLabs

NEC3 featurescontinued

• Dictionary attack resilient:

– Through use of salt

– Through use of itterations

• Also higher costs to servers and resolvers


page 37

NLnetLabs

Outline





page 38

NLnetLabs

Common argumentsagainst

• DNSSEC is to complex to deploy– The weapon with which to shoot oneself in the foot is

not a pop-gun but a military grade full automatic

• The root will never get signed

• There is no economy to push deployment

• Cache poisoning can be mitigated by correctlyimplementing random query ports and properquery ID


page 39

NLnetLabs

What’s keeping folk

• New technology; chicken and egg

• Zone walking possibility

– Is this really an issue in your environment?

– Solutions are being engineered

• Automated key rollover and distribution


page 40

NLnetLabs

Early players

• Demonstrate the ability to self-regulate

– Before the guys up the hill (or from Brussels)force it down your throat

– Before a bad thing happens and you are wokenup at 2 am

• Lead by example

– Break the egg


page 41

NLnetLabs

The role of DNSRegistries

• Good Netizens

– Being Involved, recognizing the problem

– Community education and awareness raising

• Registration Services

– Under appropriate circumstances providingregistration data to appropriate authorities

• DNS infrastructure

– Providing DNSSEC to raise the barrier for DNS basedattacks


page 42

NLnetLabs

DNSSEC deploymentpracticalities

• RIPE NCC deployed DNSSEC on thereverse tree

– Followed the architecture to plan the changesto the system

• You may want to follow the same stepswhen planning for local DNSSECdeployment


page 43

NLnetLabs

DNSSECArchitecturemodifications

Primary DNS

Secondary

DNS

Customer

interfaces

Zone signer

DNSSEC

aware servers

DNS and input

checks

Provisioning

DB

Zone

Creation

DNSSEC aware provisioning


page 44

NLnetLabs

Server Infrastructure

• Part of keeping up to date

– Your most recent version of BIND and NSDrun DNSSEC

• Memory might be an issue

– Predictable (see RIPE352)

• Coordination with secondaries


page 45

NLnetLabs

Provisioning

• Realize that interaction with child is notdrastically different.

– DS and NS have the same security properties

– You may need to respond a bit different to‘child’ emergency cases

• Thinking “security” will make you notice“security”


page 46

NLnetLabs

Key Mastering andSigning

• Key management and signing needs to bereliable

– Failure will lead to loss of service

• Cost factors:

– Automation and Education


page 47

NLnetLabs

Instruct your lawyers

• A DNSSEC signature is not a certification for thecorrectness of the provisioned data

• It only serves to proof that the data is not changed after itmade its transition from the provisioning system into theDNS

• DNSSEC validation failures indicate possible maliciousactivity

• Do not put legal weight on DNSSEC signatures


page 48

NLnetLabs

Concluding remarks

• DNSSEC is not a magic bullet but may become animportant component

– By providing the infrastructure apps and resolver developmentshould follow

• U.S. Federal requirement

– Federal agencies will need to support DNSSEC

– http://www.dnssec-deployment.org/news/FISMA.htm


page 49

NLnetLabs


page 50

NLnetLabs

QUESTIONS?

Acknowledgements: A number of these slides are based on earlier work at RIPE NCC.


page 51

NLnetLabs

References I

Without claims to completeness…

RFCs can be found at http://www.ietf.org/rfc/

Internet drafts are at http://www.ietf.org/internet-drafts/

• DNSSEC bis:– RFC4033,4034,4035

• Authenticated denial:– Online signing:

• RFC4470, RFC4471

– NSEC3: draft-ietf-dnsext-dnssec-nsec3


page 52

NLnetLabs

Rerferences II Key Anchor maintenance

• DLV: IEICE Trans. Commun. Vol. E88-B,No. 4, April 2005

• Trustupdate proposals

– draft-ietf-dnsext-trustupdate-threshold

– draft-ietf-dnesxt-trustupdate-timers

– draft-moreau-dnsext-takrem-dns

– draft-laurie-dnssec-key-distribution


page 53

NLnetLabs

References III Operational

• RFC4641

• RIPE 352– http://www.ripe.net/ripe/docs/ripe-352.html

• DNSSEC HOWTO– http://www.ripe.net/disi/dnssec_howto/

• draft-hayatnagarkar-dnsext-validator-api

• Geoff Hustons experiences– ispcolumn.isoc.org or www.potaroo.net


page 54

NLnetLabs

References IVWebsites

• www.dnssec-deployment.org

• www.dnssec.net

• RIPE DNSSEC deployment (howto, keymanagement toolsetc)– www.ripe.net/disi/

• DNSSEC testbed and testing tools developed by NIST– http://www-x.antd.nist.gov/dnssec/

• DNSSEC tools available at– http://www.dnssec-tools.org/


page 55

NLnetLabs

References VDeployment Initiatives

• http://dnssec.nic.se/

• http://www.dnssec.ru/

• https://www.ripe.net/rs/reverse/dnssec/

dnssec deployment - internet society · dnssec evangelist of the day ¥nlnet labs Ðnot for profit...

Documents