Security and Information Assurance for the DNS Dan Massey USC/ISI.
Published byModified over 6 years ago
Presentation on theme: "Security and Information Assurance for the DNS Dan Massey USC/ISI."— Presentation transcript:
Security and Information Assurance for the DNS Dan Massey USC/ISI
13 May firstname.lastname@example.org l Virtually every application uses the Domain Name System (DNS). l DNS database maps: n Name to IP address www.isc2033.com = 126.96.36.199 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
13 May email@example.com 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.
13 May firstname.lastname@example.org Limitations of Availability Caching DNS Server Manu’s Laptop www.icc2003.com? www.darpa.mil 188.8.131.52 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 184.108.40.206 Second response is silently dropped.
13 May email@example.com 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.
13 May firstname.lastname@example.org “Secure” DNS Query and Response Caching DNS Server End-user www.icc2003.com www.icc2003.com = 220.127.116.11 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
13 May email@example.com 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.
13 May firstname.lastname@example.org 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