1. Using Digital Signature with DNS

2. DNS structure 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.

3. Example of Zone file Example Zone file dacht.net 7200 IN SOA ns.ripe.net. olaf.ripe.net.( 2001061501 ; Serial 43200 ; Refresh 12 hours 14400 ; Retry 4 hours 345600 ; Expire 4 days 7200 ; Negative cache 2 hours ) dacht.net 7200 IN NS ns.ripe.net. dacht.net 7200 IN NS ns.high5.net. pinkje.dacht.net 3600 IN A 193.0.1.162 host25.dacht.net 2600 IN A 193.0.3.25

4. DNS resolving stub resolver Question: www.cnn.com www.cnn.com A ? resolver. www.cnn.com A ? ask.com server the ip address of.com server.com www.cnn.com A ? ask cnn.com server the ip address of cnn.com server cnn.com www.cnn.com A ? xxx.xxx.xxx.xxx add to cache www.cnn.com lab.cs.umass.edu dns.cs.umass.edu

5. DNS Vulnerabilities Client DHCP Server Client Resolver Resolver itself (rootfile) Resolver's communication to the net Various glue records and their update mechanism Various nameserver nameserver communication Various network network communication

6. Focus on vulnerabilities Data Protection Server Protection Zone file slaves master resolver stub resolver Zone administrator Dynamic updates Cache pollution by Data spoofing Unauthorized updates Corrupting data Impersonating master Cache impersonation

7. Historical reasons 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. Just one false root server could disrupt the entire DNS.

8. Simple attack

9. More complex attack

10. What is the problem ? 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. –Must maintain a working DNS for old clients.

11. What is solution ? Each DNS 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.

12. Protect DNS with digital signature Secure client resolver communication –Secure LAN/DHCP –DNSSEC aware Resolver on Client(!) Secure communication between nameservers –Zone transfers (AXFR) –dynamic updates Secure data storage integrity –Zonefiles –Caches

13. DNSSEC The core of the DNSSEC specification is described in the following 3 RFCs, published March 2005: RFC 4033 - DNS Security Introduction and RequirementsDNS Security Introduction and Requirements RFC 4034 - Resource Records for the DNS Security ExtensionsResource Records for the DNS Security Extensions RFC 4035 - Protocol Modifications for the DNS Security ExtensionsProtocol Modifications for the DNS Security Extensions

14. Main Goal of DNSSEC a) origin authentication of DNS data, b) data integrity c) authenticated denial of existence.

15. New record types The KEY record: The public key used The SIG record: The signatures created by that key The NXT record: For denial of existance The DS record: For building the chain of trust

16. How does it work The DNS servers sign (digitally encrypt)the hash of resource record set with its private keys Resouce record set: The set of resource records of the same type. Public KEYs can be used to verify the SIGs The authenticity of public KEYs is established by a SIGnature over the keys with the parent’s private key In the ideal case, only one public KEY needs to be distributed off-band (the root’s public KEY)

17. Key record RRlabel TTL IN KEY freeswan.nl. 3600 IN KEY 256 3 5 ( AQPRv8TN8ayfxrtRo1dveOMVSSpT4PGEZvfGjaERldQZ izYKgVBj/l84DjVktGUbkJ3pBiLBAzZ+5nbGkWn+Lz5Z gHMlQnjWde/mKKDlZnwQ13vU+HPt3cszNy9CdBmn6l8= ) ; key id = 56954 flags: authentication, confidentiality protocol: DNSSEC = 3, IPsec = 4 [only protocol 3 is allowed since RFC3445] algorithm: RSAMD5 = 1, DiffieHellman = 2, DSA = 3, EllipticCurve = 4, RSASHA1 = 5

18. The SIG record RRlabel TTL IN SIG freeswan.nl. 3600 IN NS ns.xtdnet.nl. freeswan.nl. 3600 IN NS ns1.xtdnet.nl. freeswan.nl. 3600 IN SIG NS 5 2 3600 20030506165654 ( 20030406165654 56954 freeswan.nl. bTKJvyrwmP+nsFoE8oelC4gFqoyJxkawNIExMVupI+ie NeyUYdkrpDVBF5yn7U0dLxQu/+wqbOGYjPWx/r1ybZF7 JMd1PRefb30TsBtsrA9Ah13EKmO18oyJEZdDWwPV )

19. The NXT record RRlabel TTL IN NXT alpha.freeswan.nl. 3600 IN NXT gamma.freeswan.nl. NS SOA MX SIG KEY NXT Denial of existance: We now know there is no RRset beta.freeswan.nl.

20. Delegation problem The Parent should securely delegate authority of the child zone –Parent cannot give a “non-authoritative” answer Parent cannot not sign child zone data –It has no private key of child Parent should not sign child zone data –It is not authoritative for child zone Parent will need to serve NS (and perhaps glue) records of child zone Answer needs to be secure

21. The DS record Sign a hash of the child key RRlabel TTL IN DS freeswan.nl. 345600 IN NS ns.xtdnet.nl. freeswan.nl.345600 IN NS ns1.xtdnet.nl. freeswan.nl.345600 IN DS 49601 5 1 ( C7D3B76F7DEE10E6A73B7D0F6EDAF55FFF60CA78 ) freeswan.nl.345600 IN SIG DS 1 2 345600 20030416070311 ( 20030409070311 6869 nl. W2pmK7IGF1W7SDJxyyTep707lDRQ36IEkmyEhezJO72U 3g1YeWTI4r5lSAOkGW/+u74FRuQgMFzYzRisCZKYCiBm rNiatRg+TTf9+yzJcqg9A2CuygNBi8I7aVloYxsM+qri 9J1CJQuxAzbKLPAppQw4UP1VOiB4NvHWG2jwFNw= ) - These are all the freeswan.nl records at the parent - Parent only signs DS record for which it is authoritative.

22. Is it deployed Standard since 2005 Not yet deployed at a large scale !! Considerable overhead (CPU, network). No major attacks against DNS justify the need. Could we consider it as a “failed” case for security ? Telnet was replaced by SSH, FTP replace with secure version. Only DNS and SMTP remain totally unsecured.

23. THANK YOU QUESTIONS ?