Some aspects of DNS and its design invariably impact our approach, and the most important is trust and verification. The central issue is whether it is possible for a requestor to determine that its peer has correctly resolved the request, and that the result provided is actually a valid IP address for the given name. This issue arises if peers can be compromised or are otherwise failing.
Unfortunately, we believe that a general solution to this problem is not possible with the current DNS, though certain fault models are more amenable to checking than others. For example, if the security model assumes that at most one peer can be compromised, it may be possible to always send remote requests to at least three peers. When these nodes respond, if two results agree, then the answer must be correct. However, DNS does not mandate that any of these results have to agree, making the general case of verification impossible.
Many server-side DNS deployments use techniques to improve performance, reliability, or balance load and locality. For example, round-robin DNS can return results from a list of IP addresses in order to distribute load across a set of servers. Geography-based redirection can be used to reduce round-trip times between clients and servers by having DNS lookups resolve to closer servers. Finally, DNS-based content distribution networks will often incorporate load balancing and locality considerations when resolving their DNS names. In these cases, multiple lookups may produce different results, and lookups from different locations may receive results from different pools of IP addresses.
While it would be possible to imagine extending DNS such that each name is associated with a public key, and each IP address result is signed with this key, such a change would be significant. DNSSEC [6] attempts smaller-scale change, mainly to prevent DNS spoofing, but has been in some form of development for nearly a decade, and still has not seen wide-scale adoption.
Given the current impossibility of verifying all lookups, we rely on
trusting peers in order to sidestep the problems mentioned. This
approach is already used in various schemes. Name owners often use
each other as their secondary servers, sometimes at large scale. For
example, princeton.edu's DNS servers act as the secondary servers for
60 non-Princeton domains. BIND supports zone transfers, where all DNS
information can be downloaded from another node, specifically for this
kind of scenario. Similarly, large-scale distributed systems running
at hosting centers already have a trust relationship in place with
their hosting facility.