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: ?
Answer:

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

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

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
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%)

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

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

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:

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: ?
Answer:

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?

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