The DNS Handbook

Chapter 1 –History of Domain Name System (DNS)

A domain name system, also known as domain name server (DNS), is a framework of connected domain names. A domain name, in this case, is a form of identification of computers that are logged on to the Internet.

These domain names are usually represented by two terms: the readable hostnames which are typically identified as web addresses, and its corresponding IP address which is represented by a set of numbers. This is to say that domain names serve their identification function through different levels thereby demonstrating the hierarchy of name spaces. For example, a .com or a .net functions as a top level domain name, as followed by a second-level domain name such as yahoo or google. The second level domain name, and the other preceding sublevel domain names, further specifies IP addresses which eventually translates to the location of a particular web page after initially identifying the path towards a particular recipient.
The history of DNS initially started with the conception of the main principle behind the Internet. In the 1970s, the idea of a networked communications through the email platform would lead to the formulation of the DNS. This was necessary given through growing netwrok of email communications as files were initially saved under “HOSTS.TXT” which would map both the host names and their respective network addresses.

Discussing the beginnings of DNS requires an understanding on the inception of the Internet. The idea behind the Internet started with the creation of a communication network that initialy functioned like emails. Such beginnings were found when computers were “networked” to other remote computers as a means to create a communication route. These initiatives took place in the United States when a computer located in Massachusettes was connected to a computer in California by means of a telephone line. From this possibility, the United States’ Department of Defense took an interest in the project, therefore formalizing the project through the Defense Advanced Research Projects Agency (DARPA). Fro the simple concept of connecting computers by means of a network, a more expanded version was created through the ARPANET which at that time had the speed of about 50,000 bits per second. This was the file rate at that period.
As previously mentioned, such files were maintained under the host file “HOSTS.TXT” which was maintained by the ARPANET. The ARPANET was the packet switching network that was essential to the creation of the Internet. As a network that hosted other computers during the inception in the late 1960s to the early 1970s, the ARPANET’s evoluton would require the creation of a hierarchy which would host different domains that represent other computers or growing subnetworks. However, the idea of utilizing a hierarchy was not necessary at that time given the small number of electronic communication at that time as the network was restricted when it comes to usage. Hence, a “flat space”, which would serve as the platform of electronic exchange, was enough in the beginning. However, it was not until the technology and demand for the function increased that the system was already experiencing problems.
The initial solution for such growing challenge was found in maintaining multiple copies of the host file. However, this would evetually lead to problems in terms of capacity as these multiple copies would turn out to be error-prone and inefficient.

Another important note was the development of TCP/IP which would somehow serve as a solution to the growing number of networks made up of ARPANET computers. In a way, the TCP/IP enabled the creation of internetworking, thereby the possibility of having more computers able to communicate with each other was feasible. However, what also came with this opportunity was the challenge in the area of addressing.

Hence, centralization would then become a potential solution to efficiency problems. A series of proposals were formulated starting with the RFC 606 or Host Names On-line which was presented in December 1973; this would then be followed by RFC 608 and further modified through Comments on On-Line Host Service or RFC 623. The round of discussions would be settled by March 1974 when the series of proposals would lead to the On-Line Hostnames Service, the RFC 625 which would finalize the official source of master hosts file in the Stanford Research Institute. The Network Information Center in the SRI (SRI-NIC) compiled changes to the file once or twice a week and submitted them to “HOSTS.TXT”.

This centralization would become effective at this point. With the presence of a master host, the systemic flat name space would find room as communications and access would become more dynamic. However, for about a decade since the utilization of the centralized system, the dynamics and the necessity of creating unique domain names would again challenge the capacity of the SRI-NIC. The number of hosts increased, thereby further escalating network traffic; this would create problems as the processor load on SRI-NIC became uncontrollable.
The problem with this set-up is that the centralized system merely created a host that could only replenish updates on the files through the system. The lack of “authority” when it comes to the organization of the hosts could lead to problems in the case additional host names would conflict with the pre-existing ones. When this happens, the tendency is that accessing conflicting names could potentially break the entire system. This system also does not have enough capacity to maintain consistency among the files throughout the network. Basically, the system architecture would make copies of the additional hosts and/or changes to the hosts prior to the file reaching the ARPANET, but the flat name space could only handle as much.
To respond to this problem, a new design of the system was needed. Although the centralized system at the SRI-NIC was initially effective, it could not respond to the evolving size and speed needed for the growing network. The improvements necessary required a more organized platform which would handle a potentially exponentially developing network that a flat space could not handle. This is where the domain name system (DNS) came system.

The footprint of the initial design of the DNS was made by Paul Mockapetris of the USC's Information Science Institute as based on John Postel’s assignment of blocks of IP network addresses. Mockapetris came up with an architecture that utilized hierarchical name space. This would allow the system to update data without creating a breakdown since there are assigned zones of authority.

The more organized structure of the DNS addresses the disadvantages experienced by the precursor to the domain name. The need to relay more emails, the increasing bandwidth requirements for downloads and the creation of new paths required a mrore effective system that would define a systematized communication path that would supplement the capacity of the software,

The development of the DNS also required the development of domain names. The concept of domains in network communications aimed to simplify both the identification system of the network and at the same time, address the complexity of relaying an increasing capacity of communications. Through the basic email system, the application of developed domain names with respect to a designed DNS, the email is able to be sent by using a specific address for every recipient within an identified set or domain. Hence, this explains that, for example, the address recepient@email is a representation of the idea as to how domains work.

From the discussions that started in 1982 starting with the RFC 805 (Computer Mail Meeting Notes), the basic principles of the DNS were outlined. The following points were brought up as follows:

• The necessity of top level domain names that serve as the starting point of the delegation of queries
• The necessity of second level domain names to further define the uniqueness of the recipient information or address
• The utilization of a registration system for the purpose of more efficient administration
• The utilization of individual name servers that can furter enhance administration and maintenance

