The evolution of the internet is anchored in the phenomenon of new technologies replacing their older counterparts. But technology evolution can be just as much about building upon what is already in place, as it is about tearing down past innovations. Indeed, the emergence of cloud computing has been powered by extending an unlikely underlying component: the more than 30-year-old global Domain Name System (DNS).
The DNS has offered a level of utility and resiliency that has been virtually unmatched in its 30-plus years of existence. Not only is this resiliency important for the internet as a whole, it is particularly important for cloud computing. In addition to the DNS’s resiliency, cloud computing relies heavily on DNS capabilities such as naming schemes and lookup mechanisms for its flexibility, usability and functionality.
As far back as the original ARPANET (the precursor of the internet), communication endpoints have had both names and addresses. The association between the two was originally recorded in the classic HOSTS.TXT file, where a master copy was kept in a centralized server and copies were distributed to endpoints. Making updates to the ARPANET’s HOSTS.TXT was originally a fully centralized function coordinated by Stanford Research Institute; while the actual use of the file to lookup names and map them to network addresses was a local function, implemented within the endpoint.
That started to change in the 1980s, when Paul Mockapetris proposed the DNS, replacing HOSTS.TXT with a hierarchical naming system, with management of different parts of the overall namespace “delegated” to different endpoints. As Mockapetris noted in his design principles, “The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance.”
Emergence of Name Servers
Due to the delegation of authority, an organization could update the name-address mappings for endpoints within the organization locally without having to change the master file. But the trade-off was that lookups could no longer be implemented solely as a local function since no one had a copy of the entire file anymore.
Instead, the sending endpoint would need to interact with an “authoritative name server” for the receiving organization to get the network addresses for endpoints within that organization. And to identify the receiving organization’s authoritative name server, the sending endpoint would also need to interact with other name servers — starting with the newly defined DNS “root” servers.
Specialized computers were set up within organizations (or by their internet service providers) to perform the (now iterative) resolution process of navigating from the root to top-level domains (TLDs) and onward to the endpoint’s authoritative name server. Endpoints within the organization would then “outsource” their lookup process to the specialized servers, which were designated as recursive name servers.
Relationship Between the DNS and Cloud Computing
Like other parts of an organization’s IT infrastructure, recursive name servers can be moved from on-premise deployments into the cloud. In fact, some organizations now contract with network operators and other service providers for their recursive DNS services; this external outsourcing of DNS resolution is like an external cloud deployment, providing “DNS resolution as a service” or “Cloud DNS.” Organizations have likewise outsourced their authoritative name servers to external service providers.
But this isn’t the only relationship that the DNS has to cloud computing. The DNS also plays an important role in enabling other cloud services. Indeed, resources in cloud computing platforms are generally identified with domain names and located by DNS lookups.
For example, Amazon Web Services recommends that “buckets” of objects – the basic unit of storage in its Simple Storage Service (or “S3”) – be named according to DNS naming conventions. An appropriately named bucket can then be accessed via a Uniform Resource Identifier (URI), such as: “”. Following standard DNS processing, a browser or application would then resolve the URI into a network address for the virtual server that hosts the bucket.
Similar naming conventions can be found in other cloud services, such as Microsoft Azure Storage (e.g., “http://mystorageaccount.blob.core.windows.net/mycontainer/myblob”) and Google Cloud.
Importance of DNS-based Conventions in Cloud Computing
A DNS-based naming scheme – and consequently a DNS-based lookup mechanism – can take advantage of the capabilities built into the DNS to balance application workload across multiple servers. These capabilities are fundamental to rapid elasticity, one of the National Institute of Standards and Technology (NIST)’s five characteristics of cloud computing. In particular, a domain name can provide a “virtual name” for a resource in a cloud platform — resource instances corresponding to the name can then be deployed at many different physical locations. This gives the effect, as described by NIST, that “the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.”
The DNS “function” of mapping a fully qualified domain name to a network address — a function implemented by an authoritative name server for the cloud platform — is thus a fundamental building block for cloud computing. Indeed, in order for endpoints to interact reliably and confidently with named resources on the cloud platform, the platform’s name server must be available and accurate.
The ongoing availability and accuracy of the DNS at all levels of the hierarchy, under various workloads and attacks, is essential to the functioning of cloud-computing platforms. The higher up the DNS hierarchy, the more important resiliency becomes, because a wider range of names and services depend on it. In this sense, the DNS, one of the earliest and most successful distributed systems, may be considered today an essential function as a service: something that cloud platforms and applications all depend on.