Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

1 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 Reid) The purpose of this document is to provide some basic introductory material on security features of the Domain Name System (DNS)

2 Introduction to Secure DNS

3 Copyright © 2002 Nominum, Inc.3 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)

4 Copyright © 2002 Nominum, Inc.4 Whats the IP address of The Resolution Process The workstation annie asks its configured name server, dakota, for address ping

5 Copyright © 2002 Nominum, Inc.5 ping The Resolution Process Lets look at the resolution process step-by- step:

6 Copyright © 2002 Nominum, Inc.6 The Resolution Process The name server dakota asks a root name server, m, for address ping Whats the IP address of

7 Copyright © 2002 Nominum, Inc.7 The Resolution Process The root server m refers dakota to the com name servers This type of response is called a referral ping Heres a list of the com name servers. Ask one of them.

8 Copyright © 2002 Nominum, Inc.8 The Resolution Process The name server dakota asks a com name server, f, for address ping Whats the IP address of

9 Copyright © 2002 Nominum, Inc.9 The Resolution Process The com name server f refers dakota to the name servers ping Heres a list of the name servers. Ask one of them.

10 Copyright © 2002 Nominum, Inc.10 The Resolution Process The name server dakota asks an name server, ns1.sanjose, for address ping Whats the IP address of

11 Copyright © 2002 Nominum, Inc.11 The Resolution Process The name server ns1.sanjose responds with address ping Heres the IP address for

12 Copyright © 2002 Nominum, Inc.12 Heres the IP address for The Resolution Process The name server dakota responds to annie with address ping

13 Copyright © 2002 Nominum, Inc.13 Whats Wrong With That? Nothing: it all works fine….. BUT theres no authentication at all! A client cant 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

14 Copyright © 2002 Nominum, Inc.14 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)

15 Copyright © 2002 Nominum, Inc.15 What Does This Mean? A DNS client cant be sure of anything: -Did a lookup for really get answered by the name servers? -Did it get what a real name server actually sent? -Is the server that answered telling the truth? Did we get the actual address of Nominums web server? Feel free to replace with your favourite domain name….

16 Copyright © 2002 Nominum, Inc.16 Transaction Signatures The use of Transaction Signatures, TSIG, is explained in this section

17 Copyright © 2002 Nominum, Inc.17 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

18 Copyright © 2002 Nominum, Inc.18 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

19 Copyright © 2002 Nominum, Inc.19 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

20 Copyright © 2002 Nominum, Inc.20 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

21 Copyright © 2002 Nominum, Inc.21 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

22 Copyright © 2002 Nominum, Inc.22 Using TSIG named.conf key{}, server{} statements: key examplekey { algorithm hmac-md5; secret "pRP5FapFoJ95JEL06sv4PQ=="; }; server { keys { examplekey; }; }; Use examplekey to send/validate TSIG DNS packets to/from

23 Copyright © 2002 Nominum, Inc.23 TSIG for Access Control The name of a TSIG key can be used in a BIND Access Control List: allow-transfer { examplekey; }; allow-update { ; examplekey; }; Zone transfers must be TSIG signed with examplekey Accept dynamic updates from or if they're signed by examplekey

24 Copyright © 2002 Nominum, Inc.24 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!

25 Copyright © 2002 Nominum, Inc.25 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

26 Copyright © 2002 Nominum, Inc.26 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

27 Copyright © 2002 Nominum, Inc.27 dhcpd Updates with TSIG Add to dhcpd.conf: key examplekey { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret pRP5FapFoJ95JEL06sv4PQ==; }; zone EXAMPLE.ORG. { primary ; key examplekey; }; Send dynamic updates for to signed with examplekey TSIG key

28 Copyright © 2002 Nominum, Inc.28 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!

29 Copyright © 2002 Nominum, Inc.29 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)

30 Copyright © 2002 Nominum, Inc.30 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

31 Copyright © 2002 Nominum, Inc.31 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

