Modeling DNS Security: Misconfiguration, Availability, and Visualization Casey Deccio Sandia National Laboratories BYU Computer Science Dept. Colloquium Sep 9, 2010 Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.

Criticality of the DNS The DNS is the “phone book” for the Internet Domain name to IP address translation Mail server lookup Service discovery Most Internet applications rely on DNS name resolution Query: www.foo.com/A ? Answer: 192.0.2.16

Availability and security DNS must be both available and accurate Security was added as a retrofit Security increases complexity Troubleshooting is difficult Misconfigurations abound, rendering name resolution unavailable Examples: medicare.gov, nasa.gov, arpa

Objectives Establish model and metrics for assessing availability of DNSSEC deployments Quantify complexity that may increase potential for DNSSEC misconfiguration Introduce techniques to mitigate effects of misconfiguration Query: www.foo.com/A ? Answer: 192.0.2.16 4

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

DNS namespace Namespace is organized hierarchically DNS root is top of namespace Zones are autonomously managed pieces of DNS namespace Subdomain namespace is delegated to child zones . com net baz.net bar.com foo.com

DNS name resolution Resolvers query authoritative servers Queries begin at root zone, resolvers follow downward referrals Resolver stops when it receives authoritative answer … . Query: www.bar.com/A ? … com Answer: 192.0.2.16 … bar.com stub resolver recursive resolver authoritative servers

DNS attacks Tainted DNS responses can direct users to malicious services To forge DNS responses: Guess query ID and UDP source port Arrive before legitimate response Attackers success rate increased by: Eliciting queries of the resolver Sending large number of responses attacker Query: www.bar.com/A ? bar.com Answer: ?? stub resolver recursive resolver authoritative servers

DNS Security Extensions (DNSSEC) DNS data signed with private keys for authentication Signatures (RRSIGs) and public keys (DNSKEYs) published in zone data Resolver response If authentic: Authenticated data (AD) bit is set If bogus: SERVFAIL message is returned Query: www.bar.com/A ? Query: www.bar.com/A ? bar.com Answer: 192.0.2.16 RRSIG Query: bar.com/DNSKEY ? validate Answer: DNSKEY… RRSIG Answer: 192.0.2.16 AD authoritative server recursive/validating resolver stub resolver 9

Chain of trust DNSKEY must be authenticated Resolver trust anchor . DNSKEY must be authenticated Resolver must have some notion of trust Trust extends through ancestry to a trust anchor at resolver DS resource record – provides digest of DNSKEY in child zone DNSKEY Zone data DS com DNSKEY Zone data DS bar.com DNSKEY Zone data 10

Insecure delegations Resolver trust anchor If child zone is unsigned, resolver must be able to prove it is insecure NSEC resource records provide proof of absence of DS . DNSKEY Zone data DS net DNSKEY Zone data NSEC/DS baz.net Zone data 11

DNSSEC maintenance RRSIGs must be periodically resigned to prevent expiration DNSKEYs must be periodically rolled (replaced) to avoid prolonged exposure Rollovers involving DS RRs must be coordinated with parent zones Authoritative servers must serve consistent data 12

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

Classes of DNSSEC misconfiguration Zone misconfigurations Missing, expired, or bogus RRSIG Missing DNSKEYs Delegation misconfigurations No DNSKEY in child matching any DS in parent Missing NSEC RRs for insecure delegation Trust anchor misconfiguration Stale trust anchor at resolver

Failure potential Probability of bogus validation Based on fraction of responsive authoritative servers serving bogus or incomplete data Resolvers will retry if server non-responsive Not all servers will retry if server responds with bogus data Assumption: resolver queries any authoritative server with equal probability bar.com Valid Bogus Non-responsive authoritative server recursive/validating resolver

Failure potential Formula extends to chain of trust in ancestor zones Failure potential of each zone is combined independently of one another … . … com … bar.com Recursive/validating resolver 16 authoritative servers

DNSSEC Deployment Survey Polled ~1500 production signed zones over a six-week period Recorded validation errors resulting from misconfiguration Statistic Value Production signed zones polled 1,456 Total misconfigurations resulting in certain failure 194 Zone-class misconfigurations 134 (69%) Delegation-class errors resulting in certain failure 60 (31%) Errors (any class) caused by misconfigured ancestor zones 61 (31%)

