DNS History Timeline

  • 1969-09-25 The telnet access to a serving host connects using an official site name, such as SRI, UCLA, UCSB, or UTAH. RFC 15
  • 1973-02-07 The Stanford Research Institute's Augmentation Research Center (SRI-ARC) is considering to offer a Network Information Center to implement and maintain identification files for all network users and sites and make these files available via the network. RFC 453
  • 1973-03-08 The SRI NIC will provide standard addresses of mail recipients. RFC 469
  • 1973-06-13 FTP MAIL proposes that a mail user may be a combination of a host name and mailbox name. RFC 524
  • 1973-09-05 The recommended network FTP MAIL author includes a hostname. RFC 561
  • 1973-12 "... absurd situation where each site on the network must maintain a different, generally out-of-date, host list ..." It is suggested that the NIC maintain a structured online file, accessible to anyone, which lists names, host addresses, and capabilities. RFC 606
  • 1974-01 The SRI NIC will maintain an online ASCII text file of hostnames, addresses, and attributes, known as HOSTS.TXT, which anyone may retrieve via FTP. RFC 608
  • 1977-05-12 The use of numbers for a network address is strongly discouraged for host names for the proposed official standard for the format of ARPA Network messages for FTP MAIL. RFC 724
  • 1979-05 SRI NIC developed a provisional Name Server with information from the NIC's Arpanet host address database. RFC 756
  • 1982-01-11 Computer Mail Meeting at USC Information Sciences Institute decides to replace simple hostname field with a composite domain-name field. RFC 805
  • 1982-03-01 SRI NIC runs server to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains. RFC 811
  • 1982-05-01 Cutover to a new format for HOSTS.TXT table maintained by SRI NIC. RFC 810
  • 1982-08 Zaw-Sing Su and Jon Postel of ISI propose an Internet naming convention based on the domain concept with registrars as naming authorities, and describe iterative and recursive name servers. The initial top-level domain is "ARPA." RFC 819
  • 1982-10 Proposal for distributed System for Internet Name Service (SINS) where each domain is resolved using an application interface process (AIP) for each, starting with the right-most name. RFC 830
  • 1983-02-22 325 names were in the NIC hostname table, e.g., ada-vax and wpafb-afwal. RFC 846
  • 1983-11 Schedule proposed that the existing HOSTS.TXT table prepend domain names under ARPA domain for each entry in March 1984, domain servers for ARPA available in April 1984, top-level domains list pointing to their servers in May 1984, and HOSTS.TXT deprecated for ARPA in September 1984. RFC 881
  • 1984 The SRI-NIC runs a centralized name server answering queries for all hosts from all systems. (Zhou, S., The Design and Implementation of the Berkeley Internet Name Domain (BIND) Servers. UCB/CSD 84/177)
  • 1984 Graduate students at University of California at Berkeley design and implement the Berkeley Internet Name Domain (BIND) servers and database on 4.2BSD Unix for distributed name service. This was developed in parallel with USC-ISI's different system running on a TOPS-20.
  • 1984-10 A limited set of top level domains is introduced: GOV, EDU, COM, MIL, ORG; and two-letter country code top-level domains are proposed (based on ISO-3166). RFC 920
  • 1985 Digital Equipment funded further development and maintenance of BIND, further integrating the nameserver into a real working environment.
  • 1985 The name server lookup program nslookup was released to the Unix community.
  • 1989 Security researcher Steven M. Bellovin's ``Security Problems in the TCP/IP Protocol Suite'' paper published in 1989 clearly identified a sequence number attack.
  • 1993 Christoph Schuba's 1993 ``Addressing Weaknesses in the Domain Name System Protocol'' thesis outlined problems with predictable IDs, spoofing referrals, cache poisoning, and documented a mechanism to use signatures and public keys stored in DNS.
  • 1994-02 The first DNS Protocol Security Extensions IETF draft specification proposed using digital signatures and authentication keys added as resource records to assure data integrity or authentication.
  • 1994-03 The IETF working group for DNSSEC started with a goal of specifying digital signature enhancements to the DNS protocol to protect against unauthorized modification of data (i.e. add data integrity) and protect against faking the DNS origin.
  • 1997-01 The Internet standards track protocol for Domain Name System Security Extensions (RFC 2065) was published.
  • 1997-04 Secure Networks Inc. and CORE Seguridad de la Informacion published a security advisory that showed how ``[t]he usage of predictable IDs in queries and recursed queries allows for remote cache corruption.''
  • 1999-03 RFC 2065 was made obsolete by a new Internet standard for Domain Name System Security Extensions, RFC 2535.
  • 2005-03 New Internet standards for DNS Security Extensions (DNSSEC). RFC 4033, 4034, 4035
(This is a work in progress. This is parsed out of some comment tags in a book in progress about the history of DNS.)