32 Copyright © 2002 Nominum, Inc.32 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

33 Copyright © 2002 Nominum, Inc.33 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...

34 Copyright © 2002 Nominum, Inc.34 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 comes from the genuine name servers for -Should be a chain of trust to the root

35 Copyright © 2002 Nominum, Inc.35 The Chain of Trust Public key for is signed with the private key trusts the key Public key is signed with the private key for the root -Root zone trusts key Everyone trusts the root zones public key -Openly published -Built in to every name server?

36 Copyright © 2002 Nominum, Inc.36 Validation Model Answer for is provably correct -Its been signed with the key -Nobody could have tampered with the data -The key was signed by the key so the key is OK 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

37 Copyright © 2002 Nominum, Inc.37 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

38 Copyright © 2002 Nominum, Inc.38 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

39 Copyright © 2002 Nominum, Inc.39 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

40 Copyright © 2002 Nominum, Inc.40 The KEY Record The public key component Format: name KEY flags proto algorithm pubkey

41 Copyright © 2002 Nominum, Inc.41 -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

42 Copyright © 2002 Nominum, Inc.42 An Example KEY Record IN KEY AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQ tyNGVnpBAMTbOykxKMJNrBdg41AufR4hI tZIi76vbd0R1emEXvPpBAZ Public RSA zone key for DNSSEC called

43 Copyright © 2002 Nominum, Inc.43 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

44 Copyright © 2002 Nominum, Inc.44 -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: *

45 Copyright © 2002 Nominum, Inc.45 -ottl original TTL of signed RRset -sig-exp time when the signature expires -sig-inc time when the signature is valid from

46 Copyright © 2002 Nominum, Inc.46 -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

47 Copyright © 2002 Nominum, Inc.47 An Example SIG Record SIG SOA ( pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny 9nY8jBHEiUAxGTV+i53fsIpVJOnWalUxb kP260OAR0bTHve4voN9g== ) A SIG record for's SOA record signed with the key for

48 Copyright © 2002 Nominum, Inc.48 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

49 Copyright © 2002 Nominum, Inc.49 An Example NXT Record NXT \ A SIG NXT -Next name in zone after is -A, SIG and NXT records exist for

50 Copyright © 2002 Nominum, Inc.50 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 if com is not signed

51 Copyright © 2002 Nominum, Inc.51 Stage 1: generate a key dnssec-keygen BIND utility for generating keys can generate RSA, DSA, HMAC-MD5 keys Uses entropy from operating system to generate random keys: large prime numbers

52 Copyright © 2002 Nominum, Inc.52 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

53 Copyright © 2002 Nominum, Inc.53 Stage 3 - Parent Zone Signs Child Zones 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)

54 Copyright © 2002 Nominum, Inc.54 Stage 4 - Signing The Zone Add public key & parents signature of that key to the unsigned zone file Run dnssec-signzone

55 Copyright © 2002 Nominum, Inc.55 Example Unsigned Zone $TTL ; IN SOA ( ; serial number ; refresh 3600 ; retry ; expire ; time to live ) IN TXT "$Id:,v /06/24 22:53:39 jim Exp $"

56 Copyright © 2002 Nominum, Inc.56 IN NS IN MX 10 IN A IN A

57 Copyright © 2002 Nominum, Inc.57 dnssec-signzone # dnssec-signzone \ Original (unsigned) zone file left intact zonename.signed contains signed zone file It's not pretty.....

58 Copyright © 2002 Nominum, Inc.58 Example Signed Zone File ; File written on Wed Jun 27 21:08: ; dnssec_signzone version 9.2.0a2 IN SOA ( ; serial ; refresh (3 hours) 3600 ; retry (1 hour) ; expire (4 weeks 2 days) ; minimum (1 day) ) SIG SOA ( pGsWdt8qpm58kXDqkM8DLLKxjT8qqgTny9nY8jBHEiUAx GTV+i53fsIpVJOnWalUxbkP260OAR0bTHve4voN9g== )