From these principles, the design of the hardware and the software would eventually take place. Within a year from the release of the RFC 805, the NIC would conduct development through more communications and discussions as to how to structurally evolve the pre-existing network system. By March, the DoD Internet Host Table Specification (RFC 810) was updated, as followed by the introduction of a server function by the NIC which was used to provide specific host nae and address translations. The Hostnames Server, RFC 811, served as a translation reference and at the same time, as a document for the domain concept. By August, the RFC 819 (The Domain Convention for Internet User Applications) further enhanced the concept, and the document RFC 830 the main architectural outlines of the system were decribed. The RFC 830 also expounded on the full concept of how the distributed system of name server works and how these functioned with respect to a specific local domain. At this point, this is the system that is being used today.
From these series of developments, the convention on DNS was established. These conventions were documented in The Domains Names Plan and Schedule (RFC 881); Domain Names: Concepts and Facilities (RFC 882); and Domain Names: Implementation and Specification (RFC 883).

Currently, the maintenance of the DNS, under the supervision of the Internet’s infrastructure and domain name and IP identifiers, was vested to the Internet Corporation for Assigned Names and Numbers (ICANN) which was only created in the late 1990s.

Bibliography
‘DNS: History’. 2000. PSI Net. [Online] Available at:
http://www.support.psi.com/support/common/inet-serv/dns/history.html
‘Domain Name System (DNS) History’. 2008. Living Internet. [Online] Available at:
http://www.livinginternet.com/i/iw_dns_history.htm
Weinberg , J. 2000. ‘ICANN and the Problem of Legitimacy’. Duke Law Journal,
vol. 5, no. 1, pp. 187 +

back to index

Chapter 2 - How DNS works

One of the important things to be reminded of when it comes to DNS was the necessity of its property as an open source; this is to say that the DNS has to be fault free and can be trusted by the Internet community.

Another important function of the DNS is its ability to provide a convenient solution to addressing. Given that the number of network users are increasing, the DNS is able to come up with an easier means of identification instead of using the IP addres of the computer. IP addressses are usually made up of a unique 32-bit number in dotted decimal form which was translated by the “HOSTS.TXT” table. The DNS therefore prevented the table from going through an overcapacity by effective functioning.

How the DNS works is significantly due to its essence as a hierarchical name space; hence, there is the top-level domains (TLDs), the second level domains, and so on. When the Internet was at the period of early developments, the identified TLDs depended on the name of the organization such as .arpa, .csnet, .bitnet and .uucp which were the four main organization-networks that were internetworked. Eventually, in 1986, these four groups, along with Postel and Mockapetris, initially came up with 7 TLDs: .com, .net, .org, .edu, gov, .mil and .int. These TLDs are assigned according to the function of a certain group or organization; the next chapters will explain further on these TLDs.

After the identification of a top level domain name, the second level domain name further identifies the uniqueness of an address. These second level domain name are therefore unique. For example, a number of organizations may share a .com, but only one of them will own a specific name following the .com; for example, there is only one yahoo.com and google.com. At this point, there is already a specfication of a domain although further specifying a domain is necessary as a user further navigates this specific domain. Hence, there is also the third level domain which specifies a series of other areas. At this point, it is possible that a domain already stops at third level since the created pyramid of hierarcy already allows the creation of unique paths without replicating another. The third level domain can therefore identify functions, geographical or other organization of any portion of the name space.

With this pyramid, the apex of the DNS already established thirteen root servers with each of these servers listing the IP addresses of the computers that contain the zone files fr each of the top level domain names. The hierarchy therefore makes it possible for the processing of the name-to-number distribution since there is no single central server that serves as a reference point of translation unlike the former centralized and “HOSTS.TXT” system. What happens is that through the DNS, when a user enters a query into the computer, the user “starts” at the bottom of the pyramid where a series of identification, through the entered domain name, becomes a means to create a direct path that goes through the computer of a specific domain. Hence, for example, if a user looks for the email page of the website of yahoo.com, the entered domain name identifies the .com as a commercial address (top level), and the proceeding relay of information takes place within yahoo.com instead of going through a centralized server. As a result, the hierarchy is able to identify the corresponding IP address that is specific within a certain domain.

Domain Name Space Workflow
(image from ‘Domain Name Space’, Wikipedia)
BIBLIOGRAPHY
‘Domain Name System (DNS) History’. 2008. Living Internet. [Online] Available at:
http://www.livinginternet.com/i/iw_dns_history.htm
Weinberg , J. 2000. ‘ICANN and the Problem of Legitimacy’. Duke Law Journal,
vol. 5, no. 1, pp. 187 +

Chapter 3 - How dynamic DNS works

One of the important factors about the DNS is that it may be required to be dynamic especially when a particular domain is assigned to a computer with a changing IP address. In order for the DNS to have the capacity to be updated in real time, a system was created in order to address these required changes. The dynamic DNS therefore allows the domain name data to go through these modifications in real time.

How the dynamic DNS works is based on how DNS works although the dynamic systems integrated to the whole function allows more flexibility in its features. The importance of this function is that this gives the possibility for other sites to be able to establish a connection without necessarily to continuously track the IP addresses by this specific server. This is deemed helpful for sites that are also dynamic such as the consumer-focused Internet service providers. As an integral part of the Active Directory, the dynamic DNS needs to establish its maximum caching time by a few minutes in order to avoid any incidences of retaining old addresses in the different in the sites’ respective DNS cache. This also helps in the speed of contact between the servers.

When it comes to implementing Dynamic DNS in server operators, it can be initially done by miximizing the caching time or the intervals between the caching of the domains by a shorter period; in this case, the caching can be set to about one or two minutes.

Implementing dynamic DNS is also made possible through DNS hosting services where their serves retain current addresses in their database and provide client program that sends updates when changes in the IP addresses take place. Specific features in dynamic DNS hosting also depends on the service provider and the firmware that is used. For example, routers are designed to support specific dynamic DNS features such as the UMAX Ugate-3000, the first router that was able to support dnynamic DNS.

Another important note on the dynamic DNS is described by RFC 2136 as a protocol through the nsupdate utility. Although the dynamic DNS can be considered as an important feature for particular sites, an updating DNS can be also considered dangerous for security and stability reason. This is to say that it is important to utilize a feature that can authenticate dynamic DNS updates such as TSIG and using the HMAC-MD5 hash key.

