Copyright © 2002 Nominum, Inc.1 Information Document 17-E ITU-T Study Group 2 May 2002 QUESTION:Q.1/2 SOURCE:TSB TITLE:INTRODUCTION TO SECURE DNS (by Jim

Copyright © 2002 Nominum, Inc. 1

Information Document 17-E

ITU-T Study Group 2May 2002

QUESTION: Q.1/2

SOURCE: TSB

TITLE: INTRODUCTION TO SECURE DNS (by Jim Reid)

The purpose of this document is to provide some basic introductory material on security features of the Domain Name System (DNS)

Introduction to Secure DNS


Introduction

• Explaining the problem• Weaknesses in the DNS resolution process• Attacks on the name servers

- Consequences of those attacks- Spoofing, mangled DNS answers

• Solutions to the problem- Transaction Signatures (TSIG)- DNS Security Extensions (DNSSEC)


What’s the IP address of

www.nominum.com?

The Resolution Process• The workstation annie asks its configured

name server, dakota, for www.nominum.com’s address

ping www.nominum.com.annie.west.sprockets.com

dakota.west.sprockets.com


ping www.nominum.com.

The Resolution Process

• Let’s look at the resolution process step-by-step:

annie.west.sprockets.com



• The name server dakota asks a root name server, m, for www.nominum.com’s address


m.root-servers.net



www.nominum.com?


The Resolution Process• The root server m refers dakota to the com name

servers

• This type of response is called a “referral”


m.root-servers.net

dakota.west.sprockets.com Here’s a list of the com name servers.

Ask one of them.



• The name server dakota asks a com name server, f, for www.nominum.com’s address


m.root-servers.net



www.nominum.com?

f.gtld-servers.net



• The com name server f refers dakota to the nominum.com name servers


f.gtld-servers.net

m.root-servers.net


Here’s a list of the nominum.com name servers.

Ask one of them.



• The name server dakota asks an nominum.com name server, ns1.sanjose, for www.nominum.com’s address


f.gtld-servers.net

m.root-servers.net


ns1.sanjose.nominum.net


www.nominum.com?



• The nominum.com name server ns1.sanjose responds with www.nominum.com’s address


f.gtld-servers.net

m.root-servers.net


ns1.sanjose.nominum.netHere’s the IP address for

www.nominum.com


Here’s the IP address for

www.nominum.com


• The name server dakota responds to annie with www.nominum.com’s address


f.gtld-servers.net

m.root-servers.net


ns1.sanjose.nominum.net


What’s Wrong With That?

• Nothing: it all works fine…..• BUT there’s no authentication at all!• A client can’t tell:

- Where an answer really came from- If the server that replied is telling the truth or not- If it received exactly what the server sent


Cracking the DNS

• Bombard client with bogus answers- Guess what the answer might be

• Intercept an answer packet & modify it- Only works well if adjacent to client or server

• Set up a fake server for some zone- Trick other servers into querying the fake one

• Evil routing/peering tricks & hi-jack traffic- Inject bogus routes for the root servers (or the

servers for any other “interesting” zone)


What Does This Mean?

• A DNS client can’t be sure of anything:- Did a lookup for www.nominum.com really get answered

by the nominum.com name servers?- Did it get what a real nominum.com name server

actually sent?- Is the server that answered telling the truth?

• Did we get the actual address of Nominum’s web server?

• Feel free to replace nominum.com with your favourite domain name….


Transaction Signatures

The use of Transaction Signatures, TSIG,

is explained in this section


Transaction Signatures (TSIG)

• Defined in RFC2845• Computed on the fly

- Not in zone files- Added to Additional Section of DNS replies

• Uses a shared secret and cryptographic hash functions- Currently HMAC-MD5

• Timestamps prevent replay attacks


TSIG Overview

• "Lightweight" digital signature• Cryptographic hash of:

- DNS query or answer- Timestamp- Shared secret

• Can be anything (within reason)• Usually generated by dnssec-keygen• Use any tool that generates a base-64 encoded string


Cryptographic Hash Functions

• Very strong checksums• Mathematically proven to have almost no chance

of a collision:- Different inputs cannot result in the same hash value

• MD5 hash of ASCII character 1- b026324c6904b2a9cb4b88d6d61c81d1

• MD5 hash of ASCII character 2- 26ab0db90d72e28ad0ba1e22ee510510


TSIG Validation

• Other party knows:- Contents of DNS packet- Chosen crypto hash algorithm- Time of day (UTC)- Shared Secret

• It can compute the TSIG hash value- If the calculated hash matches the TSIG hash in DNS

packet, all is well- If not, something has gone wrong:

• Wrong timestamp• Different shared secret


TSIG Shared Secret

• An obvious vulnerability- Has to remain secret

• Systems using TSIG should be under one administrative & operational control- Authenticating zone transfers?

• Many TLDs do this already

- Dynamic DNS update requests• DHCP server, nsupdate


Using TSIGnamed.conf key{}, server{} statements:

key examplekey { algorithm hmac-md5; secret "pRP5FapFoJ95JEL06sv4PQ==";};server 10.9.8.7 { keys { examplekey; };};

Use examplekey to send/validate TSIGDNS packets to/from 10.9.8.7


TSIG for Access Control• The name of a TSIG key can be used in a BIND

Access Control List:

allow-transfer { examplekey; };allow-update {127.0.0.1; examplekey; };

Zone transfers must be TSIG “signed”with examplekeyAccept dynamic updates from 127.0.0.1or if they're signed by examplekey


TSIG and named.conf

• named.conf is usually world-readable- but TSIG keys should be kept secret

• Use an include statement- put the keys in a private file and include that:

include "/not/for/public/tsig-keys";

• Watch out for keys in core dumps or name server logs!


TSIG and Dynamic Updates

• nsupdate - BIND utility for performing Dynamic DNS (DDNS)

updates

• nsupdate understands TSIG- Allows TSIG authentication of Dynamic Update

requests• Only sane way to authenticate them• Alternative is by (easily forged) IP address


TSIG and DHCP

• ISC DHCP server understands TSIG too- Standards for DDNS and DHCP interaction still

to be completed by IETF

• Security considerations- Name server may trust DHCP daemon

• DHCP daemon may believe untrusted clients• Could insert illegal/unwanted hostnames into DNS

- TSIG "signatures" better than nothing


dhcpd Updates with TSIG

Add to dhcpd.conf:key examplekey { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret pRP5FapFoJ95JEL06sv4PQ==;};zone EXAMPLE.ORG. { primary 127.0.0.1; key examplekey;};Send dynamic updates for example.org to127.0.0.1 signed with examplekey TSIG key


Timestamps and TSIG

• Transaction Signatures include a timestamp- Prevents replay attacks- Fuzz factor allows clocks to be out by up to a few

minutes

• Systems using TSIG should have their clocks synchronised- Should be running NTP anyway- Run Secure NTP if you're paranoid

• Or buy an atomic clock!


Windows 2000

• Windows 2000 uses Dynamic DNS updates- Active Directory

• Does not use TSIG• Uses a proprietary mechanism, GSS-TSIG

- Based on “mangled” Kerberos tickets- GSS-TSIG proposed as IETF standard

• No second implementation (yet)


Summary

• Transaction Signatures (TSIG) have been explained in this section:- How to use them for authentication

• clients, name servers, dynamic update requests

- Using them in BIND Access Control Lists- Timestamps mean clocks should be

synchronised- Windows 2000 issues


Secure DNS (DNSSEC)

This section explains DNSSEC: Secure DNS- Rationale for DNSSEC

• What problems DNSSEC solves• What problems it does not solve• What problems DNSSEC creates

- KEY, SIG and NXT records- BIND9's DNSSEC utilities- Signing a zone


Why Secure DNS?

• The DNS is not secure!!!• Servers could be lying

- Cache poisoning attacks

• Servers could be spoofed• Answers could be tampered with• UDP makes these attacks simple• This is what Secure DNS is designed to

solve


What DNSSEC Does Not Do

• Prevent/thwart denial-of-service attacks• Stop name server compromises

- Buffer overflows• Run BIND9 to stop that!

- Environment variable leakages

• Confidentiality of DNS data- The DNS is public after all...


What Secure DNS Proves

• Data authenticity- What was received was what the server sent

• Non-repudiation- Who/what signed the data

• Name server authenticity (in theory anyway)- An answer for foo.example.com comes from

the genuine name servers for example.com- Should be a chain of trust to the root


The Chain of Trust

• Public key for nominum.com is signed with the private key for .com- .com “trusts” the nominum.com key

• Public key for .com is signed with the private key for the root- Root zone “trusts” the .com key

• Everyone trusts the root zone’s public key- Openly published- Built in to every name server?


Validation Model

• Answer for ww.nominum.com is provably correct- It’s been signed with the nominum.com key- Nobody could have tampered with the data- The nominum.com key was signed by the key

for .com so the nominum.com key is OK- The .com key was signed by the root key so the

delegation to com can be trusted too- The root key is known and trusted by everyone


Secure DNS Overview

• Defined in RFC2535 (DNSSEC)- Raft of enhancements & extensions since then:

• RFC2536, RFC2537, RFC2931, RFC3007, RFC3008, RFC3090, RFC3110, etc

• Three new resource records:- KEY, SIG and NXT

• Digital signatures of DNS data• Industrial-strength crypto:

- DSA, RSA, Diffie-Helman


Public Key Cryptography

• Asymmetric encryption:- RSA, DSA- Public key and private key pairs

• Data encoded with public key can only be decoded with the corresponding private key and vice versa

- Digital signatures- Non-repudiation- Confidentiality

• Not used in DNSSEC!• DNS is supposed to be public after all


DNSSEC Signatures

• Don't explicitly sign the actual DNS data- Sign a hash of the data instead (SHA1)- Less data to sign

• Names must be normalised to a canonical form:- All in lower-case- Fully qualified domain names- Handled automatically by the zone signing tool


The KEY Record

• The public key component• Format:

name KEY flags proto algorithm pubkey


- flags• What the key can be used for: authentication, zone,

user, etc

- proto• Protocol identifier: DNSSEC, IPsec, TLS, etc

- algorithm• Crypto algorithm: RSA, DSA

- pubkey • Base-64 public key


An Example KEY Record

example.com. IN KEY 256 3 1 AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQtyNGVnpBAMTbOykxKMJNrBdg41AufR4hItZIi76vbd0R1emEXvPpBAZ

• Public RSA zone key for DNSSEC called example.com


The SIG Record

• A digital signature for some RRset- RRset: resource records with same name, class,

type and TTL

• Horribly complicated• Format:

name SIG type alg labels ottl sig-exp sig-inc key-tag signer sig


- type • the RRset type that the SIG record signs• A, MX, SOA, etc

- alg• crypto algorithm• as in the KEY record

- labels• number of labels in the name that are signed• kludge for wildcards:

*.example.com


- ottl• original TTL of signed RRset

- sig-exp• time when the signature expires

- sig-inc• time when the signature is valid from


- key-tag• short-cut to identify the key• helps when there are 2 or more keys

- signer• name of the public key to validate the signature

- sig• base-64 encoding of signature


An Example SIG Record

• example.com. 86400 SIG SOA ( 1 2 86400 2001072720082 20010627200820 42000 example.com. pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny9nY8jBHEiUAxGTV+i53fsIpVJOnWalUxbkP260OAR0bTHve4voN9g== )

• A SIG record for example.com's SOA record signed with the key for example.com


The NXT Record

• For proving a name or RR type does not exist- Can't just sign NULL string!

• Format: name NXT next-name types- next-name

• Name of alphabetically next record in the zone• Last name points back to zone's SOA record

- types• Resource record types that exist for the name


An Example NXT Record

• jim.example.com. NXT \ ns0.example.com A SIG NXT

- Next name in zone after jim.example.com is ns0.example.com.

- A, SIG and NXT records exist for jim.example.com


Signing a Zone

• 4 steps:- Generate a key- Get parent to sign zone key- Incorporate parent's signature of zone key- Sign the zone

• Can self-sign when the parent zone is not DNSSEC-aware- e.g. self-sign example.com if com is not signed


Stage 1: generate a key

• dnssec-keygenBIND utility for generating keys

can generate RSA, DSA, HMAC-MD5 keys

Uses entropy from operating system to generate random keys: large prime numbers


Stage 2 - Make a Key Set• Use dnssec-makekeyset• Options:

- -s YYYYMMDDHHMMSS | +offset• SIG start time (absolute or relative)

- -e YYYYMMDDHHMMSS | +offset | "now" + offset• SIG end time (absolute or relative)

- -t ttl• TTL of generated RRs

• Arguments:- name of key file


Stage 3 - Parent Zone Signs Child Zone’s Key

• Uses dnssec-signkey• Options:

- -s YYYYMMDDHHMMSS | +offset• SIG start time (absolute or relative)

- -e YYYYMMDDHHMMSS | +offset | "now" + offset

• SIG end time (absolute or relative)


Stage 4 - Signing The Zone

• Add public key & parent’s signature of that key to the unsigned zone file

• Run dnssec-signzone


Example Unsigned Zone

$TTL 86400;example.com. IN SOA ns0.example.com. ( hostmaster.example.com.

2001062400 ; serial number 10800 ; refresh 3600 ; retry 2592000 ; expire 86400 ; time to live

)example.com. IN TXT "$Id: example.com,v 1.2 2001/06/24 22:53:39 jim Exp $"


example.com. IN NS ns0.example.com.example.com. IN MX 10 jim.example.com.

jim.example.com. IN A 10.11.12.13ns0.example.com. IN A 10.9.8.7


dnssec-signzone

# dnssec-signzone example.com \ Kexample.com.+001+42000

example.com.signed

• Original (unsigned) zone file left intact• zonename.signed contains signed zone file

- example.com.signed

• It's not pretty.....


Example Signed Zone File; File written on Wed Jun 27 21:08:20 2001; dnssec_signzone version 9.2.0a2example.com. 86400 IN SOA ns0.example.com.

( hostmaster.example.com. 2001062400 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 2592000 ; expire (4 weeks 2 days) 86400 ; minimum (1 day) ) 86400 SIG SOA 1 2 86400 20010727200820 ( 20010627200820 42000 example.com. pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny9nY8jBHEiUAx GTV+i53fsIpVJOnWalUxbkP260OAR0bTHve4voN9g== )


86400 NS ns0.example.com. 86400 SIG NS 1 2 86400 20010727200820 ( 20010627200820 42000 example.com. nyFlzAYSM/CPqDjpsHPNTqKlSwniotFqM6KH BcloIBlFOR6Tx6nCiV2Qk4VawPrRIeOAG+uc ZaV6jwrHl+Aujg== ) 86400 MX 10 jim.example.com. 86400 SIG MX 1 2 86400 20010727200820 ( 20010627200820 42000 example.com. elYsn8kCaO42JuGKgvt7Api+Uj8wr09Dj3WM Grll2GYXFq4yeneRlq+UmiXqEZjSJXiwipKk vMn7pr2qv0T9IQ== )


86400 TXT "$Id: example.com,v 1.2 2001/06/24 22:53:39 jim Exp $"

86400 SIG TXT 1 2 86400 20010727200820 ( 20010627200820 42000 example.com. aKqz7FiIL1FSnFBWyVuyqgLr2p/GjBQVljTX XfqtKFCQWTSytMNVyn52buyydy80Fup5ZonN YkNfEBzQvlDViQ== ) 86400 KEY 256 3 1 ( AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQtyN GVnpBAMTbOykxKMJNrBdg41AufR4hItZIi76 vbd0R1emEXvPpBAZ ) ; key id = 42000


86400 NXT jim.example.com. NS SOA MX TXT SIG KEY NXT

86400 SIG NXT 1 2 86400 20010727200820 (

20010627200820 42000 example.com.

jhBUcRSzoMCwzc1FVgOKrl+mSgv7f/Ri8/mb

Q1dtGz/+0KKXa0u4s+T1SygG8wHs3Y/IOPq+

qn5YSbMtAmSajQ== )


jim.example.com. 86400 IN A 10.11.12.13 86400 SIG A 1 3 86400 20010727200820 ( 20010627200820 42000 example.com. ZpD/YrrFQzeFJWENIe4U1Z2xpVmRxzBabYKw xe61bqrLsg2EuOv7CRdNwxWvEbZPN4Rf64GG oaGV97him2C10Q== ) 86400 NXT ns0.example.com. A SIG NXT 86400 SIG NXT 1 3 86400 20010727200820 ( 20010627200820 42000 example.com. dub7z+Gq4ZnJqRB1ucJfsgIsMv8WepkzrvyY +kn3NfTOGBC51tJgcyW8HMxQz/D9ig39KO8G wl6Wc7upvReUMA== )


ns0.example.com. 86400 IN A 10.9.8.7 86400 SIG A 1 3 86400 20010727200820 ( 20010627200820 42000 example.com. Ks14BB6UVciyfxgJ4R5eXFZrRUmnuPhTgfjQ 0r3FCyvdOr6Uu5iLSTbzgulY+qZXaXF9tCTK +65y5VxUk3WtBQ== ) 86400 NXT example.com. A SIG NXT 86400 SIG NXT 1 3 86400 20010727200820 ( 20010627200820 42000 example.com. ro1TRC7idXJw/MpLBLY/sXBlNAoLcSjKKR7t mD91i7hhW9OF4R8Ql01QU+MYrjui9kOw2isU /8BY63MCfbqlnw== )


Comments on Signed Zone

• Original ordering is lost- So are any comments in the unsigned zone file

• Signed zone files are not human-readable- "No user servicable parts inside"

• Zone file is approximately 4 times bigger:- Each RR has a SIG record

• And an NXT record which also has a SIG record


Verifying with dig

% dig example.com soa; <<>> DiG 9.2.0a2 <<>> example.com soa;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:

58191;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY:

1, ADDITIONAL: 1;; QUESTION SECTION:;example.com. IN SOA;; ANSWER SECTION:example.com. IN SOA ns0.example.com.

hostmaster.example.com. 2001062400 10800 3600 2592000 86400


;; AUTHORITY SECTION:

example.com. IN NS ns0.example.com.

;; ADDITIONAL SECTION:

ns0.example.com. IN A 10.9.8.7

;; Query time: 5 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Mon Jun 25 22:45:07 2001

;; MSG SIZE rcvd: 110


• DNSSEC-aware query:% dig example.com soa +dnssec; <<>> DiG 9.2.0a2 <<>> example.com soa +dnssec;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:

44988;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY:

2, ADDITIONAL: 5;; OPT PSEUDOSECTION:; EDNS: version: 0, udp= 4096;; QUESTION SECTION:;example.com. IN SOA


;; ANSWER SECTION:example.com. IN SOA ns0.example.com.

hostmaster.example.com. 2001062400 10800 3600 2592000 86400

example.com. IN SIG SOA 1 2 86400 20010725213738 20010625213738 2499 example.com. eAZ54DURplbBQEy+tuTJWuldooHEKoDB+nbKW1LL7pN2yGAI9UdsrZURnuJSgVQehT7AWTyqV8ldAhxBKUFoyQ==

;; AUTHORITY SECTION:example.com. IN NS ns0.example.com.example.com. IN SIG NS 1 2 3600 20010725213738

20010625213738 2499 example.com.

vR28oF6X+6rswIV7X5OM9Va9XW9Kqf+hCaDzamcnMp4OT7KDpikwDdLy620Uia+VWglC0Tva5XcXVDL54VnwlQ==


;; ADDITIONAL SECTION:

ns0.example.com. IN A 10.9.8.7

example.com. IN KEY 256 3 1 AQPR/qMZ4euseKDELUcPQ9G8AoO8Qkv3M7jmFwUUXZDtWx6vZRJ

ib0lrbVcwUMOzWu1c/lAkDb8Iv6ruhabGCcMp

example.com. IN SIG KEY 3 2 3600 20010725053856 20010625053856 5945 com. CAylEF0FQFYZOkzCquLtg9wYxFLsIb+qwVYgf+KuXBEG9txRByxC4Ug=


ns0.example.com. IN SIG A 1 3 3600 20010725213738 20010625213738 2499 example.com. TeRV2qIiXROf60KLnrwgDNaDdSYJgX4IySAjrRkeoDujXv91NU0rWnAC inLTmGVX+hrryUFwIz0BYrdhZyvIaQ==

;; Query time: 5 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Mon Jun 25 22:45:15 2001

;; MSG SIZE rcvd: 600


DNSSEC-aware queries

• Note use of EDNS0 protocol- Bigger DNS payloads/buffers- Standard DNS query only has 512 byte payload

• Prevents truncated responses and TCP retries

• DNSSEC-aware answer is much bigger- All the crypto stuff: SIGs, KEY- Exceeds standard 512-byte limit

• Trivial example with small key size


Setting Up Islands of Trust

• Root and top-level zones are not signed (yet)- How to verify another DNSSEC-aware zone?

• trusted-keys statement in named.conf- Add another "trusted" zone's public key to server- Zone's public key sent by some out-of-band

means to another DNSSEC-aware name server• eg business partner, supplier, ASP


Example trusted-keys Statement

trusted-keys {example.net. 256 3 3 "AMNOZhb05QlfBNuXTj VV+wsXwqAn6yhaw71smL0qTU/pWRXqom7eYFVdNUGu 4jGPWMBOXT6CRY089c1RezLhu9vj4PsF4GRrJHfwbx L/B/jyCu4x8RITdvj9eCrYIF0DWbN4TzUhOOFYSLbw 8KwfcwRFigXDPLDwAcawdLaT7dpuqzNvHXZWsuSvxb GxBX0uKOG1o4JHhBpCAUcARX/r9Z7DGCgrq2NuCqre +yRdNFPt2fgqXZOix3DeGkAYFgySFbNzIrEFG8yunk FSix7XC8XJA1Ou";};

Public RSA key for example.net is trusted- Verify anything signed with its private key


Algorithms

• Implementations must support DSA• RSA will become mandatory too

- No patent issues any more

• DSA is faster than RSA at signing- Takes longer to verify DSA signatures though

• Using >1 algorithm doesn't provide stronger authenticity or "security"- DNS data will be insecure if either key is

compromised


Sample Zone Signing Times

• Very modest hardware: 300 Mhz Pentium- 100 Resource Records: 7.6 seconds- 100,000 Resource Records: 7445 seconds

• Clearly linear• Faster processors mean quicker signing

- Moore’s Law is a big help here- Crypto hardware makes it even faster

• Zone signing is inherently parallelisable- Multi-processor systems, clusters


SIG Verification Times

• Same modest hardware:• Verifying 1 RRset, 1 SIG record

- DSA-512: 108 ms- DSA-1024: 346 ms- RSA-512: 20 ms- RSA-1024: 110ms

• Same linear speed-up with faster CPUs and/or special crypto hardware (RSA chips)

• Validating a single SIG record can’t easily be done in parallel


Choosing Key Lengths

• Keys should be no bigger than parent zone's key- No point making them larger- Parent's key "strength" defines child's "strength"

• Use larger key sizes for long-lived SIGs - Beware of cryptanalysis

• Shorter key lengths make sense for short-lived signatures- Typically valid for less than a week


Good Crypto Policy

• Don't use one key for everything• Maybe:

- RSA to sign zone data- DSA to sign child keys

• or:- 768-bit keys for signing zone data- 1024-bit keys for signing child keys

• Change the keys "often enough"


Secure Dynamic Update

• Defined in RFC3007- But not well explained in BIND9 documentation yet

• On-line signing- BIND9 computes SIG and NXT records on the fly- Dynamic update requests on signed zones

• Name server needs to read the file containing the private key

• Storing private keys on-line is maybe not a good idea


DNSSEC Problems• Bigger DNS packets

- Typically break 512-byte payload limit- Need EDNS0 to allow bigger packets

• And prevent truncated responses => TCP retries

• Zone files are bigger and unreadable• Signed zones can't be altered by hand• Signing means changes to admin procedures

- check-out, modify, check, check-in, sign zone- Add/remove/change keys


• Parent zone should sign child zone's keys- Implies close coupling of parent and child zones- No bad thing, but too many broken/lame

delegations• ~25% in tightly controlled registries• ??% in .com

- High levels of DNS cluelessness

• No top-level domains are signed yet


• Awkward registry/registrar relationships- Who signs what and how?

• NXT records allow the whole zone to be traversed

• Key rollover is hard (and recursive!)• Root zone key is a weakness


Key Rollover

• Keys should changed regularly - Good cryptographic practice

• When a parent's key changes, it has to re-sign the keys of its secure child zones- Child zones then need to be re-signed- And so on......

• SIG record "valid from/to" timestamps help - New keys and SIGs introduced in advance- Period of dual-running


The Root Zone Key

• Integrity of root key is critical- Compromise cannot be allowed (or suspected)

• Break it and reboot the internet• Obvious magnet for attackers

- Massive single point of failure

• Root key must change from time to time- Prevent cryptanalysis- Implies eventually re-signing everything


DNSSEC Applications

• DNS as a PKI?- DNS is ubiquitous and works!- DNSSEC means answers can be validated

• Use the DNS for storing & distributing IPsec, SSL & SSH keys, etc.- Fetching keys becomes a (Secure) DNS lookup

• PGP & GPG keys?• X.509 Certificates

- CERT record


DNSSEC Future

• Some registries are planning to sign their TLDs for real- Projects under way in Netherlands, Sweden &

Germany- RIPE's in-addr.arpa tree- Verisign/NSI's plans for .com

• Further protocol extensions- The DS (Delegation Signer) record - Opt-in

• Alterations to NXT record


The DS Record

• Another new record type: Delegation Signer- Here is the name of a meta-key that I’ve signed

• Parent signs child zone’s meta key• Child’s meta key signs child’s zone key

- Child can pick a new zone key without needing the parent to sign it

- Simplifies parent/child zone relationship

• Almost through IETF standarisation process


Opt-In

• Changed semantics for the NXT record- Points to next signed name in a zone- Probably a delegation

• Big win for .com- 99.9% of names there may never be signed

• Makes signed zones smaller- not everything needs to be signed

• IETF standarisation just about complete


Summary

• This section has covered:Secure DNS (DNSSEC)

Resource records for DNSSEC

Some of the problems in deploying DNSSEC

Potential uses of Secure DNS

Documents

Copyright © 2002 Nominum, Inc.1 Information Document 17-E ITU-T Study Group 2 May 2002 QUESTION:Q.1/2 SOURCE:TSB TITLE:INTRODUCTION TO SECURE DNS (by Jim