Changes

==1.1 Period 1983-1986==  

==1.1 Period 1983-1986==  

<div style="text-align: justify;">

<div style="text-align: justify;">

Before the development of [[DNS]], information about hosts was assigned in a flat namespace format and name-to-address lookups were done using a table, which use to be available in all the hosts. Network Information Centre (NIC) at [[SRI International]], use to maintain this table and all hosts get the updated copy from SRI-NIC periodically. At that time, most of the hosts were at [[ARPANET]] (Advanced Research Project Agency Network) and [[DND]] (Defense Data Network), and managing the host records in flat file wasn’t that tough. <ref>[https://marc.info/?l=namedroppers&m=95837667426588&w=2]</ref><ref>[https://www.donelan.com/dnstimeline.html DNS Timeline, Donelan]</ref>

Before the development of the [[DNS]], information about hosts was assigned in a flat namespace format and name-to-address lookups were done using a table, which use to be available in all the hosts. Network Information Centre (NIC) at [[SRI International]], use to maintain this table and all hosts get the updated copy from SRI-NIC periodically. At that time, most of the hosts were at [[ARPANET]] (Advanced Research Project Agency Network) and [[DND]] (Defense Data Network), and managing the host records in a flat file wasn’t that tough. <ref>[https://marc.info/?l=namedroppers&m=95837667426588&w=2]</ref><ref>[https://www.donelan.com/dnstimeline.html DNS Timeline, Donelan]</ref>

<br/>

<br/>

As the number of hosts were increasing so was the size of this flat file, and with the frequency of updates, a decentralized database need was felt. To address this problem, Mr. Jon Postel and Mr. Paul Mockapetris published a number of RFCs that laid down the design of DNS.

As the number of hosts were increasing so was the size of this flat file, and with the frequency of updates, a decentralized database need was felt. To address this problem, Mr. [[Jon Postel]] and Mr. [[Paul Mockapetris]] published a number of RFCs that laid down the design of DNS.

<br/><br />

<br/><br />

To test the DNS, Mr. [[Jon Postel]] and Mr. [[Paul Mockapetris]] set up the first root server in 1984 at the [[Information Science Institute]] (ISI) at the University of South California (USC). The domain name services were running on the software developed by Mockapetris, named JEEVES. In 1985, an additional root was added at ISI.

To test the DNS, Postel and Mockapetris set up the first root server in 1984 at the [[Information Science Institute]] (ISI) at the University of South California (USC). The domain name services were running on the software developed by Mockapetris, named JEEVES. In 1985, an additional root was added at ISI.

<br/>

<br/>

An additional root server was placed at SRI International, as it was NIC for DDN and was handling the registration of hosts and maintenance of the hosts.txt file.

An additional root server was placed at SRI International, as it was NIC for DDN and was handling the registration of hosts and maintenance of the hosts.txt file.

As NSFNet traffic and registrations grew, people became aware of some cases of poor DNS service due to the limited number and reach of root servers. To address this issue, in July 1987, at the IETF 7 meeting, the name domain planning working group held a one-hour session to discuss root servers<ref>[IETF 7 Proceedings: http://www.ietf.org/proceedings/07.pdf.]</ref>.  The goal of the meeting was to select root servers that would provide improved service to the NSFNET. The participants discussed and chose three new name servers –

As NSFNet traffic and registrations grew, people became aware of some cases of poor DNS service due to the limited number and reach of root servers. To address this issue, in July 1987, at the IETF 7 meeting, the name domain planning working group held a one-hour session to discuss root servers<ref>[IETF 7 Proceedings: http://www.ietf.org/proceedings/07.pdf.]</ref>.  The goal of the meeting was to select root servers that would provide improved service to the NSFNET. The participants discussed and chose three new name servers –

* University of Maryland, largely because it was in a position to service equally well the NSFNET, ARPANET, MILNET and SURANET.  

* University of Maryland, largely because it was in a position to serve equally well the [[NSFNET]], ARPANET, MILNET and [[SURANET]].  

* NASA Ames, because it was an ideal location due to its connection to MILNET, ARPANET, NASA-SCINET19, NSFNET and BARRNET.

* NASA Ames, because it was an ideal location due to its connection to MILNET, ARPANET, [[NASA]]-SCINET19, NSFNET and [[BARRNET]].

   

   

* Rensselaer Polytechnic Institute (RPI), which was part of the New York State Education and Research Network. It was also one of the first Internet service providers in the United States.  

* Rensselaer Polytechnic Institute ([[RPI]]), which was part of the New York State Education and Research Network. It was also one of the first Internet service providers in the United States.  

These three root servers and GUNTER-ADAM were expected to be operational by IETF 8 in November 1987. In November 1987, C.ISI.EDU was retired from root server duty. As agreed, four additional root servers were added.

These three root servers and GUNTER-ADAM were expected to be operational by IETF 8 in November 1987. In November 1987, C.ISI.EDU was retired from root server duty. As agreed, four additional root servers were added.

<div style="text-align: justify;">

<div style="text-align: justify;">

Since the 1980s, the registration of domain names was performed by the DDN-NIC under contract by the Department of Defense. This was because most registrants at the time were military users and awardees. By the early 1990s, due to the rapid growth of the NSFNET, academic institutions comprised the majority of new registrations, and the military was no longer willing to fund the registration for these names. The U.S. Federal Networking Council (a group of U.S. Government agencies involved in networking) asked the National Science Foundation (NSF) to assume responsibility for non-military Internet registration.

Since the 1980s, the registration of domain names was performed by the DDN-NIC under contract by the Department of Defense. This was because most registrants at the time were military users and awardees. By the early 1990s, due to the rapid growth of the NSFNET, academic institutions comprised the majority of new registrations, and the military was no longer willing to fund the registration for these names. The U.S. Federal Networking Council (a group of U.S. Government agencies involved in networking) asked the National Science Foundation (NSF) to assume responsibility for non-military Internet registration.

In 1992, after a solicitation process (NSF 9224), the NSF awarded three five-year cooperative agreements, to American Telephone and Telegraph Company (AT&T), General Atomics (GA), and Network Solutions, Inc. (NSI). The contracted parties were to provide directory and database services, information services and non-military registration services, respectively. These companies adopted the name InterNIC for their joint role.  

In 1992, after a solicitation process (NSF 9224), the NSF awarded three five-year cooperative agreements, to American Telephone and Telegraph Company (AT&T), General Atomics (GA), and [[Network Solutions]], Inc. (NSI). The contracted parties were to provide directory and database services, information services and non-military registration services, respectively. These companies adopted the name InterNIC for their joint role.  

Around the time Network Solutions won the bid to manage the domain registration service, it asked Jon Postel (IANA) about adding NS.INTERNET.NET as a root name server. Postel agreed and IANA added NS.INTERNET.NET as a root server in April 1993.

Around the time Network Solutions won the bid to manage the domain registration service, it asked Jon Postel (IANA) about adding NS.INTERNET.NET as a root name server. Postel agreed and [[IANA]] added NS.INTERNET.NET as a root server in April 1993.

In May 1994, KAVA.NISC.SRI.COM at SRI International was retired due to lack of funding, and NS1.ISI.EDU was added as a root server to replace it.  

In May 1994, KAVA.NISC.SRI.COM at SRI International was retired due to a lack of funding, and NS1.ISI.EDU was added as a root server to replace it.  

In 1994, Paul Vixie and Rick Adams asked Jon Postel (IANA) on behalf of the Internet Software Consortium (ISC) to add a root server at ISC. Postel agreed, and in September 1994, IANA added NS.ISC.ORG as a root server. ISC was the organisation coordinating the ongoing development and distribution of the most-used name server software, BIND, after taking over responsibility for BIND from Digital Equipment Corporation.  

In 1994, [[Paul Vixie]] and [[Rick Adams]] asked Jon Postel (IANA) on behalf of the Internet Software Consortium (ISC) to add a root server at ISC. Postel agreed, and in September 1994, IANA added NS.ISC.ORG as a root server. ISC was the organisation coordinating the ongoing development and distribution of the most-used name server software, BIND, after taking over responsibility for BIND from Digital Equipment Corporation.  

In October 1994, C.NYSER.NET changed to C.PSI.NET, as part of the commercialisation of the Internet service provider (ISP).

In October 1994, C.NYSER.NET changed to C.PSI.NET, as part of the commercialisation of the Internet service provider (ISP).

</div>

</div>

==1.7 1997 – Adding J, K, L and M ==

==1.7 1997 – Adding J, K, L and M ==

<div style="text-align: justify;">

<div style="text-align: justify;">

Until 1996, there was only 9 Root Servers and with the migration to root-servers.net, operators were able to take advantage of DNS label compression,<ref>[Domain name compression was introduced in RFC1035 as an optional protocol feature and later mandated by RFC1123. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name in the same message, thus eliminating the repetition of domain names in a message and reducing the size of the message. In the case of responses to root server priming queries , the domain root-servers.net appears only once in the response, instead of 13 times (once for each root server).]</ref>  leaving room for four additional root servers to fit within a 512 byte DNS response (will cover the 512 byte logic in detail in subsequent article).<ref>[The limitation is specified in RFC 1035 because at the time there were networks that could not handle DNS packets larger than 512 bytes without fragmenting. Also, known firewall rules dropped DNS packets more than 512 bytes in size]</ref>

Until 1996, there were only 9 Root Servers and with the migration to root-servers.net, operators were able to take advantage of DNS label compression,<ref>[Domain name compression was introduced in RFC1035 as an optional protocol feature and later mandated by RFC1123. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name in the same message, thus eliminating the repetition of domain names in a message and reducing the size of the message. In the case of responses to root server priming queries, the domain root-servers.net appears only once in the response, instead of 13 times (once for each root server).]</ref>  leaving room for four additional root servers to fit within a 512-byte DNS response (will cover the 512-byte logic in detail in a subsequent article).<ref>[The limitation is specified in RFC 1035 because at the time there were networks that could not handle DNS packets larger than 512 bytes without fragmenting. Also, known firewall rules dropped DNS packets more than 512 bytes in size]</ref>

In January 1997, servers J-Root, K-Root, L-Root and M-Root, were added, serving the root zone exclusively. Postel (IANA) asked Network Solutions Inc. to set up two additional servers with the intention of moving them to suitable operators quickly thereafter. He kept two more servers at USC-ISI with the same intention. J-Root and K-Root were set up at Network Solutions on the U.S. East Coast, while L-Root and M-Root were at USC ISI on the U.S. West Coast.  

In January 1997, servers J-Root, K-Root, L-Root and M-Root, were added, serving the root zone exclusively. Postel (IANA) asked Network Solutions Inc. to set up two additional servers with the intention of moving them to suitable operators quickly thereafter. He kept two more servers at USC-ISI with the same intention. J-Root and K-Root were set up at Network Solutions on the U.S. East Coast, while L-Root and M-Root were at USC ISI on the U.S. West Coast.  

* Need: The need for root server service. At the time, Europe had one operator. As the Internet developed in Europe, another root server would be useful. There were also no root servers in Asia, so a root server was needed there. The primary tool that Postel used to determine the need was Larry Landweber’s International Connectivity Map.

* Need: The need for root server service. At the time, Europe had one operator. As the Internet developed in Europe, another root server would be useful. There were also no root servers in Asia, so a root server was needed there. The primary tool that Postel used to determine the need was Larry Landweber’s International Connectivity Map.

* Connectivity: The potential operator must have good connectivity both to the internal infrastructure (internal connectivity), and to the world (external connectivity).  

* Connectivity: The potential operator must have good connectivity both to the internal infrastructure (internal connectivity) and to the world (external connectivity).  

* Community consensus: The potential operator should demonstrate the widest possible support from the community being served.

* Community consensus: The potential operator should demonstrate the widest possible support from the community being served.

* Commitment to send and respond to traffic without filtering. The operator must be able to answer every DNS query and send responses back unfiltered.

* Commitment to send and respond to traffic without filtering. The operator must be able to answer every DNS query and send responses back unfiltered.

For the European region, a number of parties expressed their willingness to operate a second root name server. Jon Postel (IANA) encouraged all parties to seek consensus about the matter. After thorough discussion, there was consensus that the Réseaux IP Européens Network Coordination Centre (RIPE NCC) was the appropriate organization to operate the server because of its neutrality and technical expertise. In particular, the RIPE NCC was deemed able to change the server’s deployment following changes in Internet topology<ref>[At the time, all deployments were unicast. The RIPE DNS working group suggested deploying near or at one of the existing open exchange points. Consequently, the first deployment was at the LINX in London. The LINX contributed hosting and local hands, while the RIPE NCC provided the hardware and covered operations. This choice re-emphasized the independence of the location of the operator and the server itself. This was followed shortly thereafter by deployment of a hot standby at the AMS-IX.]</ref>.

For the European region, a number of parties expressed their willingness to operate a second root name server. Jon Postel (IANA) encouraged all parties to seek consensus about the matter. After thorough discussion, there was consensus that the Réseaux IP Européens Network Coordination Centre (RIPE NCC) was the appropriate organization to operate the server because of its neutrality and technical expertise. In particular, the RIPE NCC was deemed able to change the server’s deployment following changes in Internet topology<ref>[At the time, all deployments were unicast. The RIPE DNS working group suggested deploying near or at one of the existing open exchange points. Consequently, the first deployment was at the LINX in London. The LINX contributed hosting and local hands, while the RIPE NCC provided the hardware and covered operations. This choice re-emphasized the independence of the location of the operator and the server itself. This was followed shortly thereafter by the deployment of a hot standby at the AMS-IX.]</ref>.

In the Asia Pacific Region, the Widely Integrated Distributed Environment (WIDE) organization was chosen.  

In the Asia Pacific Region, the Widely Integrated Distributed Environment (WIDE) organization was chosen.  

These selections provided additional organizational diversity in the operation of root servers. Operators now included educational institutions, governments, commercial companies and not-for-profit service organizations.  

These selections provided additional organizational diversity in the operation of root servers. Operators now included educational institutions, governments, commercial companies and not-for-profit service organizations.  

In May 1997, K-Root (K.ROOT-SERVERS.NET) moved to London LINX, managed by RIPE NCC. In August 1997, M-Root (M.ROOT-SERVERS.NET) moved to Japan, managed by WIDE.

In May 1997, [[K-Root]] (K.ROOT-SERVERS.NET) moved to London LINX, managed by [[RIPE NCC]]. In August 1997, [[M-Root]] (M.ROOT-SERVERS.NET) moved to Japan, managed by [[WIDE]].

</div>

</div>

==1.8 Root Servers after Postel’s Death==

==1.8 Root Servers after Postel’s Death==

<div style="text-align: justify;">

<div style="text-align: justify;">

With K-Root and M-Root assigned, there remained two additional root servers to be assigned. Unfortunately, Jon Postel died on 16 October 1998, and there was no one to drive the process of assigning these additional root servers. J-Root stayed with NSI, and remained with Verisign after it acquired NSI in 2000.

With K-Root and M-Root assigned, there remained two additional root servers to be assigned. Unfortunately, Jon Postel died on 16 October 1998, and there was no one to drive the process of assigning these additional root servers. [[J-Root]] stayed with NSI and remained with [[Verisign]] after it acquired NSI in 2000.

   

   

Before Postel’s death, it was planned that USC would transfer certain responsibilities, assets, and personnel to ICANN<ref>[Founded in 1998, Internet Corporation for Assigned Names and Numbers (ICANN) is a private not-for-profit public benefit corporation. It has performed the IANA functions on behalf of the global Internet community since the organization’s creation in 1998. ]</ref>.  In 1999, this transfer occurred, which included L-Root.  

Before Postel’s death, it was planned that USC would transfer certain responsibilities, assets, and personnel to [[ICANN]]. Founded in 1998, Internet Corporation for Assigned Names and Numbers (ICANN) is a private not-for-profit public benefit corporation. It has performed the IANA functions on behalf of the global Internet community since the organization’s creation in 1998. In 1999, this transfer occurred, which included [[L-Root]].  

</div>

</div>

|+  

|+  

|-

|-

! Hostname !! IP Addresses !! Operator

! Hostname !! IP Addresses !! [[Root Server Operator]]

|-

|-

|A.ROOT-SERVERS.NET || 198.41.0.4, 2001:503:ba3e::2:30 || Verisign, Inc.

|A.ROOT-SERVERS.NET || 198.41.0.4, 2001:503:ba3e::2:30 || Verisign, Inc.