Resolving Content Names in DNS: Does it scale?
31 May 2016
Today, the replication of content or services over several strategically placed locations is a common method used by many service providers to improve performance and scalability. The user is redirected to the nearest server location, and this approach helps to reduce network impact on the response time of the user requests. There is increasing interest from service provider side in content lookup and transfer schemes working on a fine granularity level, i.e., per content name in contrast to todays host-centric abstractions. Clean-slate Information-Centric Network (ICN) architectures have been developed to address the demand for efficient access to named data as the main use case of the Internet. Such architectures are based on location-independent content naming rather than location-oriented host addressing and are implemented employing name-based addressing and routing principles. However, many of those proposals envision significant upgrades to the entire network infrastructure to support name-based routing and persistent caching. It has been proposed that some of the ICN benefits can also be achieved in today's IP-based networks through a number of modifications of the Domain Name System (DNS), enabling its servers to resolve content or named data objects (NDO) names. However, using DNS to resolve NDO dramatically changes the usage patterns of DNS and is it not clear if todays DNS designs will be able to support this new use. So far, scalability and performance of such a system has not been evaluated in a quantitative way. Given that the global DNS system, especially at the root and top-levels, already experiences significant load levels we systematically evaluate if DNS would be able to serve as a name resolution system for NDOs. Specifically we address the following questions: How many additional records need to be stored at the authoritative servers? Which query load is expected at the DNS resolvers, and which cache size is required? Which resources are required where in the DNS hierarchy to cope with the additional load, and which modifications can improve performance and reduce load? Our results indicate that such a use is possible if the resulting system is carefully designed and resources are added to the critical DNS parts.