Failure Potential of Zones

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

Complexity analysis Complexity creates potential for misconfiguration Hierarchical complexity: Size of ancestry (zone depth) Administrative complexity: Servers administered by distinct organizations … . … com … bar.com 20 20

Hierarchical reduction potential If ancestry might reasonably be consolidated, what is the reduction? Ancestry reduced, but original namespace can be preserved . . com com = 0.25 bar.com bar.com sub.bar.com

Administrative Complexity How diverse is the set of organizations administering a zone? Complexity measured by random sampling (with replacement) of authoritative servers to determine the probability that two organizations are selected bar.com ns.bar.com me.baz.net = 0.5

Hierarchical Reduction Potential

Administrative complexity

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

Avoiding and mitigating effects of misconfiguration Follow best practice operational standards (RFCs) Key rollover procedures Trust anchor rollover procedures Validation diligence Resolver keeps trying alternative authoritative servers to find valid response Optimality can be difficult – where is the break in the chain? Implemented in BIND 9

Soft anchoring DNSKEYs typically don’t change often . DNSKEYs typically don’t change often Resolvers configured with “hard” (traditional) trust anchors “Soft” anchors are derived from DNSKEYs authenticated from existing hard anchors DNSKEY Zone data DS com DNSKEY Zone data DS Resolver Hard anchor bar.com DNSKEY Soft anchor Soft anchor Zone data

Impact of soft anchoring . Resolution not inhibited by: zone-class misconfigurations in ancestry delegation-class misconfigurations DNSKEY Zone data DS com DNSKEY Zone data DS Resolver Hard anchor bar.com DNSKEY Soft anchor Soft anchor Zone data

Maintaining soft anchors Resolvers follow procedure similar to that used for rolling hard trust anchors (RFC 5011) Resolver periodically polls soft anchor zone Soft anchor addition: Newly authenticated DNSKEYs persist for “hold down” period New DNSKEY seen with corresponding DS Soft anchor removal: Delegation to soft anchor made insecure DNSKEY is revoked DNSKEY and its DS RR are removed

Soft anchoring limitations Doesn’t help when misconfigurations are at or below the bottom “link” in the chain of trust Resolver must have authenticated soft anchors through valid chain of trust before misconfiguration Scalability Maintenance overhead of all trust anchors may be intense Least-recently used policy may help

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

DNSSEC Visualization Live analysis of DNS authentication chain at: http://dnsviz.net/

arpa: the “root” of reverse name resolution RRSIG expired, invalidating NSEC necessary to prove insecure delegation

Some authoritative servers for kiae.ru not serving RRSIGs

Some authoritative servers for dshield.org have expired RRSIGs

medicare.gov: missing appropriate DNSKEY, resulting in broken delegation

Misconfiguration in a complex system of DNS dependencies

Outline DNS/DNSSEC background DNSSEC availability model DNS complexity analysis Misconfiguration mitigation DNSSEC visualization Summary and future work

Summary DNS responses must be both accurate and available DNSSEC deployment requires careful deployment and maintenance Soft anchoring can mitigate effects of misconfiguration DNSSEC visualization helps understanding and troubleshooting Query: www.foo.com/A ? Answer: 192.0.2.16

Future work Internet draft of soft anchoring to gain community support Improved usability of DNS visualization tool Monitoring and alerting Better analysis of server inconsistencies

Acknowledgements Jeff Sedayao, Krishna Kant at Intel Corporation Prasant Mohapatra at UC Davis

Questions? ctdecci@sandia.gov

Visualization components Domain name DNSKEY/DS RR SEP Revoke Published DNSKEY attributes Missing Trust anchor Missing NSEC proving non-existence of DS RRs (insecure delegation)

Visualization components Alias dependency Valid Bogus Expired Missing Signature or digest Secure Bogus Insecure Misconfigured Delegation Sufficient Insufficient Proof of insecure delegation

The bottom line Status of nodes in graph, based on chain of trust Secure Bogus Insecure