Network Working Group P. Mockapetris
`Request for Comments: 883 ISI
` November 1983
`
` DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION
`
` +-----------------------------------------------------+
` | |
` | This memo discusses the implementation of domain |
` | name servers and resolvers, specifies the format of |
` | transactions, and discusses the use of domain names |
` | in the context of existing mail systems and other |
` | network software. |
` | |
` | This memo assumes that the reader is familiar with |
` | RFC 882, "Domain Names - Concepts and Facilities" |
` | which discusses the basic principles of domain |
` | names and their use. |
` | |
` | The algorithms and internal data structures used in |
` | this memo are offered as suggestions rather than |
` | requirements; implementers are free to design their |
` | own structures so long as the same external |
` | behavior is achieved. |
` | |
` +-----------------------------------------------------+
`
` +-----------------------------------------------+
` | |
` | ***** WARNING ***** |
` | |
` | This RFC contains format specifications which |
` | are preliminary and are included for purposes |
` | of explanation only. Do not attempt to use |
` | this information for actual implementations. |
` | |
` +-----------------------------------------------+
`
`Mockapetris [Page i]
`
`Petitioner Apple Inc. - Ex. 1033, p. i
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
`TABLE OF CONTENTS
` INTRODUCTION........................................................3
` Overview.........................................................3
` Implementation components........................................2
` Conventions......................................................6
` Design philosophy................................................8
` NAME SERVER TRANSACTIONS...........................................11
` Introduction....................................................11
` Query and response transport....................................11
` Overall message format..........................................13
` The contents of standard queries and responses..................15
` Standard query and response example.............................15
` The contents of inverse queries and responses...................17
` Inverse query and response example..............................18
` Completion queries and responses................................19
` Completion query and response example...........................22
` Recursive Name Service..........................................24
` Header section format...........................................26
` Question section format.........................................29
` Resource record format..........................................30
` Domain name representation and compression......................31
` Organization of the Shared database.............................33
` Query processing................................................36
` Inverse query processing........................................37
` Completion query processing.....................................38
` NAME SERVER MAINTENANCE............................................39
` Introduction....................................................39
` Conceptual model of maintenance operations......................39
` Name server data structures and top level logic.................41
` Name server file loading........................................43
` Name server file loading example................................45
` Name server remote zone transfer................................47
` RESOLVER ALGORITHMS................................................50
` Operations......................................................50
` DOMAIN SUPPORT FOR MAIL............................................52
` Introduction....................................................52
` Agent binding...................................................53
` Mailbox binding.................................................54
` Appendix 1 - Domain Name Syntax Specification......................56
` Appendix 2 - Field formats and encodings...........................57
` TYPE values.....................................................57
` QTYPE values....................................................57
` CLASS values....................................................58
` QCLASS values...................................................58
` Standard resource record formats................................59
` Appendix 3 - Internet specific field formats and operations........67
` REFERENCES and BIBLIOGRAPHY........................................72
` INDEX..............................................................73
`
`Mockapetris [Page ii]
`
`Petitioner Apple Inc. - Ex. 1033, p. ii
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
`INTRODUCTION
`
` Overview
`
` The goal of domain names is to provide a mechanism for naming
` resources in such a way that the names are usable in different
` hosts, networks, protocol families, internets, and administrative
` organizations.
`
` From the user’s point of view, domain names are useful as
` arguments to a local agent, called a resolver, which retrieves
` information associated with the domain name. Thus a user might
` ask for the host address or mail information associated with a
` particular domain name. To enable the user to request a
` particular type of information, an appropriate query type is
` passed to the resolver with the domain name. To the user, the
` domain tree is a single information space.
`
` From the resolver’s point of view, the database that makes up the
` domain space is distributed among various name servers. Different
` parts of the domain space are stored in different name servers,
` although a particular data item will usually be stored redundantly
` in two or more name servers. The resolver starts with knowledge
` of at least one name server. When the resolver processes a user
` query it asks a known name server for the information; in return,
` the resolver either receives the desired information or a referral
` to another name server. Using these referrals, resolvers learn
` the identities and contents of other name servers. Resolvers are
` responsible for dealing with the distribution of the domain space
` and dealing with the effects of name server failure by consulting
` redundant databases in other servers.
`
` Name servers manage two kinds of data. The first kind of data
` held in sets called zones; each zone is the complete database for
` a particular subtree of the domain space. This data is called
` authoritative. A name server periodically checks to make sure
` that its zones are up to date, and if not obtains a new copy of
` updated zones from master files stored locally or in another name
` server. The second kind of data is cached data which was acquired
` by a local resolver. This data may be incomplete but improves the
` performance of the retrieval process when non-local data is
` repeatedly accessed. Cached data is eventually discarded by a
` timeout mechanism.
`
` This functional structure isolates the problems of user interface,
` failure recovery, and distribution in the resolvers and isolates
` the database update and refresh problems in the name servers.
`
`Mockapetris [Page 1]
`
`Petitioner Apple Inc. - Ex. 1033, p. 1
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` Implementation components
`
` A host can participate in the domain name system in a number of
` ways, depending on whether the host runs programs that retrieve
` information from the domain system, name servers that answer
` queries from other hosts, or various combinations of both
` functions. The simplest, and perhaps most typical, configuration
` is shown below:
`
` Local Host | Foreign
` |
` +---------+ +----------+ | +--------+
` | | user queries | |queries | | |
` | User |-------------->| |---------|->|Foreign |
` | Program | | Resolver | | | Name |
` | |<--------------| |<--------|--| Server |
` | | user responses| |responses| | |
` +---------+ +----------+ | +--------+
` | A |
` cache additions | | references |
` V | |
` +----------+ |
` | database | |
` +----------+ |
`
` User programs interact with the domain name space through
` resolvers; the format of user queries and user responses is
` specific to the host and its operating system. User queries will
` typically be operating system calls, and the resolver and its
` database will be part of the host operating system. Less capable
` hosts may choose to implement the resolver as a subroutine to be
` linked in with every program that needs its services.
`
` Resolvers answer user queries with information they acquire via
` queries to foreign name servers, and may also cache or reference
` domain information in the local database.
`
` Note that the resolver may have to make several queries to several
` different foreign name servers to answer a particular user query,
` and hence the resolution of a user query may involve several
` network accesses and an arbitrary amount of time. The queries to
` foreign name servers and the corresponding responses have a
` standard format described in this memo, and may be datagrams.
`
`Mockapetris [Page 2]
`
`Petitioner Apple Inc. - Ex. 1033, p. 2
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` Depending on its capabilities, a name server could be a stand
` alone program on a dedicated machine or a process or processes on
` a large timeshared host. A simple configuration might be:
`
` Local Host | Foreign
` |
` +---------+ |
` / /| |
` +---------+ | +----------+ | +--------+
` | | | | |responses| | |
` | | | | Name |---------|->|Foreign |
` | Master |-------------->| Server | | |Resolver|
` | files | | | |<--------|--| |
` | |/ | | queries | +--------+
` +---------+ +----------+ |
`
` Here the name server acquires information about one or more zones
` by reading master files from its local file system, and answers
` queries about those zones that arrive from foreign resolvers.
`
` A more sophisticated name server might acquire zones from foreign
` name servers as well as local master files. This configuration is
` shown below:
`
` Local Host | Foreign
` |
` +---------+ |
` / /| |
` +---------+ | +----------+ | +--------+
` | | | | |responses| | |
` | | | | Name |---------|->|Foreign |
` | Master |-------------->| Server | | |Resolver|
` | files | | | |<--------|--| |
` | |/ | | queries | +--------+
` +---------+ +----------+ |
` A |maintenance | +--------+
` | \------------|->| |
` | queries | |Foreign |
` | | | Name |
` \------------------|--| Server |
` maintenance responses | +--------+
`
` In this configuration, the name server periodically establishes a
` virtual circuit to a foreign name server to acquire a copy of a
` zone or to check that an existing copy has not changed. The
` messages sent for these maintenance activities follow the same
` form as queries and responses, but the message sequences are
` somewhat different.
`
`Mockapetris [Page 3]
`
`Petitioner Apple Inc. - Ex. 1033, p. 3
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` The information flow in a host that supports all aspects of the
` domain name system is shown below:
`
` Local Host | Foreign
` |
` +---------+ +----------+ | +--------+
` | | user queries | |queries | | |
` | User |-------------->| |---------|->|Foreign |
` | Program | | Resolver | | | Name |
` | |<--------------| |<--------|--| Server |
` | | user responses| |responses| | |
` +---------+ +----------+ | +--------+
` | A |
` cache additions | | references |
` V | |
` +----------+ |
` | Shared | |
` | database | |
` +----------+ |
` A | |
` +---------+ refreshes | | references |
` / /| | V |
` +---------+ | +----------+ | +--------+
` | | | | |responses| | |
` | | | | Name |---------|->|Foreign |
` | Master |-------------->| Server | | |Resolver|
` | files | | | |<--------|--| |
` | |/ | | queries | +--------+
` +---------+ +----------+ |
` A |maintenance | +--------+
` | \------------|->| |
` | queries | |Foreign |
` | | | Name |
` \------------------|--| Server |
` maintenance responses | +--------+
`
` The shared database holds domain space data for the local name
` server and resolver. The contents of the shared database will
` typically be a mixture of authoritative data maintained by the
` periodic refresh operations of the name server and cached data
` from previous resolver requests. The structure of the domain data
` and the necessity for synchronization between name servers and
` resolvers imply the general characteristics of this database, but
` the actual format is up to the local implementer. This memo
` suggests a multiple tree format.
`
`Mockapetris [Page 4]
`
`Petitioner Apple Inc. - Ex. 1033, p. 4
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` This memo divides the implementation discussion into sections:
`
` NAME SERVER TRANSACTIONS, which discusses the formats for name
` servers queries and the corresponding responses.
`
` NAME SERVER MAINTENANCE, which discusses strategies,
` algorithms, and formats for maintaining the data residing in
` name servers. These services periodically refresh the local
` copies of zones that originate in other hosts.
`
` RESOLVER ALGORITHMS, which discusses the internal structure of
` resolvers. This section also discusses data base sharing
` between a name server and a resolver on the same host.
`
` DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain
` system to support mail transfer.
`
`Mockapetris [Page 5]
`
`Petitioner Apple Inc. - Ex. 1033, p. 5
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` Conventions
`
` The domain system has several conventions dealing with low-level,
` but fundamental, issues. While the implementer is free to violate
` these conventions WITHIN HIS OWN SYSTEM, he must observe these
` conventions in ALL behavior observed from other hosts.
`
` ********** Data Transmission Order **********
`
` The order of transmission of the header and data described in this
` document is resolved to the octet level. Whenever a diagram shows
` a group of octets, the order of transmission of those octets is
` the normal order in which they are read in English. For example,
` in the following diagram the octets are transmitted in the order
` they are numbered.
`
` 0 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 1 | 2 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 3 | 4 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | 5 | 6 |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Transmission Order of Bytes
`
` Whenever an octet represents a numeric quantity the left most bit
` in the diagram is the high order or most significant bit. That
` is, the bit labeled 0 is the most significant bit. For example,
` the following diagram represents the value 170 (decimal).
`
` 0 1 2 3 4 5 6 7
` +-+-+-+-+-+-+-+-+
` |1 0 1 0 1 0 1 0|
` +-+-+-+-+-+-+-+-+
`
` Significance of Bits
`
` Similarly, whenever a multi-octet field represents a numeric
` quantity the left most bit of the whole field is the most
` significant bit. When a multi-octet quantity is transmitted the
` most significant octet is transmitted first.
`
`Mockapetris [Page 6]
`
`Petitioner Apple Inc. - Ex. 1033, p. 6
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` ********** Character Case **********
`
` All comparisons between character strings (e.g. labels, domain
` names, etc.) are done in a case-insensitive manner.
`
` When data enters the domain system, its original case should be
` preserved whenever possible. In certain circumstances this cannot
` be done. For example, if two domain names x.y and X.Y are entered
` into the domain database, they are interpreted as the same name,
` and hence may have a single representation. The basic rule is
` that case can be discarded only when data is used to define
` structure in a database, and two names are identical when compared
` in a case insensitive manner.
`
` Loss of case sensitive data must be minimized. Thus while data
` for x.y and X.Y may both be stored under x.y, data for a.x and B.X
` can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In
` general, this prevents the first component of a domain name from
` loss of case information.
`
` Systems administrators who enter data into the domain database
` should take care to represent the data they supply to the domain
` system in a case-consistent manner if their system is
` case-sensitive. The data distribution system in the domain system
` will ensure that consistent representations are preserved.
`
`Mockapetris [Page 7]
`
`Petitioner Apple Inc. - Ex. 1033, p. 7
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` Design philosophy
`
` The design presented in this memo attempts to provide a base which
` will be suitable for several existing networks. An equally
` important goal is to provide these services within a framework
` that is capable of adjustment to fit the evolution of services in
` early clients as well as to accommodate new networks.
`
` Since it is impossible to predict the course of these
` developments, the domain system attempts to provide for evolution
` in the form of an extensible framework. This section describes
` the areas in which we expect to see immediate evolution.
`
` DEFINING THE DATABASE
`
` This memo defines methods for partitioning the database and data
` for host names, host addresses, gateway information, and mail
` support. Experience with this system will provide guidance for
` future additions.
`
` While the present system allows for many new RR types, classes,
` etc., we feel that it is more important to get the basic services
` in operation than to cover an exhaustive set of information.
` Hence we have limited the data types to those we felt were
` essential, and would caution designers to avoid implementations
` which are based on the number of existing types and classes.
` Extensibility in this area is very important.
`
` While the domain system provides techniques for partitioning the
` database, policies for administrating the orderly connection of
` separate domains and guidelines for constructing the data that
` makes up a particular domain will be equally important to the
` success of the system. Unfortunately, we feel that experience
` with prototype systems will be necessary before this question can
` be properly addressed. Thus while this memo has minimal
` discussion of these issues, it is a critical area for development.
`
` TYING TOGETHER INTERNETS
`
` Although it is very difficult to characterize the types of
` networks, protocols, and applications that will be clients of the
` domain system, it is very obvious that some of these applications
` will cross the boundaries of network and protocol. At the very
` least, mail is such a service.
`
` Attempts to unify two such systems must deal with two major
` problems:
`
` 1. Differing formats for environment sensitive data. For example,
`
`Mockapetris [Page 8]
`
`Petitioner Apple Inc. - Ex. 1033, p. 8
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` network addresses vary in format, and it is unreasonable to
` expect to enforce consistent conventions.
`
` 2. Connectivity may require intermediaries. For example, it is a
` frequent occurence that mail is sent between hosts that share
` no common protocol.
`
` The domain system acknowledges that these are very difficult
` problems, and attempts to deal with both problems through its
` CLASS mechanism:
`
` 1. The CLASS field in RRs allows data to be tagged so that all
` programs in the domain system can identify the format in use.
`
` 2. The CLASS field allows the requestor to identify the format of
` data which can be understood by the requestor.
`
` 3. The CLASS field guides the search for the requested data.
`
` The last point is central to our approach. When a query crosses
` protocol boundaries, it must be guided though agents capable of
` performing whatever translation is required. For example, when a
` mailer wants to identify the location of a mailbox in a portion of
` the domain system that doesn’t have a compatible protocol, the
` query must be guided to a name server that can cross the boundary
` itself or form one link in a chain that can span the differences.
`
` If query and response transport were the only problem, then this
` sort of problem could be dealt with in the name servers
` themselves. However, the applications that will use domain
` service have similar problems. For example, mail may need to be
` directed through mail gateways, and the characteristics of one of
` the environments may not permit frequent connectivity between name
` servers in all environments.
`
` These problems suggest that connectivity will be achieved through
` a variety of measures:
`
` Translation name servers that act as relays between different
` protocols.
`
` Translation application servers that translate application
` level transactions.
`
` Default database entries that route traffic through application
` level forwarders in ways that depend on the class of the
` requestor.
`
` While this approach seems best given our current understanding of
`
`Mockapetris [Page 9]
`
`Petitioner Apple Inc. - Ex. 1033, p. 9
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` the problem, we realize that the approach of using resource data
` that transcends class may be appropriate in future designs or
` applications. By not defining class to be directly related to
` protocol, network, etc., we feel that such services could be added
` by defining a new "universal" class, while the present use of
` class will provide immediate service.
`
` This problem requires more thought and experience before solutions
` can be discovered. The concepts of CLASS, recursive servers and
` other mechanisms are intended as tools for acquiring experience
` and not as final solutions.
`
`Mockapetris [Page 10]
`
`Petitioner Apple Inc. - Ex. 1033, p. 10
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
`NAME SERVER TRANSACTIONS
`
` Introduction
`
` The primary purpose of name servers is to receive queries from
` resolvers and return responses. The overall model of this service
` is that a program (typically a resolver) asks the name server
` questions (queries) and gets responses that either answer the
` question or refer the questioner to another name server. Other
` functions related to name server database maintenance use similar
` procedures and formats and are discussed in a section later in
` this memo.
`
` There are three kinds of queries presently defined:
`
` 1. Standard queries that ask for a specified resource attached
` to a given domain name.
`
` 2. Inverse queries that specify a resource and ask for a domain
` name that possesses that resource.
`
` 3. Completion queries that specify a partial domain name and a
` target domain and ask that the partial domain name be
` completed with a domain name close to the target domain.
`
` This memo uses an unqualified reference to queries to refer to
` either all queries or standard queries when the context is clear.
`
` Query and response transport
`
` Name servers and resolvers use a single message format for all
` communications. The message format consists of a variable-length
` octet string which includes binary values.
`
` The messages used in the domain system are designed so that they
` can be carried using either datagrams or virtual circuits. To
` accommodate the datagram style, all responses carry the query as
` part of the response.
`
` While the specification allows datagrams to be used in any
` context, some activities are ill suited to datagram use. For
` example, maintenance transactions and recursive queries typically
` require the error control of virtual circuits. Thus datagram use
` should be restricted to simple queries.
`
` The domain system assumes that a datagram service provides:
`
` 1. A non-reliable (i.e. best effort) method of transporting a
` message of up to 512 octets.
`
`Mockapetris [Page 11]
`
`Petitioner Apple Inc. - Ex. 1033, p. 11
`
`

`

`
`RFC 883 November 1983
` Domain Names - Implementation and Specification
`
` Hence datagram messages are limited to 512 octets. If a
` datagram message would exceed 512 octets, it is truncated
` and a truncation flag is set in its header.
`
` 2. A message size that gives the number of octets in the
` datagram.
`
` The main implications for programs accessing name servers via
` datagrams are:
`
` 1. Datagrams should not be used for maintenance transactions
` and recursive queries.
`
` 2. Since datagrams may be lost, the originator of a query must
` perform error recovery (such as retransmissions) as
` appropriate.
`
` 3. Since network or host delay may cause retransmission when a
` datagram has not been lost, the originator of a query must
` be ready to deal with duplicate responses.
`
` The domain system assumes that a virtual circuit service provides:
`
` 1. A reliable method of transmitting a message of up to 65535
` octets.
`
` 2. A message size that gives the number of octets in the
` message.
`
` If the virtual circuit service does not provide for message
` boundary detection or limits transmission size to less than
` 65535 octets, then messages are prefaced with an unsigned 16
` bit length field and broken up into separate transmissions
` as required. The length field is only prefaced on the first
` message. This technique is used for TCP virtual circuits.
`
` 3. Multiple messages