Alternatives have been also designed such as Microsoft’s GSS-TSIG that usees Kerberos for authentication; this also automates the installation of hash keys. Hence, the GSS-TSIG has become a proposed standard and operating systems that run on Microsoft Windows 2000, Widows XP and Windows 2003 only uses this authenticated dynamic DNS support system. Hence, dynamic DNS has actually created a niche in different markets, especially when it comes to its potentia in the server ector. The dynamic DNS has also evolved with the continuous developments on Internet technologies, especially when it comes to better speeds and the available computer technology; this therefore gave an opportunity to the home server markets which has taken advantage of offering services for dynamic DNS functions. Hence, it is possible for small websites to become a host a dynamic IP address by merely installing relevat server setups which can still function despite its amateur level.

BIBLIOGRAPHY:
‘Dynamic DNS’. 2008. Wikipedia. [Online] Available at:
http://en.wikipedia.org/wiki/Dynamic_DNS
‘What is Dynamic DNS?’. N.d. The Tech-FAQ. [Online] Avaiable at:
http://www.tech-faq.com/dynamic-dns.shtml

Chapter 4 - Types of DNS records

The DNS, in addition to providing a hierarchical identification system of domain names, also establishes certain parameters. These parameters are identified by means of zones which can be multiple or secondary. The DNS record types are mainly classified according to the binary or wire format which is utilized for queries and responses that direct them to specific zone files.
There are a number of DNS record types. The following generally describes some valid kinds of DNS records:

• SOA (Start of Authority) record is made of significant DNS information such as the serial number. The serial number is a form of identification as monitored by servers when changes take place and also acts as an indicator when change of information for a zone actualizes. The SOA also contains the refresh function which also indicates the number of times a secondary name server must check for a change in the serial number. The retry function, on one hand, informs the secondary server the interval it can use in using the current entry if the system is unable to activate the retry functions. The minimum becomes a reference as to how long the other name servers can hold the information.
• The NS record shows the authoritative DNS per zone.
• The A record directs a hostname to a particular IP address.
• The CNAME (canonical naming) record enables a node to be also used as an address in addition to functioning as a host name.
• The MX record is used for message routing. This is important for multiple mail exchange hosts.
• PTR records maps IP addresses to a hostname. These are useful in addr.arpa zones which are mostly delegated or assigned by the service provider of a particular IP block.

In addition to these records, the more DNS record types are enumerated in the following table:

BIBLIOGRAPHY

‘Domain Name System Parameters’. 2008. Internet Assigned Numbers Authority.
[Online] Available at: http://www.iana.org/assignments/dns-parameters
‘Types of DNS Records’. N.d. Net Dummy. [Online] Available at:
http://www.netdummy.net/dnsrecords.html

back to index

Chapter 5 - Internationalized Domain Names ("umlaut" domains)

Domain names need to be recognized by the system; however, not all characters are able to be recognized through the typically used alphanumeric numbers. In this case, internationalized domain names have made text usage in DNS systems more flexible by means of including additional characters which the DNS can also read and translated. The intention of these domain names is basically to contained non-ASCII characters such as texts that contain diacritics and characters from non-Latin texts such as Arabic and Chinese.

As previously mentioned, these domain names, within the framework of the DNS, functions by means of representing the IP addresses through more recognizable name through text. Since that the text used is not necessarily universal, the tendency is that the initial system is restrictive.

The deployment of the IDN initially started in October 2002 when the Interet Engineering Streering group approved the publication of RFCS 34490, 3491 and 3492 which are the protocols on Internationaliing Domain Names in Application (IDNA). Basically, through the IDNA, the support for non-ASCII IDNs that are found within the DNS would be established. This will then allow the creation of DNS that do not have ASCII characters. By March 2003, the Internet Corporation for Assigned Names and Numbers (ICANN) and a host of IDN-implementing registries developed a set of universal "Guidelines for the Implementation of Internationalized Domain Names” in which its fist version was published in June 2003.

One of the important factors addressed by these guidelines are the potential risks of cybersquatting and duplication of registered domain names which can bring confusion to consumers. In addition to this, the guidelines also made it a point to respect local languages and character sets that may be used in the domain names. Hence, one initiative was the deployment of language-specific registration and adminisration rules which can be accessed by the public. The registries also need to recognize the agreements with ICANN in addition to the fulfillment of requirements according to the guidelines.

Although initives on IDN seem to have only started recently due to the growing global response to the Internet, the idea was actually already conceived as early as 1996 by M. Duerst, with its implementation taking place in 1998 through T.W Tan and his team.

How the IDN works is initially to maximize backward compatibility. However, systems that support IDNA are only the ones that have the ability to read such domains although they can access non-ASCII sites. When an application is IDNA enabled, the system is able to convert from ASCII to non-ASCII and vice-versa, with the ASCII format utilized for DNS lookup. However, users are also able to read non-ASCII forms.

Conversions between languages are made possibel through ToASCII and ToUnicode which are both algorithms. In IDNA, each domain name level is applied separately per code. Each label can be also processed separately especially if a specific domain label is a non-ASCII; the processing of the conversion can be handled by different software such as Nameprep and Punycode.

It is also evident there are the advantages and disadavantages of using IDNA. Apparently, the IDN has allowed a more universal and flexible means to utilize language that are non-Latin in nature when it comes to the creation of domain names. However, the disadvantage can be found in the potential risks that come with the utilization of IDN application. These risks include cybersquatting and spoofing since that the utilization of full Unicode names can lead to the cretion of spoof sites or sites that replicate other sites. The challenge in this is that even the domain name and the security certificate can be spoofed in this format. What made this possible is not necessarily due to the faulty system offered by Unicode but rather the similarities of texts despite some interface differences; this shows that characters that look alike can be read similarly although the minor differences such as small punctuations and umlauts can be overlooked when reading certain data.

BIBLIOGRAPHY
‘Internationalized Domain Name’. 2007. ICANN. [Online] Available at:
http://www.icann.org/topics/idn.html
‘Internationalized Domain Name’. 2008. Wikipedia. [Online] Available at:
http://en.wikipedia.org/wiki/Internationalized_domain_name#Internationalizing_domain_names_in_applications

