Modeling DNS Security: Misconfiguration, Availability, and Visualization

1. 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.

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

3. 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

4. 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

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

6. 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

7. 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

8. 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

9. 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 ? RRSIG Answer: DNSKEY… validate Answer: 192.0.2.16 AD authoritative server recursive/validating resolver stub resolver 9

10. Chain of trust Resolver trust anchor . DNSKEY • 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 Zone data DS com DNSKEY Zone data DS bar.com DNSKEY Zone data 10

11. 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

12. 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

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

14. 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

15. 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

16. 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

17. DNSSEC Deployment Survey • Polled ~1500 production signed zones over a six-week period • Recorded validation errors resulting from misconfiguration

18. Failure Potential of Zones

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

20. 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

21. 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

22. 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

23. Hierarchical Reduction Potential

24. Administrative complexity

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

26. 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

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

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

29. 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

30. 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

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

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

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

35. Some authoritative servers for kiae.ru not serving RRSIGs

36. Some authoritative servers for dshield.org have expired RRSIGs

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

38. Misconfiguration in a complex system of DNS dependencies

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

40. 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

41. 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

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

43. Questions? • ctdecci@sandia.gov

44. 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)

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

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