The Domain Name System (DNS) is a part of the Internet protocol suite (TCP/IP) and is a naming system for the Internet resources. DNS was designed in the early 1980s, and was launched in 1985; it has since become a core service of the Internet. The Internet has two namespaces: domain names and IP addresses: IP addresses (numerical) are assigned to every device that connects to the Internet, and domain name addresses (alphanumeric) are used to easily locate IP addresses. IP addresses (Internet Protocol) were designed before DNS, but it was always acknowledged that using numerical addresses to find resources was not user-friendly. The solution was the Domain Name System (DNS): which consists of alphanumeric domain names - such as internet-guide.co.uk - that are easy to memorise and can be mapped to an IP address; resulting in user's only needing to know a domain name to find a resource on the Internet.
The roots of the Domain Name System can be traced back to the ARPANET computer network (forerunner to the Internet) when computer scientists attempted to improve the simplicity of finding resources on it. ARPANET was based upon a numerical address system (Assigned Numbers List), which was maintained by Stanford Research Institute and Jon Postel at the Information Sciences Institute (ISI). Due to the difficulty of memorising numerical addresses, host names with alphabetical character strings were introduced to ARPANET. While alphabetic hostnames were useful for identifying host computers, the underlying network still used numeric addresses.
The Stanford Research Institute created the Network Information Center (NIC) in 1972 - Elizabeth "Jake" Feinler headed the project - to manage the list of host names. Jon Postel assigned the numbers, and the Network Information Center (NIC) distributed them and handled inquiries from users. The NIC distributed a master list of hostnames, mapped to numerical addresses, in a text file named: HOSTS.TXT. The problem with this system was that each ARPANET node (location) had to manually download and update their HOSTS.TXT file. This became a problem as more and more nodes were added to ARPANET, and the inherent unreliability of relying on nodes to manually update a single HOSTS.TXT file became apparent.
By the early 1980s, the early ARPANET protocols had been replaced with TCP/IP, but, the problem still remained for finding a refined solution for mapping numerical addresses to host names. A meeting was held on the 11th of January 1982 - at the USC Information Sciences Institute - to solve the problem and an "interesting idea" was suggested at this meeting: the idea was 'Name Domains' (RFC 805). In 1983, Paul Mockapetris was asked by Jon Postel to evaluate a range of proposals for 'Name Domains' which Mockapetris developed into the Domain Name System (DNS). The Domain Name System was implemented in 1984, and it would become a centralised system for distributing and resolving naming issues on TCP/IP networks (ARPANET and the Internet etc). The specification of the Domain Name System (DNS) was outlined in the following RFC documents: RFC 881, RFC 882, RFC 883, RFC 1034 and RFC 1035.
(Pictured: Paul Mockapetris)
In 1990, according to RFC 1174, the management of Internet numbers was still 'in the hands' of a central authority; named in this RFC as the Internet Assigned Numbers Authority (Jon Postel) and an Internet Registry (IR) named the Network Information Center (DDN-NIC). The DNS root zone was administrated exclusively by IANA from 1984-1998; Jon Postel was the head of IANA during this period. From 1984-1990, the Defense Data Network Information Center (DDN-NIC) administrated the Top Level Domains of the DNS (com, net, org, edu etc) and provided a root name server.
However, in 1990, the Internet Activities Board (IAB) proposed a change to the centralised control of the Domain Name System (DNS): while IANA would continue to manage the root zone of the DNS, management of the Top Level Domains would transfer from the Network Information Center (NIC) to Network Solutions, Inc. (NSI), and from its management location of SRI International to Government Systems (GSI). Network Solutions, Inc. (NSI) would initiate a fee structure for registering domain names; previously they were given out for free. By 1998, there was a concern that a monopoly had formed in relation to the management of Top Level Domains. Another issue would also arise, initiated by Jon Postel.
In 1998, Jon Postel caused controversy when he instructed eight regional root name servers to change the root zone server they "pulled" information from (to IANA); essentially hijacking control of the Internet. In response, the (NTIA) National Telecommunications and Information Administration of the (DOC) United States Department of Commerce created a document named: "A proposal to improve technical management of Internet names and addresses". The U.S. government was obviously alarmed by the power Jon Postel (who created IANA, alongside Joyce Reynolds) yielded upon the Internet.
The result of the NTIA document was the creation of ICANN in 1998; IANA became a department within it. ICANN was created as a non-profit organisation, but it was under contract from the United States Department of Commerce (DOC). The NTIA provided oversight. ICANN has managed the Domain Name System (DNS) from 1998 to the present day, and assigns organisations to manage zones in the DNS and accredits registrars to manage domain names on behalf of registrants; such as IANA who manage the DNS root zone.
There was demand - supported by many of the pioneers of the Internet - to transition management of the namespace of the Internet from the U.S. government to a global multi-stakeholder community. In 2013, the 'Montevideo Statement on the Future of Internet Cooperation' was released, signed by leaders of many important Internet organisations: it warned against NSA surveillance of the Internet, and urged for greater international oversight of the Internet.
On the 1st of October 2016, ICANN was freed from its United States Department of Commerce (DOC) oversight contract. ICANN now had the "keys to the kingdom", with ultimate authority over the Domain Name System (DNS) and Internet numbers; the namespace of the Internet has passed to an international multi-stakeholder arrangement.
Due to the importance of the Domain Name System (DNS), management and maintenance is required. While the Internet has no central government, the assignment of "space" (IP, DNS, ASN) on the Internet is strictly managed. The Domain Name System is managed by the following organisations:
(Pictured: ICANN's management of the DNS, and Verisign's of the .com registry has remained controversial)
The Domain Name System is a hierarchical system, and at the top of the hierarchy is the DNS root zone. IANA manages the DNS root zone - with oversight provided by ICANN - by administrating the data (root zone file) in the root name servers. Alongside maintaining the Root Zone File, ICANN also maintains the Root Zone Database (information published in the WHOIS service) and manages the Key Signing Key (KSK): which provides DNS security using DNSSEC. ICANN creates policy for root zone management through advice provided by two technical bodies: Root Server System Advisory Committee (RSSAC) and the Security and Stability Advisory Committee (SSAC).
ICANN assigns organisations to manage Top Level Domains (such as the com domain) and accredits registrars who buy and manage namespace - on behalf of companies and individuals - within these Top Level Domains. There are currently in the region of 1000 accredited registrars (such as GoDaddy); some of who assign third party registrars. Global policy for Top Level Domains is developed by two ICANN organisations: Generic Names Supporting Organization (GNSO) and Country Code Names Supporting Organization (ccNSO).
ICANN also delegates responsibility for IP number assignment, and some DNS functions, to five regional Internet registries; who comprise the Number Resource Organization. While ICANN is the ultimate authority for managing the Domain Name System (DNS), it does so be delegating administrative responsibility to a range of organisations and also sets policy by taking advice from a range of committees; some of which are comprised of representatives from national governments and super-national bodies.
The Domain Name System is structured in hierarchical zones, which are:
The DNS root zone is the highest zone within the Domain Name System, and is name-less.
When examining the domain name google.com, it is fairly obvious it consists of two labels; which are separated by dots (.). Labels are limited to sixty-three characters and the characters allowed in the label are from a ASCII character set. The importance of the label - in terms of its hierarchy - moves from right to left. Each label, which is to the left, can be described as a subdomain of the label to it's right. The amount of subdomains is restricted to one hundred and twenty-seven. For the domain google.com the com label is the Top Level Domain and google label is the Second Level Domain. In theory, there is virtually no end (127) to the amount of domain name subdomains, but most domain names do not exceed the following: example.co.ss.co.com. The full domain name is limited to two hundred and fifty-three characters.
There are two kinds of name servers: authoritative name servers and cache name servers.
The purpose of authoritative name servers is to store DNS records for domain zones and to respond to queries. DNS resource records have different record types, such as 'AAAA', which is a 128-bit IPv6 address. Authoritative name servers are structured in a hierarchy, with the highest level being the root name servers; listed below. The root name servers store data - in a root zone file - about the Top level domains; this data is provided to the root name servers by the Internet Assigned Numbers Authority (IANA). Therefore, the root name servers are an authoritative source for any query related to a Top Level Domain. The operators of Top Level Domains - assigned by ICANN - run authoritative name servers for their zone and also creates and publish a zone file for all the active domain names in their zone. Therefore, the DNS zone descends like a tree structure with individual organisations and authoritative name servers responsible for each zone.
(Pictured: DNS servers come in different varities, such as root servers and dns resolvers.
The DNS root zone is currently served by thirteen authoritative root name servers, which are: a.root-servers.net VeriSign, Inc.; b.root-servers.net University of Southern California (ISI); c.root-servers.net Cogent Communications; d.root-servers.net University of Maryland; e.root-servers.net NASA (Ames Research Center); f.root-servers.net Internet Systems Consortium, Inc.; g.root-servers.net US Department of Defense (NIC); h.root-servers.net US Army (Research Lab); i.root-servers.net Netnod; j.root-servers.net VeriSign, Inc.; k.root-servers.net RIPE NCC; l.root-servers.net ICANN; and m.root-servers.net WIDE Project. There is no single server for each root name server, the burden is spread across multiple locations; for example, the LINX (London Internet Exchange) provides services for the k.root-servers.net RIPE NCC root nameserver.
The other type of name server is a cache name server: these are operated by DNS resolvers - DNS resolvers are typically operated by Internet Service Providers. Cache name servers store DNS lookup queries from its users to improve performance and lessen the burden on the authoritative name servers.
The Domain Name System (DNS) is run on a client-server model, with end-users using a client to query authoritative name servers that store data records for domain names. The client side of the DNS process is referred to as a DNS resolver or a DNS lookup. The purpose of the resolver is to initiate and finish a DNS query, and does so by translating a domain name (inserted into the client) into an IP address (stored on a name server). DNS resolvers can resolve a query by using one of three query processes: non-recursive, recursive, or iterative queries. Non-recursive queries will only query a single name server, recursive queries will be passed to more than one name server if they receive an inadequate response from the first name server, and iterative queries will query name servers in a chain process. DNS resolvers typically cache their queries locally in a cache name server. A reverse DNS lookup can also be performed: this is when a IP address is known but not the domain name(s) operating on it. DNS queries use the User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) to serve their request.
The DNS resolver is not directly interacted with by users; their web client (browser) will handle the process in combination with their local operating system. Most modern operating systems include networking software; such as Windows 10. Typically, the networking software of an operating system can be manually configured. Generally speaking, the network settings will be set to use the DNS server of the users Internet Service Provider, but it can be manually changed to a third party DNS server. What are the reasons for doing so? To improve performance, improve security, bypass censorship, protect against phishing, and to implement parental controls. Not all Internet Service Providers provide good DNS resolvers and caching services.
The question may arise, why aren't all domain queries routed through the root nameservers: for performance, the root nameservers could not handle billions of requests, and, therefore, the burden is spread amongst a hierarchy of name servers that store DNS records and respond to queries. Therefore, the Domain Name System is often described as a distributed database. Name servers typically use the BIND (Berkeley Internet Name Domain) DNS software to handle DNS queries.
Top Level Domains (TLDs) are managed by an organisation assigned by ICANN; these organisations do not own the Top Level Domain, they are under contract from ICANN to manage the domain for a specified amount of time. The com Top Level Domain has been managed by more than one organisation in its history (Network Solutions (NSI) and Versign). Organisations who operate a Top Level Domain are responsible for the following: publishing a zone file; operating a authoritative nameserver; and maintaining a registry database; amongst other requirements outlined in ICANN's registry agreement.
Companies, organisations, and individuals can register a namespace within a Top Level Domain, which is called a Second Level Domain (such as the namespace google within the com domain). However, some Top Level Domain managers (like Nominet for the uk ccTLD) have previously imposed Third Level Domains, for example: co.uk, ac.uk. This meant that a registrant could not register a Second Level Domain within the uk Country Code Top Level Domain (recently changed with the introduction of the uk Top Level Domain).
The registration of a Second Level Domain - by the general public - is conducted via registrars; who are accredited by ICANN. Registrars register Second Level Domains on behalf of registrants. Registrars have to pay a fee to the organisation who manages a Top Level Domain; for example, the registrar GoDaddy has to pay a fee to Nominet to register a namespace within the uk Top Level Domain. ICANN also receive a small fee from every TLD registration. The process of registering a Second Level Domain is as follows:
There are currently over 1000 Top Level Domains and over 900 accredited ICANN registrars who can facilitate the registration process.
Abuse and Disputes
Abuse of domain names and the Domain Name System does occurred. Cyber squatting is usually viewed as one such abuse: where end-users buy a domain name just so that another interested "party" cannot, and then, either extorts a fee to sell it, or hold onto it out of spite (the ethical version of cyber squatting is DNS parking: registering a domain name with the intention of using it in the future).
Domain name disputes occur for a multitude of reasons: when a registrar goes out of business, cannot be contacted, or purposely/mistakenly registers a domain names in their own name instead of the registrant's. ICANN publish guidelines for registrar's, and they accredit registrar's; therefore, ICANN is the ultimate authority for resolving disputes for gTLD's. For ccTLD's (like the uk domain administered by Nominet) guidelines and disputes are resolved by the country code manager.
Transfer a Domain Name
As previously discussed, end-users have to register domain names through accredited registrars. The registrar is a 'middle man' who contacts the manager (registry) of a domain to purchase a namespace - at that domain - on behalf of the end-user. Registrars also manage the domain name on behalf of the end-user; renewing the domain and alteration to the DNS record. Some registrars allow full DNS control of a domain name, while others do not. ICANN - who accredit registrars - allow end-users (registrants) to switch registrars; which is outlined in their 'The Inter-Registrar Transfer Policy'. The current manager (registrar) of a domain name can charge a fee for transferring a domain name to another registrar, but, the process for transferring domain names does vary slightly for each type of domain. The 'Initial Authorization for Registrar Transfer form' is used for transferring a range of gTLD's (not mil and gov domains), but, the IPS TAG is used by Nominet to switch uk ccTLD's.
Further reading: Transferring a co.uk domain name address