Chapter 6 - DNS ROOT servers

The DNS root servers serve as the top of the DNS hierarchy. These root servers generally serve as the ultimate data source when it comes to identifying an address for a particular query, For example, when a user enters a query or an URL, the request is initially sent to the local server, which is then ultimately brought to the root server; the root server then in turn identifies the right address of the query which is then sent back through the path of the local server.

Basically there are only 13 root servers in operatin with the majority of the servers located in the United States and other root servers “distributed” to different geographical locations such as Tokyo and London. Hence, these root servers serve all the queries sent from different parts of the world. Although some may assume that due to the exponential growth of the Internet there ought to be more root servers, what limits this number is due to the limitaiton of the protocol in which the UDP can only allow up to 512 bytes. In order to prevent the overcapacity of root servers and any potential risks, some root servers are geographically “distributed” by using anycast.

The following are 13 root servers and their respective information:

• Root server: A

IPv4 address: 198.41.0.4
Ipv6 address: 2001:503:BA3E::2:30
Old name: ns.internic.net
Operator: VeriSign
Location: Dulles, Virginia, U.S.
Software: BIND

• Root server: B

IPv4 address: 192.228.79.201
Ipv6 address: 2001:478:65::53
Old name: ns1.isi.edu
Operator: USC-ISI
Location: Marina Del Rey, California, U.S.
Software: BIND

• Root server: C

IPv4 address: 192.33.4.12
Ipv6 address:
Old name: c.psi.net
Operator: Cogent Communications
Location: distributed using anycast
Software: BIND

• Root server: D

IPv4 address: 128.8.10.90
Ipv6 address:
Old name: terp.umd.edu
Operator: University of Maryland
Location: College Park, Maryland, U.S,
Software: BIND

• Root server: E

IPv4 address: 192.203.230.10
Ipv6 address:
Old name: ns.nasa.gov
Operator: NASA
Location: Mountain View, California, U.S.
Software: BIND

• Root server: F

IPv4 address: 192.5.5.241
Ipv6 address: 2001:500:2f::f
Old name: ns.isc.org
Operator: ISC
Location: distributed using anycast
Software: BIND

• Root server: G

IPv4 address: 192.112.36.4
Ipv6 address:
Old name: ns.nic.ddn.mil
Operator: Defense Information Systems Agency
Location: Columbus, Ohio, U.S.
Software: BIND

• Root server: H

IPv4 address: 128.63.2.53
Ipv6 address: 2001:500:1::803f:235
Old name: aos.arl.army.mil
Operator: U.S. Army Research Lab
Location: Aberdeen Proving Ground, Maryland, U.S.
Software: NSD

• Root server: I

IPv4 address: 192.36.148.17
Ipv6 address:
Old name: nic.nordu.net
Operator: Autonomica
Location: distributed using anycast
Software: NSD

• Root server: J

IPv4 address: 192.58.128.30
Ipv6 address: 2001:503:C27::2:30
Old name:
Operator: Verisign
Location: distributed using anycast
Software: BIND

• Root server: K

IPv4 address: 193.0.14.129
Ipv6 address: 2001:7fd::1
Old name:
Operator: RIPE NCC
Location: distributed using anycast
Software: NSD

• Root server: L

IPv4 address: 199.7.83.42
Ipv6 address:
Old name:
Operator: ICANN
Location: distributed using anycast
Software: NSD

• Root server: M

IPv4 address: 202.12.27.33
Ipv6 address: 2001:dc3::35
Old name:
Operator: WIDE Project
Location: distributed using anycast
Software: BIND

BIBLIOGRAPHY
Karrenberg, D. 2007. ‘DNS Root Servers: Frequently Asked Questions’. Internet
Society. [Online] Available at: http://www.isoc.org/briefings/020/
‘Root name server’. 2008. Wikipedia. [Online] Available at:
http://en.wikipedia.org/wiki/Root_nameserver

• Chapter 7 - DNS server software

Domain name servers, as systems, are actually actually a combination of hardware and software which basically operates the purpose of DNS: to translate IP data into readable names and establish them as a workable hierarchy. Domain servers can service from the smallers network to wide range of network; examples of huge networks are the root servers and smaller name servers that are set-up at a personal level.

The following are the DNS servers in ranking according to the number of sites it services.

70.105% 24,335,752 BIND
15.571% 5,405,266 TinyDNS
6.237% 2,165,143 Microsoft DNS Server
2.792% 969,097 MyDNS
1.964% 681,614 PowerDNS
1.250% 433,905 Simple DNS Plus
1.138% 395,206 Unknown
0.277% 96,232 Pliant DNS Server
0.203% 70,455 NSD
0.144% 49,921 UltraDNS
0.104% 36,195 Net::DNS::Nameserver
0.083% 28,656 QuickDNS
0.064% 22,087 Incognito DNS Commander
0.025% 8,508 MaraDNS
0.024% 8,174 rbldnsd
0.018% 6,135 Totd
0.001% 386 ATLAS
0.001% 371 Posadis
0.001% 312 NonSequitur DNS
0.000% 12 Nominum ANS/CNS

There are different types fo DNS servers available today. The next sections describe these different types of servers.

BIBLIOGRAPHY

‘BIND 9 Administrator Reference Manual’. 2007. Internet Systems Consortium.
[Online] Available at: http://www.isc.org/index.pl?/sw/bind/index.php
‘BIND Name Server’. N.d. European Center for Parallelism Barcelona. [Online]
Available at: http://www.cepba.upc.es/docs/sgi_doc/SGI_Admin/books/IA_NetwkMail/sgi_html/ch06.html
‘BIND vs, TinyDNS’. 2005. Walkato Linus Users Group. [Online] Available at:
http://www.wlug.org.nz/BindVsTinyDNS
‘DNS Server Survey’. 2004. [Online] Available at: http://mydns.bboy.net/survey/
Erdman, J. n.d. ‘Microsoft DNS Server’. Network Clue. [Online] Available at:
http://www.networkclue.com/internet/DNS/MS-DNS/
‘Name Server Daemon’. N.d. Nine T Labs. [Online] Available at:
http://www.nlnetlabs.nl/nsd/