59 Copyright © 2002 Nominum, Inc NS SIG NS ( nyFlzAYSM/CPqDjpsHPNTqKlSwniotFqM6KH BcloIBlFOR6Tx6nCiV2Qk4VawPrRIeOAG+uc ZaV6jwrHl+Aujg== ) MX 10 SIG MX ( elYsn8kCaO42JuGKgvt7Api+Uj8wr09Dj3WM Grll2GYXFq4yeneRlq+UmiXqEZjSJXiwipKk vMn7pr2qv0T9IQ== )

60 Copyright © 2002 Nominum, Inc TXT "$Id:,v /06/24 22:53:39 jim Exp $" SIG TXT ( aKqz7FiIL1FSnFBWyVuyqgLr2p/GjBQVljTX XfqtKFCQWTSytMNVyn52buyydy80Fup5ZonN YkNfEBzQvlDViQ== ) KEY ( AQPOz/KyZAsaXxv8hbx+7lfgv4iP5twIQtyN GVnpBAMTbOykxKMJNrBdg41AufR4hItZIi76 vbd0R1emEXvPpBAZ ) ; key id = 42000

61 Copyright © 2002 Nominum, Inc NXT NS SOA MX TXT SIG KEY NXT SIG NXT ( jhBUcRSzoMCwzc1FVgOKrl+mSgv7f/Ri8/mb Q1dtGz/+0KKXa0u4s+T1SygG8wHs3Y/IOPq+ qn5YSbMtAmSajQ== )

62 Copyright © 2002 Nominum, Inc.62 IN A SIG A ( ZpD/YrrFQzeFJWENIe4U1Z2xpVmRxzBabYKw xe61bqrLsg2EuOv7CRdNwxWvEbZPN4Rf64GG oaGV97him2C10Q== ) NXT A SIG NXT SIG NXT ( dub7z+Gq4ZnJqRB1ucJfsgIsMv8WepkzrvyY +kn3NfTOGBC51tJgcyW8HMxQz/D9ig39KO8G wl6Wc7upvReUMA== )

63 Copyright © 2002 Nominum, Inc.63 IN A SIG A ( Ks14BB6UVciyfxgJ4R5eXFZrRUmnuPhTgfjQ 0r3FCyvdOr6Uu5iLSTbzgulY+qZXaXF9tCTK +65y5VxUk3WtBQ== ) NXT A SIG NXT SIG NXT ( ro1TRC7idXJw/MpLBLY/sXBlNAoLcSjKKR7t mD91i7hhW9OF4R8Ql01QU+MYrjui9kOw2isU /8BY63MCfbqlnw== )

64 Copyright © 2002 Nominum, Inc.64 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

65 Copyright © 2002 Nominum, Inc.65 Verifying with dig % dig soa ; > DiG 9.2.0a2 > soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ; IN SOA ;; ANSWER SECTION: IN SOA

66 Copyright © 2002 Nominum, Inc.66 ;; AUTHORITY SECTION: IN NS ;; ADDITIONAL SECTION: IN A ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Mon Jun 25 22:45: ;; MSG SIZE rcvd: 110

67 Copyright © 2002 Nominum, Inc.67 DNSSEC-aware query: % dig soa +dnssec ; > DiG 9.2.0a2 > soa +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, udp= 4096 ;; QUESTION SECTION: ; IN SOA

68 Copyright © 2002 Nominum, Inc.68 ;; ANSWER SECTION: IN SOA IN SIG SOA eAZ54DURplbBQEy+tuTJWuldooHEKoDB+nbKW1LL7pN2yGAI9Udsr ZURnuJSgVQehT7AWTyqV8ldAhxBKUFoyQ== ;; AUTHORITY SECTION: IN NS IN SIG NS vR28oF6X+6rswIV7X5OM9Va9XW9Kqf+hCaDzamcnMp4OT7KDpikwD dLy620Uia+VWglC0Tva5XcXVDL54VnwlQ==

