Using Digital Signature with DNS

DNS structure Virtually every application uses the Domain Name System (DNS). DNS database maps: –Name to IP address = –And many other mappings (mail servers, IPv6, reverse…) Data organized as tree structure. –Each zone is authoritative for its local data.

Example of Zone file Example Zone file dacht.net 7200 IN SOA ns.ripe.net. olaf.ripe.net.( ; Serial ; Refresh 12 hours ; Retry 4 hours ; 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 host25.dacht.net 2600 IN A

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

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

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

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.

Simple attack

More complex attack

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.

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.

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

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

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

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

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)

Key record RRlabel TTL IN KEY freeswan.nl IN KEY ( AQPRv8TN8ayfxrtRo1dveOMVSSpT4PGEZvfGjaERldQZ izYKgVBj/l84DjVktGUbkJ3pBiLBAzZ+5nbGkWn+Lz5Z gHMlQnjWde/mKKDlZnwQ13vU+HPt3cszNy9CdBmn6l8= ) ; key id = 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

The SIG record RRlabel TTL IN SIG freeswan.nl IN NS ns.xtdnet.nl. freeswan.nl IN NS ns1.xtdnet.nl. freeswan.nl IN SIG NS ( freeswan.nl. bTKJvyrwmP+nsFoE8oelC4gFqoyJxkawNIExMVupI+ie NeyUYdkrpDVBF5yn7U0dLxQu/+wqbOGYjPWx/r1ybZF7 JMd1PRefb30TsBtsrA9Ah13EKmO18oyJEZdDWwPV )

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

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

The DS record Sign a hash of the child key RRlabel TTL IN DS freeswan.nl IN NS ns.xtdnet.nl. freeswan.nl IN NS ns1.xtdnet.nl. freeswan.nl IN DS ( C7D3B76F7DEE10E6A73B7D0F6EDAF55FFF60CA78 ) freeswan.nl IN SIG DS ( 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.

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.

THANK YOU QUESTIONS ?