back to index

• Chapter 7.1 - BIND Server

As an implementation of the DNS, the Berkeley Internet Name Domain is a set of protocosl that provide an accessible and redistibutable reference tool of the main components of the DNS functions. These components are the DNS server, a DNS resolver library and a set of tools for the verifiction of proper opertion of the DNS server. BIND is mainly made up of two parts: the name server program, named, and a set of C library “resolver” routines which creates access paths to the server.

The BIND is a widely used name servers due to its stable and robust design that can serve as an organization’s naming architecture’s foundation. The library also serves as a standard reference point for APIs in the translation between DNs and IPs.

The BIND version that has been currently released is version 9.4.2. BIND operates on operating systems similar to Unix and the derivatives of NT such as Windows 2000 and Windows XP. The requirements of the system is minimal provided that the system is able to handle capacity such as the capacity of the memory in order to handle a certain amount og cache. For BIND, the memory needs to be high in order to function efficiently.

BIND can be also described to be based a client-server relatioship, hence there are varying degrees of authority. BIND therefre has specific configurations for the BIND’s master, slave and cache servers, depending on the set-up and designed function of the server. However, BIND can be also configured whether it is only a caching server or an authoritative-only server.

A main advantage of BIND is that most companiies use this server; because of this, the system is already automated and can be therefore easily integrated with the system. Bind 9 is also deemed flexible especially when it comes to its caching functions. For example the caching services can share IP addtesses and it can also cache SERVFAILs. There are also improvements in the DNS security through DNSSEC and TSIG. This version is also Ipv6 supported and is multi-threaded and multi-proc aware. Enhancements are also presented in its IXFR, DDNS, Notify and ESNS0.

• Chapter 7.2 - Microsoft DNS server

Microsoft DNS servers have actually replaced Micrsoft WINS and can be deemed a vast improvement from its precursor. Basically, Microsoft’s DNS servers have been lauded for its efficiency and features. One important factor that is integrated in this server is the Active Directory Domain which plays an integral part in the server. The Active Directory works together with the Domain Controllers in order to provide correct information to the clients when they check their Active Directory Resources.

The server is also noted for its Graphical Interface. The Microsoft DNS also has a Active Directory Integrated Domain, a Standard Primary Domain and a Standard Secondary Domain. The Active Directory allows to have the domain to be hosted on multiple DNS servers which can be updated automatically through the built-in Active Directory. The rest of the domains create a chain of back-ups and sources of optimization. Although this DNS server is noted to cater to DNS needs, a noted con of the Microsoft DNS server is that when a compuer is a part of a network, such as the Windows 2000 Network, the network requires at least one functioning server otherwise the system stops.

Chapter 7.3 - NSD (Name Server Daemon)

Name server daemon (NSD) is an authoritative-only server ; this already shows a shortcoming for the server due to its lack of flexibility although the NSD is also cited for a series of strengths. First, it is RFC compliant and has some similarities with BIND. It is also noted for its high performance, immunity from DDOS and resistance from bad queries. The NSD also demonstrate the capacity as a true open source software that is simple in architecture and process. Hence, the system does not operate any caching, it is incable of any dynamic updates, no recursions, and no forwarding.

In a way, the simplicity of this structure already poses the limitations and the optimization of the NSD. What can demonstrate the strength of the NSD is that this type of server is already used as a root server. So far, the NSD has been released up to three versions and these versions have been continuously fixed when it comes to its bugs.

back to index

Chapter 7.4 - TinyDNS

TinyDNS is the second most used DNS server after BIND, followed by Microsoft DNS servers. It can be deemed as a workable alternative for BIND since it is also reiable and efficient athough it is smaller.

Its cache is a recursive resolver; it provides data obtained from the authoritative servers. TinyDns, in this case, is only restricted to authoritative nameserving through UDP and does not doe recursive nameserving and does not reply to TCP queries. This server has the capability to accept DNS queries from the Internet and reponds through configured information. It also includes NS records therefore it answers most inputted queries. However, the server has the capacity to draw queries from the parent servrs thereby resulting to reduced DNS delays.

Its main advantage is that it is comparable to the performance of the highly in-demand BIND DNS server although TinyDNS has limitations. These include the fact that its servers does not accept zone-transfer requests, inverse queries, non-Internet-class queries, truncated packets, and packets that contain anything other than a single query. It also does not support DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6.

Chapter 8 - DNS client tools

here you can find the most importend dns tools who are used each day frome millions of internet users worldwide.

Chapter 8.1 - nlsookup

NSLOOKUP is a command that can be used in both Windows and Linux systems. NSLOOKUP can express queries on IP address information. It has a series of subcommands that can help a user finding information on the DNS such as MX records. NSLOOKUP comes bundled with the DNS server although it is also found in the BIND DNS server.

Chapter 8.2 - dig

Dig functions similar to NSLOOKUP. Users can simply input the query according to the information the user needs when it comes to a particular DNS.

Chapter 8.3 - DNS updater

The DNS can be updated especially for dynamic IP addresses. This is useful for dynamic DNS that needs to be consatantly refresged for updates. Basically updaters can be simply downloaded from the Internet and can contribute to the optimization of the performance of the DNS.

Chapter 9 - RFC numbers Leading to the creation of DNS

0001 Host Software. S. Crocker. April 1969. (Format: TXT=21088 bytes)
(Status: UNKNOWN)

0002 Host software. B. Duvall. April 1969. (Format: TXT=17145 bytes)
(Status: UNKNOWN)

0003 Documentation conventions. S.D. Crocker. April 1969. (Format:
TXT=2323 bytes) (Obsoleted by RFC0010) (Status: UNKNOWN)

0008 Functional specifications for the ARPA Network. G. Deloche. May
1969. (Not online) (Status: UNKNOWN)

0009 Host software. G. Deloche. May 1969. (Not online) (Status:
UNKNOWN)

0010 Documentation conventions. S.D. Crocker. July 1969. (Format:
TXT=3348 bytes) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated
by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN)

0011 Implementation of the Host-Host software procedures in GORDO. G.
Deloche. August 1969. (Not online) (Obsoleted by RFC0033) (Status:
UNKNOWN)

