We use this data to evaluate a number of ConfiDNS policies, beginning with policies that relate only to agreement, and then combining agreement and history. Our focus in this evaluation will be coverage (applicability) and latency, so we focus on how many hostnames and how many sites benefit from the various types of security the different policies provide.
We evaluate four agreement policies for ConfiDNS, varying the numbers of sites agreeing and peer set sizes. In one policy, we require that the agreement include the local DNS, but in the rest, the local DNS is just one of the sites in the agreement process. In each case, we restrict the number of peers that can be queried in order to reach agreement. Peers are selected solely by lowest RTT value from the node.
All policies are evaluated on every node, and per-node average latencies for a subset of policies are reported in Figures 4- 6. The baseline policy, using only the local DNS resolver, suffers from the problem of retries that we described in Section 3. Likewise, the policy of requiring that at least one other site (out of the five closest peers) agree with the local resolver has similar performance because the local DNS lookup time is the bottleneck. A simplified form of the CoDNS policy is shown in Figure 4, and takes the first response of the local resolver and the three nearest peers. The queries to the peers are staggered using the same delays CoDNS uses in deployment. It shows a significant response time improvement over the local DNS resolver, precisely because it does not have to wait on the local resolver when it is slow.
The more aggressive agreement policies for ConfiDNS require 3 of the 10 closes sites agreeing (Figure 5), 5 sites out of 20 agreeing (not shown), or 7 sites out of 30 agreeing (Figure 6). For practicality, we stagger lookups in these policies at the rate of 1000ms every 10 lookups for fairness. A policy of taking either the local DNS resolver and one peer, or 3 other peers, is not shown because its latency characteristics are identical to Figure 5. The most important latency observation for these more secure policies is that they perform much better than local DNS resolvers, and are in fact generally better than CoDNS. The 3-agreement policy performs surprisingly well, with an average latency almost half of CoDNS's.
We combine agreement and rate-of-change to determine the spectrum of protection policies that are possible, and how many hostnames per site can be satisfied with each. To simplify the analysis, we linearize the range of possibilities, as shown in Table 1. The process of assigning values to policies is subjective, but our goal was to give an idea of the strength of combinations, with higher numbers indicating better protection. The per-node breakdown for each label is shown in Figure 7.
The average breakdown for lookups that satisfy only label 1 (local DNS only) averages only 0.18%, which indicates that ConfiDNS improves the security of 99.82% (on average) of unique lookups from our collection of vantage points. Even if we pick a stronger security requirement, such as label 4, which indicates seven peers agreeing, 30 days of stability, or some intermediate combinations, ConfiDNS is able to satisfy 99.63% of the unique lookups. Even the strongest policy, with 7 peers agreeing and the lookup being stable for 30 days, still works for over 92% of unique lookups on average. As we showed in the earlier results, this extra security does not come at a high latency cost - latency is better than LDNS alone, and is comparable to CoDNS.
By using a policy that uses the best available security and reverts to LDNS otherwise, ConfiDNS can provide security that is never worse than LDNS. Users that are interested in lookups with security that is strictly better than LDNS will not be able to resolve 0.18% of unique names, assuming policies that meet at least label 2. To understand the types of names affected, we break down this fraction into three categories, as shown in Figure 8: those served by Akamai, those served using Akamai's DNS service, and other assorted names. Depending on how much trust the user has in one or more of these CDNs or DNS services, they could whitelist these names to further improve resolvability. The whitelist could take several forms, ranging from automatically whitelisting these names, whitelisting them if they fail to meet other security policies, or even whitelisting them as long as they map to a given set of vetted IP addresses. A full discussion of the options and their implications is beyond the scope of this paper.
 |
1