1. Security and Information Assurance for the DNS Dan Massey USC/ISI

2. 13 May 032masseyd@isi.edu l Virtually every application uses the Domain Name System (DNS). l DNS database maps: n Name to IP address www.isc2033.com = 207.127.135.80 n And many other mappings (mail servers, IPv6, reverse…) l Data organized as tree structure. n Each zone is authoritative for its local data. Root edumilcom darpaisiicc2003usmc nge quantico The Domain Name System

3. 13 May 033masseyd@isi.edu Current State: Data Availability l Original DNS design focused on data availability n DNS zone data is replicated at multiple servers. n A DNS zone works as long as one server is available. –DDoS attacks against the root must take out 13 root servers. l But the DNS design included no authentication. n Any DNS response is generally believed. n No attempt to distinguish valid data from invalid. –Just one false root server could disrupt the entire DNS.

4. 13 May 034masseyd@isi.edu Limitations of Availability Caching DNS Server Manu’s Laptop www.icc2003.com? www.darpa.mil 128.9.128.127 First response wins! Root DNS Server com DNS Server Icc2003.com DNS Server Dan’s Laptop Easy to observe UDP DNS query sent to well known server on well known port. www.icc2003.com 192.5.18.19 Second response is silently dropped.

5. 13 May 035masseyd@isi.edu New Approach: Add Authentication l Each DNS zone signs its data using a private key. n Recommend signing done offline in advance l Query for a particular record returns: n The requested resource record set. n A signature (SIG) of the requested resource record set. l Resolver authenticates response using public key. n Public key is pre-configured or learned via a sequence of key records in the DNS heirarchy.

6. 13 May 036masseyd@isi.edu “Secure” DNS Query and Response Caching DNS Server End-user www.icc2003.com www.icc2003.com = 192.5.18.195 Plus (RSA) signature by icc2003.com Attacker can not forge this answer without the icc2003.com private key. Authoritative DNS Servers DNS Security Extensions: add public key signatures to the protocol manage/learn DNS public keys

7. 13 May 037masseyd@isi.edu So Why Aren’t We There Yet l Deployment in Existing Infrastructure is Hard n Strengthen some aspects, but add stress to existing weak points (ex: NS record consistency in DNS) l Original Design (RFC 2535) was fatally flawed n Key management was an after thought. n Operations must be simple if hope to deploy. n Ignored operations and business model issues. l Cryptography alone is not the answer. n Adds new DoS due to crypto errors & attacks –Must first ensure data availability n View as one fence that enables other services.

8. 13 May 038masseyd@isi.edu Questions Cryptography is like magic fairy dust, we just sprinkle it on our protocols and its makes everything secure - See IEEE Security and Privacy Magazine, Jan 2003