0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969.
(Format: TXT=177, PS=1489750, PDF=1163721 bytes) (Status: UNKNOWN)

0019 Two protocol suggestions to reduce congestion at swap bound
nodes. J.E. Kreznar. October 1969. (Format: TXT=3392 bytes) (Status:
UNKNOWN)

0020 ASCII format for network interchange. V.G. Cerf. October 1969.
(Format: TXT=18504 bytes) (Status: UNKNOWN)

0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT=2143
bytes) (Status: UNKNOWN)

0022 Host-host control message formats. V.G. Cerf. October 1969.
(Format: TXT=4606 bytes) (Status: UNKNOWN)

0023 Transmission of Multiple Control Messages. G. Gregg. October
1969. (Format: TXT=690 bytes) (Status: UNKNOWN)

0024 Documentation Conventions. S.D. Crocker. November 1969. (Format:
TXT=3460 bytes) (Obsoletes RFC0016) (Updates RFC0010, RFC0016)
(Updated by RFC0027, RFC0030) (Status: UNKNOWN)

0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format:
TXT=41338 bytes) (Status: UNKNOWN)
0061 Note on Interprocess Communication in a Resource Sharing Computer
Network. D.C. Walden. July 1970. (Format: TXT=43946 bytes) (Obsoleted
by RFC0062) (Status: UNKNOWN)

0062 Systems for Interprocess Communication in a Resource Sharing
Computer Network. D.C. Walden. August 1970. (Format: TXT=55784 bytes)
(Obsoletes RFC0061) (Status: UNKNOWN)

0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format:
TXT=2961 bytes) (Status: UNKNOWN)

0083 Language-machine for data reconfiguration. R.H. Anderson, E.
Harslem, J.F. Heafner. December 1970. (Format: TXT=22253 bytes)
(Status: UNKNOWN)

0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format:
TXT=12613 bytes) (Status: UNKNOWN)

0085 Network Working Group meeting. S.D. Crocker. December 1970.
(Format: TXT=1547 bytes) (Status: UNKNOWN)

0086 Proposal for a Network Standard Format for a Data Stream to
Control Graphics Display. S.D. Crocker. January 1971. (Format:
TXT=7117 bytes) (Updated by RFC0125) (Status: UNKNOWN)

0163 Data transfer protocols. V.G. Cerf. May 1971. (Format: TXT=5465
bytes) (Status: UNKNOWN)

0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71.
J.F. Heafner. May 1971. (Format: TXT=58597 bytes) (Status: UNKNOWN)

0165 Proffered official Initial Connection Protocol. J. Postel. May
1971. (Not online) (Obsoletes RFC0145, RFC0143, RFC0123) (Updated by
NIC 7101) (Status: UNKNOWN)

0166 Data Reconfiguration Service: An implementation specification.
R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M.
Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. May 1971. (Format:
TXT=42094 bytes) (Status: UNKNOWN)

0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe,
J.M. Winett. May 1971. (Format: TXT=7643 bytes) (Also RFC0147,
RFC0129) (Status: UNKNOWN)

0168 ARPA Network mailing lists. J.B. North. May 1971. (Format:
TXT=13294 bytes) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status:
UNKNOWN)

0169 Computer networks. S.D. Crocker. May 1971. (Not online) (Status:
UNKNOWN)

0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,
E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D.
Watson, J. White. June 1971. (Format: TXT=20616 bytes) (Obsoleted by
RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN)

0172 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,
E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D.
Watson, J. White. June 1971. (Format: TXT=21328 bytes) (Obsoleted by
RFC0265) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN)

0173 Network Data Management Committee Meeting Announcement. P.M.
Karp, D.B. McKay. June 1971. (Format: TXT=4239 bytes) (Status:
UNKNOWN)

0176 Comments on "Byte size for connections". A.K. Bhushan, R.
Kanodia, R.M. Metcalfe, J. Postel. June 1971. (Format: TXT=7269
bytes) (Status: UNKNOWN)

0179 Link Number Assignments. A.M. McKenzie. June 1971. (Format:
TXT=1221 bytes) (Updates RFC0107) (Status: UNKNOWN)

0196 Mail Box Protocol. R.W. Watson. July 1971. (Format: TXT=7016
bytes) (Obsoleted by RFC0221) (Status: UNKNOWN)

0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem.
July 1971. (Format: TXT=7094 bytes) (Status: UNKNOWN)

0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. July
1971. (Format: TXT=855 bytes) (Obsoletes RFC0193) (Obsoleted by
RFC0214) (Updates RFC0193) (Status: UNKNOWN)

0199 Suggestions for a network data-tablet graphics protocol. T.
Williams. July 1971. (Not online) (Status: UNKNOWN)

]]
0203 Achieving reliable communication. R.B. Kalin. August 1971.
(Format: TXT=9253 bytes) (Status: UNKNOWN)

0206 User Telnet - description of an initial implementation. J.E.
White. August 1971. (Not online) (Status: UNKNOWN)

0209 Host/IMP interface documentation. B. Cosell. August 1971.
(Format: TXT=2566 bytes) (Status: UNKNOWN)

0210 Improvement of Flow Control. W. Conrad. August 1971. (Format:
TXT=3329 bytes) (Status: UNKNOWN)

0211 ARPA Network mailing lists. J.B. North. August 1971. (Not online)
(Obsoletes RFC0168) (Obsoleted by RFC0300) (Status: UNKNOWN)

0212 NWG meeting on network usage. Information Sciences Institute
University of Southern California. August 1971. (Format: TXT=4356
bytes) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN)

0214 Network checkpoint. E. Harslem. August 1971. (Format: TXT=3047
bytes) (Obsoletes RFC0198) (Status: UNKNOWN)

0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M.
McKenzie. August 1971. (Format: TXT=16645 bytes) (Status: UNKNOWN)

0216 Telnet access to UCSB's On-Line System. J.E. White. September
1971. (Not online) (Status: UNKNOWN)

0229 Standard host names. J. Postel. September 1971. (Format: TXT=3388
bytes) (Obsoleted by RFC0236) (Status: UNKNOWN)

