c IEEE, 2017. This is author’s version of this work. It is posted here by permission of IEEE for you personal use. Not for redistribution. The definitive version was published in the proceedings of IEEE Conference on Computer Communications and Networks (ICCCN) 2017. NDNS: A DNS-Like Name Service for NDN Alexander Afanasyev,∗ Xiaoke Jiang,y Yingdi Yu,∗ Jiewen Tan,∗ Yumin Xia,∗ Allison Mankin,z and Lixia Zhang∗ ∗University of California, Los Angeles Email: aa,yingdi,[email protected] yTsinghua University, China zSalesforce Abstract—DNS provides a global-scale distributed lookup ser- network protocol architectures to explain why naming end- vice to retrieve information of all types for a given name, be it points versus naming data results in the sharp differences IP addresses, service records, or cryptographic keys. The DNS between DNS and NDNS designs. We hope that our expe- service has proven essential in today’s operational Internet. Our experience with the design and development of Named Data rience from the design and implementation of NDNS protocol Networking (NDN) also suggests the need for a similar always-on provides insights and guidelines in adapting other IP-based lookup service. To fulfill this need we have designed the NDNS application protocols to the NDN architecture. (NDN DNS) protocol, and learned several interesting lessons through the process. Although DNS’s request-response operations II. THE NECESSITY OF A LOOKUP SERVICE seem closely resembling NDN’s Interest-Data packet exchanges, they operate at different layers in the protocol stack. Comparing This section presents a brief background of NDN and DNS’s implementations over IP protocol stack with NDNS’s im- discuss the necessity of a lookup service in NDN. At the end plementation over NDN reveals several fundamental differences between applications designs for host-centric IP architecture and of this section, we analyze the commonalities and differences data-centric NDN architecture. between NDN and DNS. Index Terms—Named Data Networking; DNS; Information- centric Networking; Future Internet Architecture A. NDN Named Data Networking (NDN) [1], [2], [3] makes named I. INTRODUCTION and secured application Data packets the centerpiece of the Named-Data Networking (NDN) [1], [2], [3] is a proposed network architecture—the “thin waist” of communication. To Internet architecture, where data consumers send Interest request Data, consumers send out Interest packets that include packets to fetch desired Data packets. Our NDN design and names or prefixes of what should be fetched. These names are development efforts over the last few years identified several then used by the NDN network forwarders to steer Interests needs for a DNS-like lookup service, e.g., to support NDN towards available (closest) Data replicas and return them back routing scalability [4], to provide rendezvous for mobile data to the requesters. producers [5], and to provide persistent storage of critical data, 1) Name-based Forwarding: NDN’s Interest-Data packet such as public key certificates [6]. exchanges are network-layer operations, and network-layer’s To meet the above needs, we have designed NDNS (NDN basic function is to make the forward decision for each DNS), a distributed, always-on distributed lookup service. packet by name, e.g., “/net/ndnsim/download/pkg/_v=2”. The NDNS design leverages the experiences learned from Each NDN router maintains a Forwarding Information Base the Domain Name Systems (DNS) and its security extensions (FIB), which contains logically a table of (name prefix, inter- (DNSSEC) [7], [8], [9], [10], [11], but also addresses the fun- face list) tuples. Upon receiving an Interest packet, an NDN damental differences in the design requirements of NDN- and router uses forwarding strategy [12] to forward this request to IP-based applications. As we discuss in Section III, NDNS and one or more interfaces, using information from the matching DNS(SEC) share the commonalities of retrieving secured data FIB entry, previously recorded data plane performance for the from hierarchically structured namespaces. However, using data’s prefix, and potentially other policy restrictions. The data names directly at the network level and securing network strategy decision is then recorded in the Pending Interest layer packets leads to fundamentally different implementations Table (PIT). Each Data packet is returned to the requester and different tradeoffs. by utilizing the state recorded in routers’ PIT, following the The contributions of this paper are threefold. First, we reverse path of the Interest. explain why the NDN architecture needs a lookup service, 2) Per-Packet Authentication: NDN mandates Data produc- given it directly uses names to retrieve data at the network ers to create digital signature on their Data packets at the time layer (Section II). Second, we design the NDNS protocol that of creation. The cryptographic signature binds the name of provides DNS-like lookup service with enriched functionality Data with its content [13], so that the content authenticity can using NDN Interest/Data primitives (Section IV). Third, we be verified independent from where a Data packet comes from. identify the fundamental differences between IP and NDN’s As a result, each NDN Data packet is immutable, any change to the carried content requires creation of a new Data packet needs to be verified. The always-on lookup service would with different (e.g., versioned) name and a new signature. make the public key certificates available to all consumers at The signature field in each NDN Data packet includes a key all times, waiving the requirement of producer provisioning its locator field which names the signing key to be used for the own certificates. This service can be a default public key stor- signature verification. A key in NDN is simply another Data age to facilitate Data verification and trust management, but packet containing the public key bits and the corresponding does not restrict NDN applications from retrieving certificates signature [13], which in turn contains its own key locator. and choose their trust model by other means. These key locators form a certification chain up to a trust anchor key that a consumer must have obtained and trust a III. NDN AND DNS priori. In this section, we present a brief summary of DNS [7], [8] 3) Efficient Data Delivery: Naming and securing data at and identify its commonality with NDN on “fetching Data” the network layer brings a number of important properties in semantics and the differences from operating at application data distribution. Since a Data packet is inherently secured and layer versus network layer, respectively. identified by the name at the network layer, NDN routers can cache Data packets (in-network caching). Multiple simultane- A. DNS ous requests for the same Data can be aggregated, providing DNS defines a globally unique tree-like hierarchical names- built-in multicast Data delivery. The intelligent forwarding pace used by all Internet applications. Each node or DNS plane of NDN can forward requests along the best path based domain of the hierarchical tree can be associated with several on realtime measurement. types of resource records (RR) under that name, grouped into RR sets. DNS namespace is managed in a distributed way by B. Operational Needs of NDN splitting it into so called DNS zones, which are responsible for Our experience with NDN design and development since hosting RR sets, including records for sub-domain delegation 2010 has identified three primary needs for an always-on to child zones. Zones are usually hosted on multiple name lookup service: to scale network routing, to support mobility servers that respond to relevant DNS queries. of Data producers, and to provide online persistent storage for Any RR set stored in DNS can be retrieved using a top-down keys when their owners go offline. approach (using so-called iterative queries), starting from the 1) Routing Scalability: NDN routers forward Interest pack- pre-configured name servers for the root zone. For example, ets by names. However, the limited size of FIB implies to discover an IPv4 address of “www.ndnsim.net”, a resolver that, in large-scale environments, only a small number of would send “what is the “A” record of “www.ndnsim.net”?” name prefixes can be stored in FIB. Therefore, NDN needs query to one of the root zone DNS servers. Depending on a way to map all application names that cannot retrieve data the available information, each server responds either with the directly over the global Internet into names that can, i.e., that requested RR set or a referral to a child zone by returning a are present in FIBs and disseminated by the global routing set of “NS” and “glue” “A” (and/or “AAAA” for IPv6) records. protocols. In the example, the root zone server would refer to a set of In a proposed secure namespace mapping solution [4], when “net” nameservers, “net” nameservers would refer to a set of necessary, content producers create forwarding hints to map “ndnsim.net” nameservers, who will finally return the desired their application data name prefixes to sets of “reachable” information. The servers can also return “NSEC” (or “NSEC3”) names. These hints [13] can be then attached to Interest records to indicate that the records does not exist. packets to guide forwarding of the Interests towards a network To scale DNS resolution, in addition to replicating authori- region (or a node) where data can be found. tative DNS servers for each zone, DNS also relies on caching 2) Mobile Publishing: While NDN’s stateful forwarding resolvers between end hosts (which run stub resolvers) and provides a natural support for data retrieval by a mobile name servers. The caching resolvers, as a response to recursive consumer, it is still a challenge to steer Interests towards queries from stub resolvers, run the iterative querying on Data when producers move.