summaryrefslogtreecommitdiff
path: root/docs/rfc/rfc1035.txt
diff options
context:
space:
mode:
authorPeter Powell <petpow@saberuk.com>2013-11-24 16:20:31 +0000
committerPeter Powell <petpow@saberuk.com>2013-12-15 06:46:44 +0000
commit7fea7c24c509731040b76191d279972fced7b64c (patch)
tree65fc075fad393f4398592016cefa8fd42a6541a9 /docs/rfc/rfc1035.txt
parent07d0d8f52f361c64b3c16d7e432f475cd2131a28 (diff)
Purge docs/rfc from the repository.
These are of no use to 99% of users and anyone who actually wants to read them should be capable of using Google to find them.
Diffstat (limited to 'docs/rfc/rfc1035.txt')
-rw-r--r--docs/rfc/rfc1035.txt3077
1 files changed, 0 insertions, 3077 deletions
diff --git a/docs/rfc/rfc1035.txt b/docs/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5a9..000000000
--- a/docs/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group P. Mockapetris
-Request for Comments: 1035 ISI
- November 1987
-Obsoletes: RFCs 882, 883, 973
-
- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental. Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol. The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses). Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical. Distribution of this memo is unlimited.
-
- Table of Contents
-
- 1. STATUS OF THIS MEMO 1
- 2. INTRODUCTION 3
- 2.1. Overview 3
- 2.2. Common configurations 4
- 2.3. Conventions 7
- 2.3.1. Preferred name syntax 7
- 2.3.2. Data Transmission Order 8
- 2.3.3. Character Case 9
- 2.3.4. Size limits 10
- 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
- 3.1. Name space definitions 10
- 3.2. RR definitions 11
- 3.2.1. Format 11
- 3.2.2. TYPE values 12
- 3.2.3. QTYPE values 12
- 3.2.4. CLASS values 13
-
-
-
-Mockapetris [Page 1]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 3.2.5. QCLASS values 13
- 3.3. Standard RRs 13
- 3.3.1. CNAME RDATA format 14
- 3.3.2. HINFO RDATA format 14
- 3.3.3. MB RDATA format (EXPERIMENTAL) 14
- 3.3.4. MD RDATA format (Obsolete) 15
- 3.3.5. MF RDATA format (Obsolete) 15
- 3.3.6. MG RDATA format (EXPERIMENTAL) 16
- 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
- 3.3.8. MR RDATA format (EXPERIMENTAL) 17
- 3.3.9. MX RDATA format 17
- 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
- 3.3.11. NS RDATA format 18
- 3.3.12. PTR RDATA format 18
- 3.3.13. SOA RDATA format 19
- 3.3.14. TXT RDATA format 20
- 3.4. ARPA Internet specific RRs 20
- 3.4.1. A RDATA format 20
- 3.4.2. WKS RDATA format 21
- 3.5. IN-ADDR.ARPA domain 22
- 3.6. Defining new types, classes, and special namespaces 24
- 4. MESSAGES 25
- 4.1. Format 25
- 4.1.1. Header section format 26
- 4.1.2. Question section format 28
- 4.1.3. Resource record format 29
- 4.1.4. Message compression 30
- 4.2. Transport 32
- 4.2.1. UDP usage 32
- 4.2.2. TCP usage 32
- 5. MASTER FILES 33
- 5.1. Format 33
- 5.2. Use of master files to define zones 35
- 5.3. Master file example 36
- 6. NAME SERVER IMPLEMENTATION 37
- 6.1. Architecture 37
- 6.1.1. Control 37
- 6.1.2. Database 37
- 6.1.3. Time 39
- 6.2. Standard query processing 39
- 6.3. Zone refresh and reload processing 39
- 6.4. Inverse queries (Optional) 40
- 6.4.1. The contents of inverse queries and responses 40
- 6.4.2. Inverse query and response example 41
- 6.4.3. Inverse query processing 42
-
-
-
-
-
-
-Mockapetris [Page 2]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 6.5. Completion queries and responses 42
- 7. RESOLVER IMPLEMENTATION 43
- 7.1. Transforming a user request into a query 43
- 7.2. Sending the queries 44
- 7.3. Processing responses 46
- 7.4. Using the cache 47
- 8. MAIL SUPPORT 47
- 8.1. Mail exchange binding 48
- 8.2. Mailbox binding (Experimental) 48
- 9. REFERENCES and BIBLIOGRAPHY 50
- Index 54
-
-2. INTRODUCTION
-
-2.1. 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; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-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 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
-"pruned" 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
-
-
-
-Mockapetris [Page 3]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-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.
-
-2.2. Common configurations
-
-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 | |
- +----------+ |
- | cache | |
- +----------+ |
-
-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 cache 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 the local cache.
-
-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
-
-
-
-Mockapetris [Page 4]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in this memo, and may be datagrams.
-
-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 a primary 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.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server. Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS. 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
-
-
-
-Mockapetris [Page 5]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-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 implementor.
-
-
-
-
-Mockapetris [Page 6]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities. Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required. This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio. In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
- Local Hosts | Foreign
- |
- +---------+ |
- | | responses |
- | Stub |<--------------------+ |
- | Resolver| | |
- | |----------------+ | |
- +---------+ recursive | | |
- queries | | |
- V | |
- +---------+ recursive +----------+ | +--------+
- | | queries | |queries | | |
- | Stub |-------------->| Recursive|---------|->|Foreign |
- | Resolver| | Server | | | Name |
- | |<--------------| |<--------|--| Server |
- +---------+ responses | |responses| | |
- +----------+ | +--------+
- | Central | |
- | cache | |
- +----------+ |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues. While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names. The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris [Page 7]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822. When creating a new host name,
-the old rules for HOSTS.TXT should be followed. This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case. That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names. They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen. There are also some
-restrictions on the length. Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. 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
-
-
-
-Mockapetris [Page 8]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-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|
- +-+-+-+-+-+-+-+-+
-
-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.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner. At present, this rule is in
-force throughout the domain system without exception. However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-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 RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved. 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.
-
-
-
-
-Mockapetris [Page 9]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Loss of case sensitive data must be minimized. Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-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.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits. They are
-listed below. Some could be easily changed, others are more
-fundamental.
-
-labels 63 octets or less
-
-names 255 octets or less
-
-TTL positive values of a signed 32 bit number.
-
-UDP messages 512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets. Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero. The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions. Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity. Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris [Page 10]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME an owner name, i.e., the name of the node to which this
- resource record pertains.
-
-TYPE two octets containing one of the RR TYPE codes.
-
-CLASS two octets containing one of the RR CLASS codes.
-
-TTL a 32 bit signed integer that specifies the time interval
- that the resource record may be cached before the source
- of the information should again be consulted. Zero
- values are interpreted to mean that the RR can only be
- used for the transaction in progress, and should not be
- cached. For example, SOA records are always distributed
- with a zero TTL to prohibit caching. Zero values can
- also be used for extremely volatile data.
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-
-
-Mockapetris [Page 11]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records. Note that these types are a
-subset of QTYPEs.
-
-TYPE value and meaning
-
-A 1 a host address
-
-NS 2 an authoritative name server
-
-MD 3 a mail destination (Obsolete - use MX)
-
-MF 4 a mail forwarder (Obsolete - use MX)
-
-CNAME 5 the canonical name for an alias
-
-SOA 6 marks the start of a zone of authority
-
-MB 7 a mailbox domain name (EXPERIMENTAL)
-
-MG 8 a mail group member (EXPERIMENTAL)
-
-MR 9 a mail rename domain name (EXPERIMENTAL)
-
-NULL 10 a null RR (EXPERIMENTAL)
-
-WKS 11 a well known service description
-
-PTR 12 a domain name pointer
-
-HINFO 13 host information
-
-MINFO 14 mailbox or mail list information
-
-MX 15 mail exchange
-
-TXT 16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query. QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris [Page 12]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-AXFR 252 A request for a transfer of an entire zone
-
-MAILB 253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA 254 A request for mail agent RRs (Obsolete - see MX)
-
-* 255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records. The following CLASS mnemonics
-and values are defined:
-
-IN 1 the Internet
-
-CS 2 the CSNET class (Obsolete - used only for examples in
- some obsolete RFCs)
-
-CH 3 the CHAOS class
-
-HS 4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query. QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS. In
-addition to CLASS values, the following QCLASSes are defined:
-
-* 255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length. <character-string> is a single
-length octet followed by that number of characters. <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris [Page 13]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.1. CNAME RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME A <domain-name> which specifies the canonical or primary
- name for the owner. The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases. See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CPU /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / OS /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU A <character-string> which specifies the CPU type.
-
-OS A <character-string> which specifies the operating
- system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host. The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has the
- specified mailbox.
-
-
-
-Mockapetris [Page 14]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which should be able to deliver
- mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete. See the definition of MX and [RFC-974] for details of
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which will accept mail for
- forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete. See the definition of MX and [RFC-974] for details ofw
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris [Page 15]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MGMNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME A <domain-name> which specifies a mailbox which is a
- member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX A <domain-name> which specifies a mailbox which is
- responsible for the mailing list or mailbox. If this
- domain name names the root, the owner of the MINFO RR is
- responsible for itself. Note that many existing mailing
- lists use a mailbox X-request for the RMAILBX field of
- mailing list X, e.g., Msgroup-request for Msgroup. This
- field provides a more general mechanism.
-
-
-EMAILBX A <domain-name> which specifies a mailbox which is to
- receive error messages related to the mailing list or
- mailbox specified by the owner of the MINFO RR (similar
- to the ERRORS-TO: field which has been proposed). If
- this domain name names the root, errors should be
- returned to the sender of the message.
-
-MINFO records cause no additional section processing. Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris [Page 16]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NEWNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME A <domain-name> which specifies a mailbox which is the
- proper rename of the specified mailbox.
-
-MR records cause no additional section processing. The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EXCHANGE /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE A 16 bit integer which specifies the preference given to
- this RR among others at the same owner. Lower values
- are preferred.
-
-EXCHANGE A <domain-name> which specifies a host willing to act as
- a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE. The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / <anything> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris [Page 17]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-NULL records cause no additional section processing. NULL RRs are not
-allowed in master files. NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NSDNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME A <domain-name> which specifies a host which should be
- authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class. Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint. For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / PTRDNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME A <domain-name> which points to some location in the
- domain name space.
-
-PTR records cause no additional section processing. These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases. See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris [Page 18]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.13. SOA RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | SERIAL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | REFRESH |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RETRY |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | EXPIRE |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | MINIMUM |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME The <domain-name> of the name server that was the
- original or primary source of data for this zone.
-
-RNAME A <domain-name> which specifies the mailbox of the
- person responsible for this zone.
-
-SERIAL The unsigned 32 bit version number of the original copy
- of the zone. Zone transfers preserve this value. This
- value wraps and should be compared using sequence space
- arithmetic.
-
-REFRESH A 32 bit time interval before the zone should be
- refreshed.
-
-RETRY A 32 bit time interval that should elapse before a
- failed refresh should be retried.
-
-EXPIRE A 32 bit time value that specifies the upper limit on
- the time interval that can elapse before the zone is no
- longer authoritative.
-
-
-
-
-
-Mockapetris [Page 19]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MINIMUM The unsigned 32 bit minimum TTL field that should be
- exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations. However, MINIMUM is used in all query operations that
-retrieve RRs from a zone. Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone. Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer. The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / TXT-DATA /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text. The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris [Page 20]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-A records cause no additional section processing. The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PROTOCOL | |
- +--+--+--+--+--+--+--+--+ |
- | |
- / <BIT MAP> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS An 32 bit Internet address
-
-PROTOCOL An 8 bit IP protocol number
-
-<BIT MAP> A variable length bit map. The bit map must be a
- multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address. The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol. The first bit corresponds to port 0,
-the second to port 1, etc. If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero. The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP. If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris [Page 21]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping. Other classes may employ a similar
-strategy in other domains. The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix. Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified. Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space. For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET. Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets. Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network. Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it. Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris [Page 22]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
-would receive two RRs in response:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
- - Since the IN-ADDR.ARPA special domain and the normal domain
- for a particular host or gateway will be in different zones,
- the possibility exists that that the data may be inconsistent.
-
- - Gateways will often have two names in separate domains, only
- one of which can be primary.
-
- - Systems that use the domain database to initialize their
- routing tables must start with enough gateway information to
- guarantee that they can access the appropriate name server.
-
- - The gateway data only reflects the existence of a gateway in a
- manner equivalent to the current HOSTS.TXT file. It doesn't
- replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris [Page 23]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo. New definitions should be expected. This section
-makes some recommendations to designers considering additions to the
-existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object. Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information. New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR. This is less efficient for most applications, but does keep
-RRs shorter. The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency. Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address. This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used. This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF). The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
-
-
-
-Mockapetris [Page 24]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs. However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message. The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
- +---------------------+
- | Header |
- +---------------------+
- | Question | the question for the name server
- +---------------------+
- | Answer | RRs answering the question
- +---------------------+
- | Authority | RRs pointing toward an authority
- +---------------------+
- | Additional | RRs holding additional information
- +---------------------+
-
-The header section is always present. The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries. The question section contains fields that describe a
-question to a name server. These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME). The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs). The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 25]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID A 16 bit identifier assigned by the program that
- generates any kind of query. This identifier is copied
- the corresponding reply and can be used by the requester
- to match up replies to outstanding queries.
-
-QR A one bit field that specifies whether this message is a
- query (0), or a response (1).
-
-OPCODE A four bit field that specifies kind of query in this
- message. This value is set by the originator of a query
- and copied into the response. The values are:
-
- 0 a standard query (QUERY)
-
- 1 an inverse query (IQUERY)
-
- 2 a server status request (STATUS)
-
- 3-15 reserved for future use
-
-AA Authoritative Answer - this bit is valid in responses,
- and specifies that the responding name server is an
- authority for the domain name in question section.
-
- Note that the contents of the answer section may have
- multiple owner names because of aliases. The AA bit
-
-
-
-Mockapetris [Page 26]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- corresponds to the name which matches the query name, or
- the first owner name in the answer section.
-
-TC TrunCation - specifies that this message was truncated
- due to length greater than that permitted on the
- transmission channel.
-
-RD Recursion Desired - this bit may be set in a query and
- is copied into the response. If RD is set, it directs
- the name server to pursue the query recursively.
- Recursive query support is optional.
-
-RA Recursion Available - this be is set or cleared in a
- response, and denotes whether recursive query support is
- available in the name server.
-
-Z Reserved for future use. Must be zero in all queries
- and responses.
-
-RCODE Response code - this 4 bit field is set as part of
- responses. The values have the following
- interpretation:
-
- 0 No error condition
-
- 1 Format error - The name server was
- unable to interpret the query.
-
- 2 Server failure - The name server was
- unable to process this query due to a
- problem with the name server.
-
- 3 Name Error - Meaningful only for
- responses from an authoritative name
- server, this code signifies that the
- domain name referenced in the query does
- not exist.
-
- 4 Not Implemented - The name server does
- not support the requested kind of query.
-
- 5 Refused - The name server refuses to
- perform the specified operation for
- policy reasons. For example, a name
- server may not wish to provide the
- information to the particular requester,
- or a name server may not wish to perform
- a particular operation (e.g., zone
-
-
-
-Mockapetris [Page 27]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- transfer) for particular data.
-
- 6-15 Reserved for future use.
-
-QDCOUNT an unsigned 16 bit integer specifying the number of
- entries in the question section.
-
-ANCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the answer section.
-
-NSCOUNT an unsigned 16 bit integer specifying the number of name
- server resource records in the authority records
- section.
-
-ARCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked. The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / QNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QTYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QCLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME a domain name represented as a sequence of labels, where
- each label consists of a length octet followed by that
- number of octets. The domain name terminates with the
- zero length octet for the null label of the root. Note
- that this field may be an odd number of octets; no
- padding is used.
-
-QTYPE a two octet code which specifies the type of the query.
- The values for this field include all codes valid for a
- TYPE field, together with some more general codes which
- can match more than one type of RR.
-
-
-
-Mockapetris [Page 28]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-QCLASS a two octet code that specifies the class of the query.
- For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME a domain name to which this resource record pertains.
-
-TYPE two octets containing one of the RR type codes. This
- field specifies the meaning of the data in the RDATA
- field.
-
-CLASS two octets which specify the class of the data in the
- RDATA field.
-
-TTL a 32 bit unsigned integer that specifies the time
- interval (in seconds) that the resource record may be
- cached before it should be discarded. Zero values are
- interpreted to mean that the RR can only be used for the
- transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris [Page 29]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
- For example, the if the TYPE is A and the CLASS is IN,
- the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message. 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 occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 1 1| OFFSET |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones. This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less. (The 10 and 01 combinations
-are reserved for future use.) The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header). A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
- - a sequence of labels ending in a zero octet
-
- - a pointer
-
- - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific. If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris [Page 30]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
-message, these domain names might be represented as:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 1 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 3 | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | S | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 4 | A |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | R | P |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 30 | A | 0 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 40 | 3 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 42 | O | O |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 44 | 1 1| 20 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 64 | 1 1| 26 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 92 | 0 | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20. The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA. The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20. The root domain name is
-
-
-
-Mockapetris [Page 31]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit. While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance. Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers). Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet. Queries sent using UDP may be
-lost, and hence a retransmission strategy is required. Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
- - The client should try other servers and server addresses
- before repeating a query to a specific address of a server.
-
- - The retransmission interval should be based on prior
- statistics if possible. Too aggressive retransmission can
- easily slow responses for the community at large. Depending
- on how well connected the client is to its expected servers,
- the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal). The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris [Page 32]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-length, excluding the two byte length field. This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
- - The server should not block other activities waiting for TCP
- data.
-
- - The server should support multiple connections.
-
- - The server should assume that the client will initiate
- connection closing, and should delay closing its end of the
- connection until all outstanding client requests have been
- satisfied.
-
- - If the server needs to close a dormant connection to reclaim
- resources, it should wait until the connection has been idle
- for a period on the order of two minutes. In particular, the
- server should allow the SOA and AXFR request sequence (which
- begins a refresh operation) to be made on a single connection.
- Since the server would be unable to answer queries anyway, a
- unilateral close or reset may be used instead of a graceful
- close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form. Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents. Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries. Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text. Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry. The end of
-any line in the master file can end with a comment. The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
- <blank>[<comment>]
-
-
-
-
-Mockapetris [Page 33]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- $ORIGIN <domain-name> [<comment>]
-
- $INCLUDE <file-name> [<domain-name>] [<comment>]
-
- <domain-name><rr> [<comment>]
-
- <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name. $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file. $INCLUDE may also
-have a comment. Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs. If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner. If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
- [<TTL>] [<class>] <type> <RDATA>
-
- [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class. Class and type use the
-standard mnemonics, TTL is a decimal integer. Omitted class and TTL
-values are default to the last explicitly stated values. Since type and
-class mnemonics are disjoint, the parse is unique. (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots. Quoting conventions allow arbitrary characters to be
-stored in domain names. Domain names that end in a dot are called
-absolute, and are taken as complete. Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine. A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris [Page 34]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ". Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded. In particular:
-
- of the root.
-
-@ A free standing @ is used to denote the current origin.
-
-\X where X is any character other than a digit (0-9), is
- used to quote that character so that its special meaning
- does not apply. For example, "\." can be used to place
- a dot character in a label.
-
-\DDD where each D is a digit is the octet corresponding to
- the decimal number described by DDD. The resulting
- octet is assumed to be text and is not checked for
- special meaning.
-
-( ) Parentheses are used to group data that crosses a line
- boundary. In effect, line terminations are not
- recognized within parentheses.
-
-; Semicolon is used to start a comment; the remainder of
- the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file. The
-rationale for this is that a single error can have widespread
-consequences. For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
- 1. All RRs in the file should have the same class.
-
- 2. Exactly one SOA RR should be present at the top of the zone.
-
- 3. If delegations are present and glue information is required,
- it should be present.
-
-
-
-Mockapetris [Page 35]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 4. Information present outside of the authoritative nodes in the
- zone should be glue information, rather than the result of an
- origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@ IN SOA VENERA Action\.domains (
- 20 ; SERIAL
- 7200 ; REFRESH
- 600 ; RETRY
- 3600000; EXPIRE
- 60) ; MINIMUM
-
- NS A.ISI.EDU.
- NS VENERA
- NS VAXA
- MX 10 VENERA
- MX 20 VAXA
-
-A A 26.3.0.103
-
-VENERA A 10.1.0.52
- A 128.9.0.32
-
-VAXA A 10.2.0.27
- A 128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
- MOE MB A.ISI.EDU.
- LARRY MB A.ISI.EDU.
- CURLEY MB A.ISI.EDU.
- STOOGES MG MOE
- MG LARRY
- MG CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris [Page 36]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver. This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program. It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities. Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates. A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
- - A "catalog" data structure which lists the zones available to
- this server, and a "pointer" to the zone data structure. The
- main purpose of this structure is to find the nearest ancestor
- zone, if any, for arriving standard queries.
-
- - Separate data structures for each of the zones held by the
- name server.
-
- - A data structure for cached data. (or perhaps separate caches
- for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs. In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris [Page 37]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case. The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded. In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
- - The catalog structure can be an almost static structure that
- need change only when the system administrator changes the
- zones supported by the server. This structure can also be
- used to store parameters used to control refreshing
- activities.
-
- - The individual data structures for zones allow a zone to be
- replaced simply by changing a pointer in the catalog. Zone
- refresh operations can build a new structure and, when
- complete, splice it into the database via a simple pointer
- replacement. It is very important that when a zone is
- refreshed, queries should not use old and new data
- simultaneously.
-
- - With the proper search procedures, authoritative data in zones
- will always "hide", and hence take precedence over, cached
- data.
-
- - Errors in zone definitions that cause overlapping zones, etc.,
- may cause erroneous responses to queries, but problem
- determination is simplified, and the contents of one "bad"
- zone can't corrupt another.
-
- - Since the cache is most frequently updated, it is most
- vulnerable to corruption during system restarts. It can also
- become full of expired RR data. In either case, it can easily
- be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host. State
-information which a name server should save across system crashes
-
-
-
-Mockapetris [Page 38]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds. Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways: as
-a relative increment and as an absolute time. One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other. The RRs in zones use relative times; the refresh timers and
-cache data use absolute times. Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query. When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram. Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone. This floor function should be done when
-the data is copied into a response. This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter. In this case, the name server
-
-
-
-Mockapetris [Page 39]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible. In any case, it should never send part of one version and
-part of another. If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS. Name servers are not
-required to support any form of inverse queries. If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header. While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name. For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section. The owner name of the
-query RR and its TTL are not significant. The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete. Thus inverse queries are primarily useful for database
-management and debugging activities. Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries. Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix". However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
- 1. zero, one, or multiple domain names for the specified
- resource as QNAMEs in the question section
-
-
-
-Mockapetris [Page 40]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 2. an error code indicating that the name server doesn't support
- inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries. One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear. For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
- +-----------------------------------------+
- Header | OPCODE=IQUERY, ID=997 |
- +-----------------------------------------+
- Question | <empty> |
- +-----------------------------------------+
- Answer | <anyname> A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52. Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored). A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message. The TTL of the RR is not significant. The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 41]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- +-----------------------------------------+
- Header | OPCODE=RESPONSE, ID=997 |
- +-----------------------------------------+
- Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
- +-----------------------------------------+
- Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query. Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique. If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases. An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone. When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted. Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 42]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034]. This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler. The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source. If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information. This state block will
-typically contain:
-
- - A timestamp indicating the time the request began.
- The timestamp is used to decide whether RRs in the database
- can be used or are out of date. This timestamp uses the
- absolute time format previously discussed for RR storage in
- zones and caches. Note that when an RRs TTL indicates a
- relative time, the RR must be timely, since it is part of a
- zone. When the RR has an absolute time, it is part of a
- cache, and the TTL of the RR is compared against the timestamp
- for the start of the request.
-
- Note that using the timestamp is superior to using a current
- time, since it allows RRs with TTLs of zero to be entered in
- the cache in the usual manner, but still used by the current
- request, even after intervals of many seconds due to system
- load, query retransmission timeouts, etc.
-
- - Some sort of parameters to limit the amount of work which will
- be performed for this request.
-
- The amount of work which a resolver will do in response to a
- client request must be limited to guard against errors in the
- database, such as circular CNAME references, and operational
- problems, such as network partition which prevents the
-
-
-
-Mockapetris [Page 43]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- resolver from accessing the name servers it needs. While
- local limits on the number of times a resolver will retransmit
- a particular query to a particular name server address are
- essential, the resolver should have a global per-request
- counter to limit work on a single request. The counter should
- be set to some initial value and decremented whenever the
- resolver performs any action (retransmission timeout,
- retransmission, etc.) If the counter passes zero, the request
- is terminated with a temporary error.
-
- Note that if the resolver structure allows one request to
- start others in parallel, such as when the need to access a
- name server for one request causes a parallel resolve for the
- name server's addresses, the spawned request should be started
- with a lower counter. This prevents circular references in
- the database from starting a chain reaction of resolver
- activity.
-
- - The SLIST data structure discussed in [RFC-1034].
-
- This structure keeps track of the state of a request if it
- must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information. The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information. In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated. Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions. The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive. The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris [Page 44]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about. To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate. The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST. This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request). Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address. Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses. Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses. Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried. The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
- - The resolver may encounter a situation where no addresses are
- available for any of the name servers named in SLIST, and
- where the servers in the list are precisely those which would
- normally be used to look up their own addresses. This
- situation typically occurs when the glue address RRs have a
- smaller TTL than the NS RRs marking delegation, or when the
- resolver caches the result of a NS search. The resolver
- should detect this condition and restart the search at the
- next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris [Page 45]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- - If a resolver gets a server error or other bizarre response
- from a name server, it should remove it from SLIST, and may
- wish to schedule an immediate transmission to the next
- candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response. This procedure should include:
-
- - Check the header for reasonableness. Discard datagrams which
- are queries when responses are expected.
-
- - Parse the sections of the message, and insure that all RRs are
- correctly formatted.
-
- - As an optional step, check the TTLs of arriving data looking
- for RRs with excessively long TTLs. If a RR has an
- excessively long TTL, say greater than 1 week, either discard
- the whole response, or limit all TTLs in the response to 1
- week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired. This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort. This step has several fine points:
-
- - Some name servers send their responses from different
- addresses than the one used to receive the query. That is, a
- resolver cannot rely that a response will come from the same
- address which it sent the corresponding query to. This name
- server bug is typically encountered in UNIX systems.
-
- - If the resolver retransmits a particular request to a name
- server it should be able to use a response from any of the
- transmissions. However, if it is using the response to sample
- the round trip time to access the name server, it must be able
- to determine which transmission matches the response (and keep
- transmission times for each outgoing message), or only
- calculate round trip times based on initial transmissions.
-
- - A name server will occasionally not have a current copy of a
- zone which it should have according to some NS RRs. The
- resolver should simply remove the name server from the current
- SLIST, and continue.
-
-
-
-
-Mockapetris [Page 46]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
- - When several RRs of the same type are available for a
- particular owner name, the resolver should either cache them
- all or none at all. When a response is truncated, and a
- resolver doesn't know whether it has a complete set, it should
- not cache a possibly partial set of RRs.
-
- - Cached data should never be used in preference to
- authoritative data, so if caching would cause this to happen
- the data should not be cached.
-
- - The results of an inverse query should not be cached.
-
- - The results of standard queries where the QNAME contains "*"
- labels if the data might be used to construct wildcards. The
- reason is that the cache does not necessarily contain existing
- RRs or zone boundary information which is necessary to
- restrict the application of the wildcard RRs.
-
- - RR data in responses of dubious reliability. When a resolver
- receives unsolicited responses or RR data other than that
- requested, it should discard it without caching it. The basic
- implication is that all sanity checks on a packet should be
- performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs. Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined. If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information. The first method is called mail exchange binding
-and the other method is mailbox binding. The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet. Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris [Page 47]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>". While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name. The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded. For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent. The <local-part>
-is not even consulted. [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function. However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name. The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris [Page 48]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 1. The query can return a name error indicating that the mailbox
- does not exist as a domain name.
-
- In the long term, this would indicate that the specified
- mailbox doesn't exist. However, until the use of mailbox
- binding is universal, this error condition should be
- interpreted to mean that the organization identified by the
- global part does not support mailbox binding. The
- appropriate procedure is to revert to exchange binding at
- this point.
-
- 2. The query can return a Mail Rename (MR) RR.
-
- The MR RR carries new mailbox specification in its RDATA
- field. The mailer should replace the old mailbox with the
- new one and retry the operation.
-
- 3. The query can return a MB RR.
-
- The MB RR carries a domain name for a host in its RDATA
- field. The mailer should deliver the message to that host
- via whatever protocol is applicable, e.g., b,SMTP.
-
- 4. The query can return one or more Mail Group (MG) RRs.
-
- This condition means that the mailbox was actually a mailing
- list or mail group, rather than a single mailbox. Each MG RR
- has a RDATA field that identifies a mailbox that is a member
- of the group. The mailer should deliver a copy of the
- message to each member.
-
- 5. The query can return a MB RR as well as one or more MG RRs.
-
- This condition means the the mailbox was actually a mailing
- list. The mailer can either deliver the message to the host
- specified by the MB RR, which will in turn do the delivery to
- all members, or the mailer can use the MG RRs to do the
- expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR. This RR is usually associated with a mail group, but is
-legal with a MB. The MINFO RR identifies two mailboxes. One of these
-identifies a responsible person for the original mailbox name. This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures. This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris [Page 49]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987, version 1.9.
-
- Describes the fundamentals of the Hesiod name service.
-
-[IEN-116] J. Postel, "Internet Name Server", IEN-116,
- USC/Information Sciences Institute, August 1979.
-
- A name service obsoleted by the Domain Name System, but
- still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
- Communications of the ACM, October 1986, volume 29, number
- 10.
-
-[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
- Information Center, SRI International, December 1977.
-
-[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
- USC/Information Sciences Institute, September 1981.
-
-[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
- September 1981.
-
- Suggests introduction of a hierarchy in place of a flat
- name space for the Internet.
-
-[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
- USC/Information Sciences Institute, February 1982.
-
-[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
- Internet Host Table Specification", RFC-810, Network
- Information Center, SRI International, March 1982.
-
- Obsolete. See RFC-952.
-
-[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
- Server", RFC-811, Network Information Center, SRI
- International, March 1982.
-
-
-
-
-Mockapetris [Page 50]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Obsolete. See RFC-953.
-
-[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
- Network Information Center, SRI International, March
- 1982.
-
-[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
- Internet User Applications", RFC-819, Network
- Information Center, SRI International, August 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
- RFC-830, Network Information Center, SRI International,
- October 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-882] P. Mockapetris, "Domain names - Concepts and
- Facilities," RFC-882, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-883] P. Mockapetris, "Domain names - Implementation and
- Specification," RFC-883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
- RFC-920, USC/Information Sciences Institute,
- October 1984.
-
- Explains the naming scheme for top level domains.
-
-[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
- Table Specification", RFC-952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address
- table replaced by the DNS.
-
-
-
-
-
-Mockapetris [Page 51]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
- RFC-953, SRI, October 1985.
-
- This RFC contains the official specification of the
- hostname server protocol, which is obsoleted by the DNS.
- This TCP based protocol accesses information stored in
- the RFC-952 format, and is used to obtain copies of the
- host table.
-
-[RFC-973] P. Mockapetris, "Domain System Changes and
- Observations", RFC-973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFC-882 and RFC-883 and reasons for
- them.
-
-[RFC-974] C. Partridge, "Mail routing and the domain system",
- RFC-974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Concepts and Methods",
- RFC-1001, March 1987.
-
- This RFC and RFC-1002 are a preliminary design for
- NETBIOS on top of TCP/IP which proposes to base NetBIOS
- name service on top of the DNS.
-
-[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Detailed
- Specifications", RFC-1002, March 1987.
-
-[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
- USC/Information Sciences Institute, May 1987.
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
- November 1987.
-
- Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
- Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris [Page 52]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Describes the registration policies used by the NIC to
- administer the top level domains and delegate subzones.
-
-[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
- RFC-1033, November 1987.
-
- A cookbook for domain administrators.
-
-[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
- Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
- Describes a name service for CSNET which is independent
- from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 53]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Index
-
- * 13
-
- ; 33, 35
-
- <character-string> 35
- <domain-name> 34
-
- @ 35
-
- \ 35
-
- A 12
-
- Byte order 8
-
- CH 13
- Character case 9
- CLASS 11
- CNAME 12
- Completion 42
- CS 13
-
- Hesiod 13
- HINFO 12
- HS 13
-
- IN 13
- IN-ADDR.ARPA domain 22
- Inverse queries 40
-
- Mailbox names 47
- MB 12
- MD 12
- MF 12
- MG 12
- MINFO 12
- MINIMUM 20
- MR 12
- MX 12
-
- NS 12
- NULL 12
-
- Port numbers 32
- Primary server 5
- PTR 12, 18
-
-
-
-Mockapetris [Page 54]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- QCLASS 13
- QTYPE 12
-
- RDATA 12
- RDLENGTH 11
-
- Secondary server 5
- SOA 12
- Stub resolvers 7
-
- TCP 32
- TXT 12
- TYPE 11
-
- UDP 32
-
- WKS 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 55]
-
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:42:21 +0000