0230 Toward reliable operation of minicomputer-based terminals on a
TIP. T. Pyke. September 1971. (Format: TXT=7040 bytes) (Status:
UNKNOWN)

0231 Service center standards for remote usage: A user's view. J.F.
Heafner, E. Harslem. September 1971. (Format: TXT=9692 bytes)
(Status: UNKNOWN)

0233 Standardization of host call letters. A. Bhushan, R. Metcalfe.
September 1971. (Format: TXT=3206 bytes) (Status: UNKNOWN)

0236 Standard host names. J. Postel. September 1971. (Format: TXT=5112
bytes) (Obsoletes RFC0229) (Status: UNKNOWN)

0237 NIC view of standard host names. R.W. Watson. October 1971.
(Format: TXT=2212 bytes) (Obsoleted by RFC0273) (Status: UNKNOWN)

0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971.
(Format: TXT=2735 bytes) (Updates RFC0171, RFC0172) (Status: UNKNOWN)

0239 Host mnemonics proposed in RFC 226 (NIC 7625). R.T. Braden.
September 1971. (Format: TXT=2236 bytes) (Also RFC0226, RFC0229,
RFC0236) (Status: UNKNOWN)

0240 Site Status. A.M. McKenzie. September 1971. (Format: TXT=7948
bytes) (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN)

0241 Connecting computers to MLC ports. A.M. McKenzie. September 1971.
(Format: TXT=3739 bytes) (Status: UNKNOWN)

0242 Data Descriptive Language for Shared Data. L. Haibt, A.P.
Mullery. July 1971. (Format: TXT=18151 bytes) (Status: UNKNOWN)

0243 Network and data sharing bibliography. A.P. Mullery. October
1971. (Format: TXT=12432 bytes) (Obsoleted by RFC0290) (Status:
UNKNOWN)

0263 "Very Distant" Host interface. A.M. McKenzie. December 1971.
(Format: TXT=3914 bytes) (Status: UNKNOWN)

0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,
E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J.
White. January 1972. (Format: TXT=20907 bytes) (Obsoletes RFC0171)
(Obsoleted by RFC0354) (Updated by RFC0310) (Also RFC0265) (Status:
UNKNOWN)

0265 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,
E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D.
Watson, J. White. November 1971. (Format: TXT=3914 bytes) (Obsoletes
RFC0172) (Obsoleted by RFC0354) (Updated by RFC0281, RFC0294,
RFC0310) (Also RFC0264) (Status: UNKNOWN)

0266 Network host status. E. Westheimer. November 1971. (Format:
TXT=3174 bytes) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status:
UNKNOWN)

0267 Network Host Status. E. Westheimer. November 1971. (Format:
TXT=7862 bytes) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status:
UNKNOWN)
0289 What we hope is an official list of host names. R.W. Watson.
December 1971. (Format: TXT=5069 bytes) (Obsoleted by RFC0384)
(Status: UNKNOWN)

0392 Measurement of host costs for transmitting network data. G.
Hicks, B.D. Wessler. September 1972. (Format: TXT=14462 bytes)
(Status: UNKNOWN)

0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972.
(Format: TXT=9435 bytes) (Also RFC0109, RFC0139, RFC0158, RFC0318,
RFC0328) (Status: UNKNOWN)

0500 Integration of data management systems on a computer network. A.
Shoshani, I. Spiegler. April 1973. (Not online) (Status: UNKNOWN)

0501 Un-muddling "free file transfer". K.T. Pogran. May 1973. (Format:
TXT=13177 bytes) (Status: UNKNOWN)

0508 Real-time data transmission on the ARPANET. L. Pfeifer, J.
McAfee. May 1973. (Format: TXT=25002 bytes) (Status: UNKNOWN)

0552 Single access to standard protocols. A.D. Owen. July 1973.
(Format: TXT=1404 bytes) (Status: UNKNOWN)

0576 Proposal for modifying linking. K. Victor. September 1973. (Not
online) (Status: UNKNOWN)

0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March
1974. (Format: TXT=9448 bytes) (Status: UNKNOWN)

0661 Protocol information. J. Postel. November 1974. (Not online)
(Status: UNKNOWN)

0662 Performance improvement in ARPANET file transfers from Multics.
R. Kanodia. November 1974. (Format: TXT=8872 bytes) (Status: UNKNOWN)

0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty.
April 1976. (Format: TXT=41175 bytes) (Status: UNKNOWN)

0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie.
April 1976. (Not online) (Status: UNKNOWN)

0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT=2322
bytes) (Status: HISTORIC)

0718 Comments on RCTE from the Tenex Implementation Experience. J.
Postel. June 1976. (Format: TXT=3829 bytes) (Status: UNKNOWN)

0720 Address Specification Syntax for Network Mail. D. Crocker. August
1976. (Format: TXT=6602 bytes) (Status: UNKNOWN)

0739 Assigned numbers. J. Postel. November 1977. (Format: TXT=16346
bytes) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status:
HISTORIC)

0744 MARS - a Message Archiving and Retrieval Service. J. Sattley.
January 1978. (Format: TXT=10984 bytes) (Status: UNKNOWN)

0752 Universal host table. M.R. Crispin. January 1979. (Format:
TXT=33793 bytes) (Status: UNKNOWN)

0753 Internet Message Protocol. J. Postel. March 1979. (Format:
TXT=93363 bytes) (Status: UNKNOWN)

0754 Out-of-net host addresses for mail. J. Postel. April 1979.
(Format: TXT=19212 bytes) (Status: UNKNOWN)

0755 Assigned numbers. J. Postel. May 1979. (Format: TXT=22039 bytes)
(Obsoletes RFC0750) (Obsoleted by RFC0758) (Status: HISTORIC)

0756 NIC name server - a datagram-based information utility. J.R.
Pickens, E.J. Feinler, J.E. Mathis. July 1979. (Format: TXT=23491
bytes) (Status: UNKNOWN)

0757 Suggested solution to the naming, addressing, and delivery
problem for ARPANET message systems. D.P. Deutsch. September 1979.
(Format: TXT=35618 bytes) (Status: UNKNOWN)