69 Copyright © 2002 Nominum, Inc.69 ;; ADDITIONAL SECTION: IN A IN KEY AQPR/qMZ4euseKDELUcPQ9G8AoO8Qkv3M7jmFwUUXZDtWx6vZRJ ib0lrbVcwUMOzWu1c/lAkDb8Iv6ruhabGCcMp IN SIG KEY com. CAylEF0FQFYZOkzCquLtg9wYxFLsIb+qwVYgf+KuXBEG9txRByxC4 Ug=

70 Copyright © 2002 Nominum, Inc.70 IN SIG A TeRV2qIiXROf60KLnrwgDNaDdSYJgX4IySAjrRkeoDujXv91NU0rW nAC inLTmGVX+hrryUFwIz0BYrdhZyvIaQ== ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Mon Jun 25 22:45: ;; MSG SIZE rcvd: 600

71 Copyright © 2002 Nominum, Inc.71 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

72 Copyright © 2002 Nominum, Inc.72 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

73 Copyright © 2002 Nominum, Inc.73 Example trusted-keys Statement trusted-keys { "AMNOZhb05QlfBNuXTj VV+wsXwqAn6yhaw71smL0qTU/pWRXqom7eYFVdNUGu 4jGPWMBOXT6CRY089c1RezLhu9vj4PsF4GRrJHfwbx L/B/jyCu4x8RITdvj9eCrYIF0DWbN4TzUhOOFYSLbw 8KwfcwRFigXDPLDwAcawdLaT7dpuqzNvHXZWsuSvxb GxBX0uKOG1o4JHhBpCAUcARX/r9Z7DGCgrq2NuCqre +yRdNFPt2fgqXZOix3DeGkAYFgySFbNzIrEFG8yunk FSix7XC8XJA1Ou"; }; Public RSA key for is trusted - Verify anything signed with its private key

74 Copyright © 2002 Nominum, Inc.74 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

75 Copyright © 2002 Nominum, Inc.75 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 -Moores Law is a big help here -Crypto hardware makes it even faster Zone signing is inherently parallelisable -Multi-processor systems, clusters

76 Copyright © 2002 Nominum, Inc.76 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 cant easily be done in parallel

77 Copyright © 2002 Nominum, Inc.77 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

78 Copyright © 2002 Nominum, Inc.78 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 bit keys for signing child keys Change the keys "often enough"

79 Copyright © 2002 Nominum, Inc.79 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

80 Copyright © 2002 Nominum, Inc.80 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

81 Copyright © 2002 Nominum, Inc.81 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 ??% -High levels of DNS cluelessness No top-level domains are signed yet

82 Copyright © 2002 Nominum, Inc.82 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

83 Copyright © 2002 Nominum, Inc.83 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

84 Copyright © 2002 Nominum, Inc.84 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

85 Copyright © 2002 Nominum, Inc.85 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

86 Copyright © 2002 Nominum, Inc.86 DNSSEC Future Some registries are planning to sign their TLDs for real -Projects under way in Netherlands, Sweden & Germany -RIPE's tree -Verisign/NSI's plans Further protocol extensions -The DS (Delegation Signer) record -Opt-in Alterations to NXT record

87 Copyright © 2002 Nominum, Inc.87 The DS Record Another new record type: Delegation Signer -Here is the name of a meta-key that Ive signed Parent signs child zones meta key Childs meta key signs childs 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

88 Copyright © 2002 Nominum, Inc.88 Opt-In Changed semantics for the NXT record -Points to next signed name in a zone -Probably a delegation Big win -99.9% of names there may never be signed Makes signed zones smaller - not everything needs to be signed IETF standarisation just about complete

89 Copyright © 2002 Nominum, Inc.89 Summary This section has covered: Secure DNS (DNSSEC) Resource records for DNSSEC Some of the problems in deploying DNSSEC Potential uses of Secure DNS

Download ppt "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."

Similar presentations

Ads by Google