0758 Assigned numbers. J. Postel. August 1979. (Format: TXT=22911
bytes) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC)

0759 Internet Message Protocol. J. Postel. August 1980. (Format:
TXT=123606 bytes) (Status: HISTORIC)

0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format:
TXT=81507 bytes) (Obsoletes IEN 123) (Obsoleted by RFC0791) (Updated
by RFC0777) (Status: UNKNOWN)

0761 DoD standard Transmission Control Protocol. J. Postel. January
1980. (Format: TXT=167049 bytes) (Status: UNKNOWN)

0762 Assigned numbers. J. Postel. January 1980. (Format: TXT=24668
bytes) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC)

0763 Role mailboxes. M.D. Abrams. May 1980. (Format: TXT=942 bytes)
(Status: UNKNOWN)

0764 Telnet Protocol specification. J. Postel. June 1980. (Format:
TXT=40005 bytes) (Obsoleted by RFC0854) (Status: UNKNOWN)

0765 File Transfer Protocol specification. J. Postel. June 1980.
(Format: TXT=146641 bytes) (Obsoletes RFC0542) (Obsoleted by RFC0959)
(Status: UNKNOWN)

0766 Internet Protocol Handbook: Table of contents. J. Postel. July
1980. (Format: TXT=3465 bytes) (Obsoleted by RFC0774) (Status:
UNKNOWN)

0770 Assigned numbers. J. Postel. September 1980. (Format: TXT=26248
bytes) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC)

0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980.
(Format: TXT=18623 bytes) (Status: UNKNOWN)

0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980.
(Format: TXT=61061 bytes) (Obsoleted by RFC0780, STD0010) (Status:
UNKNOWN)

0773 Comments on NCP/TCP mail service transition strategy. V.G. Cerf.
October 1980. (Format: TXT=22181 bytes) (Status: UNKNOWN)

0781 Specification of the Internet Protocol (IP) timestamp option. Z.
Su. May 1981. (Format: TXT=4002 bytes) (Status: UNKNOWN)

0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton.
January 1981. (Format: TXT=43589 bytes) (Status: UNKNOWN)

0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)

0792 Internet Control Message Protocol. J. Postel. September 1981.
(Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950,
RFC4884) (Also STD0005) (Status: STANDARD)

0793 Transmission Control Protocol. J. Postel. September 1981.
(Format: TXT=172710 bytes) (Updated by RFC3168) (Also STD0007)
(Status: STANDARD)

0796 Address mappings. J. Postel. September 1981. (Format: TXT=11239
bytes) (Obsoletes IEN 115) (Status: UNKNOWN)

0797 Format for Bitmap files. A.R. Katz. September 1981. (Format:
TXT=3067 bytes) (Status: UNKNOWN)

0799 Internet name domains. D.L. Mills. September 1981. (Format:
TXT=13896 bytes) (Status: UNKNOWN)

0801 NCP/TCP transition plan. J. Postel. November 1981. (Format:
TXT=42041 bytes) (Status: UNKNOWN)

0802 ARPANET 1822L Host Access Protocol. A.G. Malis. November 1981.
(Format: TXT=62470 bytes) (Obsoleted by RFC0851) (Status: UNKNOWN)

0814 Name, addresses, ports, and routes. D.D. Clark. July 1982.
(Format: TXT=24663 bytes) (Status: UNKNOWN)

0819 Domain naming convention for Internet user applications. Z. Su,
J. Postel. August 1982. (Format: TXT=35314 bytes) (Status: UNKNOWN)

0820 Assigned numbers. J. Postel. August 1982. (Format: TXT=54213
bytes) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC)

0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D.
Crocker. August 1982. (Format: TXT=106299 bytes) (Obsoletes RFC0733)
(Obsoleted by RFC2822) (Updated by RFC1123, RFC2156, RFC1327,
RFC1138, RFC1148) (Also STD0011) (Status: STANDARD)

0823 DARPA Internet gateway. R.M. Hinden, A. Sheltzer. September 1982.
(Format: TXT=62620 bytes) (Updates IEN 109, IEN 30) (Status:
HISTORIC)

0840 Official protocols. J. Postel. April 1983. (Format: TXT=33534
bytes) (Obsoleted by RFC0880) (Status: HISTORIC)

0841 Specification for message format for Computer Based Message
Systems. National Bureau of Standards. January 1983. (Format:
TXT=231871 bytes) (Obsoletes RFC0806) (Status: UNKNOWN)

0849 Suggestions for improved host table distribution. M.R. Crispin.
May 1983. (Format: TXT=5178 bytes) (Status: UNKNOWN)

0850 Standard for interchange of USENET messages. M.R. Horton. June
1983. (Format: TXT=43871 bytes) (Obsoleted by RFC1036) (Status:
UNKNOWN)

0869 Host Monitoring Protocol. R. Hinden. December 1983. (Format:
TXT=94550 bytes) (Status: HISTORIC)

0870 Assigned numbers. J.K. Reynolds, J. Postel. October 1983.
(Format: TXT=56055 bytes) (Obsoletes RFC0820) (Obsoleted by RFC0900)
(Status: HISTORIC)

0871 Perspective on the ARPANET reference model. M.A. Padlipsky.
September 1982. (Format: TXT=74455 bytes) (Status: UNKNOWN)

0872 TCP-on-a-LAN. M.A. Padlipsky. September 1982. (Format: TXT=22446
bytes) (Status: UNKNOWN)

0875 Gateways, architectures, and heffalumps. M.A. Padlipsky.
September 1982. (Format: TXT=22816 bytes) (Status: UNKNOWN)

0881 Domain names plan and schedule. J. Postel. November 1983.
(Format: TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN)

0882 Domain names: Concepts and facilities. P.V. Mockapetris. November
1983. (Format: TXT=79776 bytes) (Obsoleted by RFC1034, RFC1035)
(Updated by RFC0973) (Status: UNKNOWN)

0883 Domain names: Implementation specification. P.V. Mockapetris.
November 1983. (Format: TXT=175067 bytes) (Obsoleted by RFC1034,
RFC1035) (Updated by RFC0973) (Status: UNKNOWN)