1 Network Working Group P. Mockapetris
2 Request for Comments: 1034 ISI
3 Obsoletes: RFCs 882, 883, 973 November 1987
6 DOMAIN NAMES - CONCEPTS AND FACILITIES
10 1. STATUS OF THIS MEMO
12 This RFC is an introduction to the Domain Name System (DNS), and omits
13 many details which can be found in a companion RFC, "Domain Names -
14 Implementation and Specification" [RFC-1035]. That RFC assumes that the
15 reader is familiar with the concepts discussed in this memo.
17 A subset of DNS functions and data types constitute an official
18 protocol. The official protocol includes standard queries and their
19 responses and most of the Internet class data formats (e.g., host
22 However, the domain system is intentionally extensible. Researchers are
23 continuously proposing, implementing and experimenting with new data
24 types, query types, classes, functions, etc. Thus while the components
25 of the official protocol are expected to stay essentially unchanged and
26 operate as a production service, experimental behavior should always be
27 expected in extensions beyond the official protocol. Experimental or
28 obsolete features are clearly marked in these RFCs, and such information
29 should be used with caution.
31 The reader is especially cautioned not to depend on the values which
32 appear in examples to be current or complete, since their purpose is
33 primarily pedagogical. Distribution of this memo is unlimited.
37 This RFC introduces domain style names, their use for Internet mail and
38 host address support, and the protocols and servers used to implement
39 domain name facilities.
41 2.1. The history of domain names
43 The impetus for the development of the domain system was growth in the
46 - Host name to address mappings were maintained by the Network
47 Information Center (NIC) in a single file (HOSTS.TXT) which
48 was FTPed by all hosts [RFC-952, RFC-953]. The total network
54 RFC 1034 Domain Concepts and Facilities November 1987
57 bandwidth consumed in distributing a new version by this
58 scheme is proportional to the square of the number of hosts in
59 the network, and even when multiple levels of FTP are used,
60 the outgoing FTP load on the NIC host is considerable.
61 Explosive growth in the number of hosts didn't bode well for
64 - The network population was also changing in character. The
65 timeshared hosts that made up the original ARPANET were being
66 replaced with local networks of workstations. Local
67 organizations were administering their own names and
68 addresses, but had to wait for the NIC to change HOSTS.TXT to
69 make changes visible to the Internet at large. Organizations
70 also wanted some local structure on the name space.
72 - The applications on the Internet were getting more
73 sophisticated and creating a need for general purpose name
77 The result was several ideas about name spaces and their management
78 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
79 common thread was the idea of a hierarchical name space, with the
80 hierarchy roughly corresponding to organizational structure, and names
81 using "." as the character to mark the boundary between hierarchy
82 levels. A design using a distributed database and generalized resources
83 was described in [RFC-882, RFC-883]. Based on experience with several
84 implementations, the system evolved into the scheme described in this
87 The terms "domain" or "domain name" are used in many contexts beyond the
88 DNS described here. Very often, the term domain name is used to refer
89 to a name with structure indicated by dots, but no relation to the DNS.
90 This is particularly true in mail addressing [Quarterman 86].
94 The design goals of the DNS influence its structure. They are:
96 - The primary goal is a consistent name space which will be used
97 for referring to resources. In order to avoid the problems
98 caused by ad hoc encodings, names should not be required to
99 contain network identifiers, addresses, routes, or similar
100 information as part of the name.
102 - The sheer size of the database and frequency of updates
103 suggest that it must be maintained in a distributed manner,
104 with local caching to improve performance. Approaches that
110 RFC 1034 Domain Concepts and Facilities November 1987
113 attempt to collect a consistent copy of the entire database
114 will become more and more expensive and difficult, and hence
115 should be avoided. The same principle holds for the structure
116 of the name space, and in particular mechanisms for creating
117 and deleting names; these should also be distributed.
119 - Where there tradeoffs between the cost of acquiring data, the
120 speed of updates, and the accuracy of caches, the source of
121 the data should control the tradeoff.
123 - The costs of implementing such a facility dictate that it be
124 generally useful, and not restricted to a single application.
125 We should be able to use names to retrieve host addresses,
126 mailbox data, and other as yet undetermined information. All
127 data associated with a name is tagged with a type, and queries
128 can be limited to a single type.
130 - Because we want the name space to be useful in dissimilar
131 networks and applications, we provide the ability to use the
132 same name space with different protocol families or
133 management. For example, host address formats differ between
134 protocols, though all protocols have the notion of address.
135 The DNS tags all data with a class as well as the type, so
136 that we can allow parallel use of different formats for data
139 - We want name server transactions to be independent of the
140 communications system that carries them. Some systems may
141 wish to use datagrams for queries and responses, and only
142 establish virtual circuits for transactions that need the
143 reliability (e.g., database updates, long transactions); other
144 systems will use virtual circuits exclusively.
146 - The system should be useful across a wide spectrum of host
147 capabilities. Both personal computers and large timeshared
148 hosts should be able to use the system, though perhaps in
151 2.3. Assumptions about usage
153 The organization of the domain system derives from some assumptions
154 about the needs and usage patterns of its user community and is designed
155 to avoid many of the the complicated problems found in general purpose
160 - The size of the total database will initially be proportional
166 RFC 1034 Domain Concepts and Facilities November 1987
169 to the number of hosts using the system, but will eventually
170 grow to be proportional to the number of users on those hosts
171 as mailboxes and other information are added to the domain
174 - Most of the data in the system will change very slowly (e.g.,
175 mailbox bindings, host addresses), but that the system should
176 be able to deal with subsets that change more rapidly (on the
177 order of seconds or minutes).
179 - The administrative boundaries used to distribute
180 responsibility for the database will usually correspond to
181 organizations that have one or more hosts. Each organization
182 that has responsibility for a particular set of domains will
183 provide redundant name servers, either on the organization's
184 own hosts or other hosts that the organization arranges to
187 - Clients of the domain system should be able to identify
188 trusted name servers they prefer to use before accepting
189 referrals to name servers outside of this "trusted" set.
191 - Access to information is more critical than instantaneous
192 updates or guarantees of consistency. Hence the update
193 process allows updates to percolate out through the users of
194 the domain system rather than guaranteeing that all copies are
195 simultaneously updated. When updates are unavailable due to
196 network or host failure, the usual course is to believe old
197 information while continuing efforts to update it. The
198 general model is that copies are distributed with timeouts for
199 refreshing. The distributor sets the timeout value and the
200 recipient of the distribution is responsible for performing
201 the refresh. In special situations, very short intervals can
202 be specified, or the owner can prohibit copies.
204 - In any system that has a distributed database, a particular
205 name server may be presented with a query that can only be
206 answered by some other server. The two general approaches to
207 dealing with this problem are "recursive", in which the first
208 server pursues the query for the client at another server, and
209 "iterative", in which the server refers the client to another
210 server and lets the client pursue the query. Both approaches
211 have advantages and disadvantages, but the iterative approach
212 is preferred for the datagram style of access. The domain
213 system requires implementation of the iterative approach, but
214 allows the recursive approach as an option.
222 RFC 1034 Domain Concepts and Facilities November 1987
225 The domain system assumes that all data originates in master files
226 scattered through the hosts that use the domain system. These master
227 files are updated by local system administrators. Master files are text
228 files that are read by a local name server, and hence become available
229 through the name servers to users of the domain system. The user
230 programs access name servers through standard programs called resolvers.
232 The standard format of master files allows them to be exchanged between
233 hosts (via FTP, mail, or some other mechanism); this facility is useful
234 when an organization wants a domain, but doesn't want to support a name
235 server. The organization can maintain the master files locally using a
236 text editor, transfer them to a foreign host which runs a name server,
237 and then arrange with the system administrator of the name server to get
240 Each host's name servers and resolvers are configured by a local system
241 administrator [RFC-1033]. For a name server, this configuration data
242 includes the identity of local master files and instructions on which
243 non-local master files are to be loaded from foreign servers. The name
244 server uses the master files or copies to load its zones. For
245 resolvers, the configuration data identifies the name servers which
246 should be the primary sources of information.
248 The domain system defines procedures for accessing the data and for
249 referrals to other name servers. The domain system also defines
250 procedures for caching retrieved data and for periodic refreshing of
251 data defined by the system administrator.
253 The system administrators provide:
255 - The definition of zone boundaries.
257 - Master files of data.
259 - Updates to master files.
261 - Statements of the refresh policies desired.
263 The domain system provides:
265 - Standard formats for resource data.
267 - Standard methods for querying the database.
269 - Standard methods for name servers to refresh local data from
270 foreign name servers.
278 RFC 1034 Domain Concepts and Facilities November 1987
281 2.4. Elements of the DNS
283 The DNS has three major components:
285 - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
286 specifications for a tree structured name space and data
287 associated with the names. Conceptually, each node and leaf
288 of the domain name space tree names a set of information, and
289 query operations are attempts to extract specific types of
290 information from a particular set. A query names the domain
291 name of interest and describes the type of resource
292 information that is desired. For example, the Internet
293 uses some of its domain names to identify hosts; queries for
294 address resources return Internet host addresses.
296 - NAME SERVERS are server programs which hold information about
297 the domain tree's structure and set information. A name
298 server may cache structure or set information about any part
299 of the domain tree, but in general a particular name server
300 has complete information about a subset of the domain space,
301 and pointers to other name servers that can be used to lead to
302 information from any part of the domain tree. Name servers
303 know the parts of the domain tree for which they have complete
304 information; a name server is said to be an AUTHORITY for
305 these parts of the name space. Authoritative information is
306 organized into units called ZONEs, and these zones can be
307 automatically distributed to the name servers which provide
308 redundant service for the data in a zone.
310 - RESOLVERS are programs that extract information from name
311 servers in response to client requests. Resolvers must be
312 able to access at least one name server and use that name
313 server's information to answer a query directly, or pursue the
314 query using referrals to other name servers. A resolver will
315 typically be a system routine that is directly accessible to
316 user programs; hence no protocol is necessary between the
317 resolver and the user program.
319 These three components roughly correspond to the three layers or views
320 of the domain system:
322 - From the user's point of view, the domain system is accessed
323 through a simple procedure or OS call to a local resolver.
324 The domain space consists of a single tree and the user can
325 request information from any section of the tree.
327 - From the resolver's point of view, the domain system is
328 composed of an unknown number of name servers. Each name
334 RFC 1034 Domain Concepts and Facilities November 1987
337 server has one or more pieces of the whole domain tree's data,
338 but the resolver views each of these databases as essentially
341 - From a name server's point of view, the domain system consists
342 of separate sets of local information called zones. The name
343 server has local copies of some of the zones. The name server
344 must periodically refresh its zones from master copies in
345 local files or foreign name servers. The name server must
346 concurrently process queries that arrive from resolvers.
348 In the interests of performance, implementations may couple these
349 functions. For example, a resolver on the same machine as a name server
350 might share a database consisting of the the zones managed by the name
351 server and the cache managed by the resolver.
353 3. DOMAIN NAME SPACE and RESOURCE RECORDS
355 3.1. Name space specifications and terminology
357 The domain name space is a tree structure. Each node and leaf on the
358 tree corresponds to a resource set (which may be empty). The domain
359 system makes no distinctions between the uses of the interior nodes and
360 leaves, and this memo uses the term "node" to refer to both.
362 Each node has a label, which is zero to 63 octets in length. Brother
363 nodes may not have the same label, although the same label can be used
364 for nodes which are not brothers. One label is reserved, and that is
365 the null (i.e., zero length) label used for the root.
367 The domain name of a node is the list of the labels on the path from the
368 node to the root of the tree. By convention, the labels that compose a
369 domain name are printed or read left to right, from the most specific
370 (lowest, farthest from the root) to the least specific (highest, closest
373 Internally, programs that manipulate domain names should represent them
374 as sequences of labels, where each label is a length octet followed by
375 an octet string. Because all domain names end at the root, which has a
376 null string for a label, these internal representations can use a length
377 byte of zero to terminate a domain name.
379 By convention, domain names can be stored with arbitrary case, but
380 domain name comparisons for all present domain functions are done in a
381 case-insensitive manner, assuming an ASCII character set, and a high
382 order zero bit. This means that you are free to create a node with
383 label "A" or a node with label "a", but not both as brothers; you could
384 refer to either using "a" or "A". When you receive a domain name or
390 RFC 1034 Domain Concepts and Facilities November 1987
393 label, you should preserve its case. The rationale for this choice is
394 that we may someday need to add full binary domain names for new
395 services; existing services would not be changed.
397 When a user needs to type a domain name, the length of each label is
398 omitted and the labels are separated by dots ("."). Since a complete
399 domain name ends with the root label, this leads to a printed form which
400 ends in a dot. We use this property to distinguish between:
402 - a character string which represents a complete domain name
403 (often called "absolute"). For example, "poneria.ISI.EDU."
405 - a character string that represents the starting labels of a
406 domain name which is incomplete, and should be completed by
407 local software using knowledge of the local domain (often
408 called "relative"). For example, "poneria" used in the
411 Relative names are either taken relative to a well known origin, or to a
412 list of domains used as a search list. Relative names appear mostly at
413 the user interface, where their interpretation varies from
414 implementation to implementation, and in master files, where they are
415 relative to a single origin domain name. The most common interpretation
416 uses the root "." as either the single origin or as one of the members
417 of the search list, so a multi-label relative name is often one where
418 the trailing dot has been omitted to save typing.
420 To simplify implementations, the total number of octets that represent a
421 domain name (i.e., the sum of all label octets and label lengths) is
424 A domain is identified by a domain name, and consists of that part of
425 the domain name space that is at or below the domain name which
426 specifies the domain. A domain is a subdomain of another domain if it
427 is contained within that domain. This relationship can be tested by
428 seeing if the subdomain's name ends with the containing domain's name.
429 For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
431 3.2. Administrative guidelines on use
433 As a matter of policy, the DNS technical specifications do not mandate a
434 particular tree structure or rules for selecting labels; its goal is to
435 be as general as possible, so that it can be used to build arbitrary
436 applications. In particular, the system was designed so that the name
437 space did not have to be organized along the lines of network
438 boundaries, name servers, etc. The rationale for this is not that the
439 name space should have no implied semantics, but rather that the choice
440 of implied semantics should be left open to be used for the problem at
446 RFC 1034 Domain Concepts and Facilities November 1987
449 hand, and that different parts of the tree can have different implied
450 semantics. For example, the IN-ADDR.ARPA domain is organized and
451 distributed by network and host address because its role is to translate
452 from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
453 1002] are flat because that is appropriate for that application.
455 However, there are some guidelines that apply to the "normal" parts of
456 the name space used for hosts, mailboxes, etc., that will make the name
457 space more uniform, provide for growth, and minimize problems as
458 software is converted from the older host table. The political
459 decisions about the top levels of the tree originated in RFC-920.
460 Current policy for the top levels is discussed in [RFC-1032]. MILNET
461 conversion issues are covered in [RFC-1031].
463 Lower domains which will eventually be broken into multiple zones should
464 provide branching at the top of the domain so that the eventual
465 decomposition can be done without renaming. Node labels which use
466 special characters, leading digits, etc., are likely to break older
467 software which depends on more restrictive choices.
469 3.3. Technical guidelines on use
471 Before the DNS can be used to hold naming information for some kind of
472 object, two needs must be met:
474 - A convention for mapping between object names and domain
475 names. This describes how information about an object is
478 - RR types and data formats for describing the object.
480 These rules can be quite simple or fairly complex. Very often, the
481 designer must take into account existing formats and plan for upward
482 compatibility for existing usage. Multiple mappings or levels of
483 mapping may be required.
485 For hosts, the mapping depends on the existing syntax for host names
486 which is a subset of the usual text representation for domain names,
487 together with RR formats for describing host addresses, etc. Because we
488 need a reliable inverse mapping from address to host name, a special
489 mapping for addresses into the IN-ADDR.ARPA domain is also defined.
491 For mailboxes, the mapping is slightly more complex. The usual mail
492 address <local-part>@<mail-domain> is mapped into a domain name by
493 converting <local-part> into a single label (regardles of dots it
494 contains), converting <mail-domain> into a domain name using the usual
495 text format for domain names (dots denote label breaks), and
496 concatenating the two to form a single domain name. Thus the mailbox
502 RFC 1034 Domain Concepts and Facilities November 1987
505 HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
506 HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
507 design also must take into account the scheme for mail exchanges [RFC-
510 The typical user is not concerned with defining these rules, but should
511 understand that they usually are the result of numerous compromises
512 between desires for upward compatibility with old usage, interactions
513 between different object definitions, and the inevitable urge to add new
514 features when defining the rules. The way the DNS is used to support
515 some object is often more crucial than the restrictions inherent in the
518 3.4. Example name space
520 The following figure shows a part of the current domain name space, and
521 is used in many examples in this RFC. Note that the tree is a very
522 small subset of the actual name space.
526 +---------------------+------------------+
531 +-----+-----+ | +------+-----+-----+
533 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
535 +--------+------------------+---------------+--------+
542 LCS ACHILLES +--+-----+-----+--------+
544 XX A C VAXA VENERA Mockapetris
546 In this example, the root domain has three immediate subdomains: MIL,
547 EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
548 XX.LCS.MIT.EDU. All of the leaves are also domains.
550 3.5. Preferred name syntax
552 The DNS specifications attempt to be as general as possible in the rules
556 Mockapetris [Page 10]
558 RFC 1034 Domain Concepts and Facilities November 1987
561 for constructing domain names. The idea is that the name of any
562 existing object can be expressed as a domain name with minimal changes.
563 However, when assigning a domain name for an object, the prudent user
564 will select a name which satisfies both the rules of the domain system
565 and any existing rules for the object, whether these rules are published
566 or implied by existing programs.
568 For example, when naming a mail domain, the user should satisfy both the
569 rules of this memo and those in RFC-822. When creating a new host name,
570 the old rules for HOSTS.TXT should be followed. This avoids problems
571 when old software is converted to use domain names.
573 The following syntax will result in fewer problems with many
574 applications that use domain names (e.g., mail, TELNET).
576 <domain> ::= <subdomain> | " "
578 <subdomain> ::= <label> | <subdomain> "." <label>
580 <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
582 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
584 <let-dig-hyp> ::= <let-dig> | "-"
586 <let-dig> ::= <letter> | <digit>
588 <letter> ::= any one of the 52 alphabetic characters A through Z in
589 upper case and a through z in lower case
591 <digit> ::= any one of the ten digits 0 through 9
593 Note that while upper and lower case letters are allowed in domain
594 names, no significance is attached to the case. That is, two names with
595 the same spelling but different case are to be treated as if identical.
597 The labels must follow the rules for ARPANET host names. They must
598 start with a letter, end with a letter or digit, and have as interior
599 characters only letters, digits, and hyphen. There are also some
600 restrictions on the length. Labels must be 63 characters or less.
602 For example, the following strings identify hosts in the Internet:
604 A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
606 3.6. Resource Records
608 A domain name identifies a node. Each node has a set of resource
612 Mockapetris [Page 11]
614 RFC 1034 Domain Concepts and Facilities November 1987
617 information, which may be empty. The set of resource information
618 associated with a particular name is composed of separate resource
619 records (RRs). The order of RRs in a set is not significant, and need
620 not be preserved by name servers, resolvers, or other parts of the DNS.
622 When we talk about a specific RR, we assume it has the following:
624 owner which is the domain name where the RR is found.
626 type which is an encoded 16 bit value that specifies the type
627 of the resource in this resource record. Types refer to
630 This memo uses the following types:
634 CNAME identifies the canonical name of an
637 HINFO identifies the CPU and OS used by a host
639 MX identifies a mail exchange for the
640 domain. See [RFC-974 for details.
643 the authoritative name server for the domain
646 a pointer to another part of the domain name space
649 identifies the start of a zone of authority]
651 class which is an encoded 16 bit value which identifies a
652 protocol family or instance of a protocol.
654 This memo uses the following classes:
656 IN the Internet system
660 TTL which is the time to live of the RR. This field is a 32
661 bit integer in units of seconds, an is primarily used by
662 resolvers when they cache RRs. The TTL describes how
663 long a RR can be cached before it should be discarded.
668 Mockapetris [Page 12]
670 RFC 1034 Domain Concepts and Facilities November 1987
673 RDATA which is the type and sometimes class dependent data
674 which describes the resource:
676 A For the IN class, a 32 bit IP address
678 For the CH class, a domain name followed
679 by a 16 bit octal Chaos address.
683 MX a 16 bit preference value (lower is
684 better) followed by a host name willing
685 to act as a mail exchange for the owner
694 The owner name is often implicit, rather than forming an integral part
695 of the RR. For example, many name servers internally form tree or hash
696 structures for the name space, and chain RRs off nodes. The remaining
697 RR parts are the fixed header (type, class, TTL) which is consistent for
698 all RRs, and a variable part (RDATA) that fits the needs of the resource
701 The meaning of the TTL field is a time limit on how long an RR can be
702 kept in a cache. This limit does not apply to authoritative data in
703 zones; it is also timed out, but by the refreshing policies for the
704 zone. The TTL is assigned by the administrator for the zone where the
705 data originates. While short TTLs can be used to minimize caching, and
706 a zero TTL prohibits caching, the realities of Internet performance
707 suggest that these times should be on the order of days for the typical
708 host. If a change can be anticipated, the TTL can be reduced prior to
709 the change to minimize inconsistency during the change, and then
710 increased back to its former value following the change.
712 The data in the RDATA section of RRs is carried as a combination of
713 binary strings and domain names. The domain names are frequently used
714 as "pointers" to other data in the DNS.
716 3.6.1. Textual expression of RRs
718 RRs are represented in binary form in the packets of the DNS protocol,
719 and are usually represented in highly encoded form when stored in a name
720 server or resolver. In this memo, we adopt a style similar to that used
724 Mockapetris [Page 13]
726 RFC 1034 Domain Concepts and Facilities November 1987
729 in master files in order to show the contents of RRs. In this format,
730 most RRs are shown on a single line, although continuation lines are
731 possible using parentheses.
733 The start of the line gives the owner of the RR. If a line begins with
734 a blank, then the owner is assumed to be the same as that of the
735 previous RR. Blank lines are often included for readability.
737 Following the owner, we list the TTL, type, and class of the RR. Class
738 and type use the mnemonics defined above, and TTL is an integer before
739 the type field. In order to avoid ambiguity in parsing, type and class
740 mnemonics are disjoint, TTLs are integers, and the type mnemonic is
741 always last. The IN class and TTL values are often omitted from examples
742 in the interests of clarity.
744 The resource data or RDATA section of the RR are given using knowledge
745 of the typical representation for the data.
747 For example, we might show the RRs carried in a message as:
749 ISI.EDU. MX 10 VENERA.ISI.EDU.
751 VENERA.ISI.EDU. A 128.9.0.32
753 VAXA.ISI.EDU. A 10.2.0.27
756 The MX RRs have an RDATA section which consists of a 16 bit number
757 followed by a domain name. The address RRs use a standard IP address
758 format to contain a 32 bit internet address.
760 This example shows six RRs, with two RRs at each of three domain names.
762 Similarly we might see:
764 XX.LCS.MIT.EDU. IN A 10.0.0.44
767 This example shows two addresses for XX.LCS.MIT.EDU, each of a different
770 3.6.2. Aliases and canonical names
772 In existing systems, hosts and other resources often have several names
773 that identify the same resource. For example, the names C.ISI.EDU and
774 USC-ISIC.ARPA both identify the same host. Similarly, in the case of
775 mailboxes, many organizations provide many names that actually go to the
776 same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
780 Mockapetris [Page 14]
782 RFC 1034 Domain Concepts and Facilities November 1987
785 and PVM@ISI.EDU all go to the same mailbox (although the mechanism
786 behind this is somewhat complicated).
788 Most of these systems have a notion that one of the equivalent set of
789 names is the canonical or primary name and all others are aliases.
791 The domain system provides such a feature using the canonical name
792 (CNAME) RR. A CNAME RR identifies its owner name as an alias, and
793 specifies the corresponding canonical name in the RDATA section of the
794 RR. If a CNAME RR is present at a node, no other data should be
795 present; this ensures that the data for a canonical name and its aliases
796 cannot be different. This rule also insures that a cached CNAME can be
797 used without checking with an authoritative server for other RR types.
799 CNAME RRs cause special action in DNS software. When a name server
800 fails to find a desired RR in the resource set associated with the
801 domain name, it checks to see if the resource set consists of a CNAME
802 record with a matching class. If so, the name server includes the CNAME
803 record in the response and restarts the query at the domain name
804 specified in the data field of the CNAME record. The one exception to
805 this rule is that queries which match the CNAME type are not restarted.
807 For example, suppose a name server was processing a query with for USC-
808 ISIC.ARPA, asking for type A information, and had the following resource
811 USC-ISIC.ARPA IN CNAME C.ISI.EDU
813 C.ISI.EDU IN A 10.0.0.52
815 Both of these RRs would be returned in the response to the type A query,
816 while a type CNAME or * query should return just the CNAME.
818 Domain names in RRs which point at another name should always point at
819 the primary name and not the alias. This avoids extra indirections in
820 accessing information. For example, the address to name RR for the
821 above host should be:
823 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
825 rather than pointing at USC-ISIC.ARPA. Of course, by the robustness
826 principle, domain software should not fail when presented with CNAME
827 chains or loops; CNAME chains should be followed and CNAME loops
828 signalled as an error.
832 Queries are messages which may be sent to a name server to provoke a
836 Mockapetris [Page 15]
838 RFC 1034 Domain Concepts and Facilities November 1987
841 response. In the Internet, queries are carried in UDP datagrams or over
842 TCP connections. The response by the name server either answers the
843 question posed in the query, refers the requester to another set of name
844 servers, or signals some error condition.
846 In general, the user does not generate queries directly, but instead
847 makes a request to a resolver which in turn sends one or more queries to
848 name servers and deals with the error conditions and referrals that may
849 result. Of course, the possible questions which can be asked in a query
850 does shape the kind of service a resolver can provide.
852 DNS queries and responses are carried in a standard message format. The
853 message format has a header containing a number of fixed fields which
854 are always present, and four sections which carry query parameters and
857 The most important field in the header is a four bit field called an
858 opcode which separates different queries. Of the possible 16 values,
859 one (standard query) is part of the official protocol, two (inverse
860 query and status query) are options, one (completion) is obsolete, and
861 the rest are unassigned.
863 The four sections are:
865 Question Carries the query name and other query parameters.
867 Answer Carries RRs which directly answer the query.
869 Authority Carries RRs which describe other authoritative servers.
870 May optionally carry the SOA RR for the authoritative
871 data in the answer section.
873 Additional Carries RRs which may be helpful in using the RRs in the
876 Note that the content, but not the format, of these sections varies with
879 3.7.1. Standard queries
881 A standard query specifies a target domain name (QNAME), query type
882 (QTYPE), and query class (QCLASS) and asks for RRs which match. This
883 type of query makes up such a vast majority of DNS queries that we use
884 the term "query" to mean standard query unless otherwise specified. The
885 QTYPE and QCLASS fields are each 16 bits long, and are a superset of
886 defined types and classes.
892 Mockapetris [Page 16]
894 RFC 1034 Domain Concepts and Facilities November 1987
897 The QTYPE field may contain:
899 <any type> matches just that type. (e.g., A, PTR).
901 AXFR special zone transfer QTYPE.
903 MAILB matches all mail box related RRs (e.g. MB and MG).
905 * matches all RR types.
907 The QCLASS field may contain:
909 <any class> matches just that class (e.g., IN, CH).
911 * matches aLL RR classes.
913 Using the query domain name, QTYPE, and QCLASS, the name server looks
914 for matching RRs. In addition to relevant records, the name server may
915 return RRs that point toward a name server that has the desired
916 information or RRs that are expected to be useful in interpreting the
917 relevant RRs. For example, a name server that doesn't have the
918 requested information may know a name server that does; a name server
919 that returns a domain name in a relevant RR may also return the RR that
920 binds that domain name to an address.
922 For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
923 ask the resolver for mail information about ISI.EDU, resulting in a
924 query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
927 ISI.EDU. MX 10 VENERA.ISI.EDU.
930 while the additional section might be:
932 VAXA.ISI.EDU. A 10.2.0.27
934 VENERA.ISI.EDU. A 10.1.0.52
937 Because the server assumes that if the requester wants mail exchange
938 information, it will probably want the addresses of the mail exchanges
941 Note that the QCLASS=* construct requires special interpretation
942 regarding authority. Since a particular name server may not know all of
943 the classes available in the domain system, it can never know if it is
944 authoritative for all classes. Hence responses to QCLASS=* queries can
948 Mockapetris [Page 17]
950 RFC 1034 Domain Concepts and Facilities November 1987
953 never be authoritative.
955 3.7.2. Inverse queries (Optional)
957 Name servers may also support inverse queries that map a particular
958 resource to a domain name or domain names that have that resource. For
959 example, while a standard query might map a domain name to a SOA RR, the
960 corresponding inverse query might map the SOA RR back to the domain
963 Implementation of this service is optional in a name server, but all
964 name servers must at least be able to understand an inverse query
965 message and return a not-implemented error response.
967 The domain system cannot guarantee the completeness or uniqueness of
968 inverse queries because the domain system is organized by domain name
969 rather than by host address or any other resource type. Inverse queries
970 are primarily useful for debugging and database maintenance activities.
972 Inverse queries may not return the proper TTL, and do not indicate cases
973 where the identified RR is one of a set (for example, one address for a
974 host having multiple addresses). Therefore, the RRs returned in inverse
975 queries should never be cached.
977 Inverse queries are NOT an acceptable method for mapping host addresses
978 to host names; use the IN-ADDR.ARPA domain instead.
980 A detailed discussion of inverse queries is contained in [RFC-1035].
982 3.8. Status queries (Experimental)
986 3.9. Completion queries (Obsolete)
988 The optional completion services described in RFCs 882 and 883 have been
989 deleted. Redesigned services may become available in the future, or the
990 opcodes may be reclaimed for other use.
996 Name servers are the repositories of information that make up the domain
997 database. The database is divided up into sections called zones, which
998 are distributed among the name servers. While name servers can have
999 several optional functions and sources of data, the essential task of a
1000 name server is to answer queries using data in its zones. By design,
1004 Mockapetris [Page 18]
1006 RFC 1034 Domain Concepts and Facilities November 1987
1009 name servers can answer queries in a simple manner; the response can
1010 always be generated using only local data, and either contains the
1011 answer to the question or a referral to other name servers "closer" to
1012 the desired information.
1014 A given zone will be available from several name servers to insure its
1015 availability in spite of host or communication link failure. By
1016 administrative fiat, we require every zone to be available on at least
1017 two servers, and many zones have more redundancy than that.
1019 A given name server will typically support one or more zones, but this
1020 gives it authoritative information about only a small section of the
1021 domain tree. It may also have some cached non-authoritative data about
1022 other parts of the tree. The name server marks its responses to queries
1023 so that the requester can tell whether the response comes from
1024 authoritative data or not.
1026 4.2. How the database is divided into zones
1028 The domain database is partitioned in two ways: by class, and by "cuts"
1029 made in the name space between nodes.
1031 The class partition is simple. The database for any class is organized,
1032 delegated, and maintained separately from all other classes. Since, by
1033 convention, the name spaces are the same for all classes, the separate
1034 classes can be thought of as an array of parallel namespace trees. Note
1035 that the data attached to nodes will be different for these different
1036 parallel classes. The most common reasons for creating a new class are
1037 the necessity for a new data format for existing types or a desire for a
1038 separately managed version of the existing name space.
1040 Within a class, "cuts" in the name space can be made between any two
1041 adjacent nodes. After all cuts are made, each group of connected name
1042 space is a separate zone. The zone is said to be authoritative for all
1043 names in the connected region. Note that the "cuts" in the name space
1044 may be in different places for different classes, the name servers may
1047 These rules mean that every zone has at least one node, and hence domain
1048 name, for which it is authoritative, and all of the nodes in a
1049 particular zone are connected. Given, the tree structure, every zone
1050 has a highest node which is closer to the root than any other node in
1051 the zone. The name of this node is often used to identify the zone.
1053 It would be possible, though not particularly useful, to partition the
1054 name space so that each domain name was in a separate zone or so that
1055 all nodes were in a single zone. Instead, the database is partitioned
1056 at points where a particular organization wants to take over control of
1060 Mockapetris [Page 19]
1062 RFC 1034 Domain Concepts and Facilities November 1987
1065 a subtree. Once an organization controls its own zone it can
1066 unilaterally change the data in the zone, grow new tree sections
1067 connected to the zone, delete existing nodes, or delegate new subzones
1070 If the organization has substructure, it may want to make further
1071 internal partitions to achieve nested delegations of name space control.
1072 In some cases, such divisions are made purely to make database
1073 maintenance more convenient.
1075 4.2.1. Technical considerations
1077 The data that describes a zone has four major parts:
1079 - Authoritative data for all nodes within the zone.
1081 - Data that defines the top node of the zone (can be thought of
1082 as part of the authoritative data).
1084 - Data that describes delegated subzones, i.e., cuts around the
1087 - Data that allows access to name servers for subzones
1088 (sometimes called "glue" data).
1090 All of this data is expressed in the form of RRs, so a zone can be
1091 completely described in terms of a set of RRs. Whole zones can be
1092 transferred between name servers by transferring the RRs, either carried
1093 in a series of messages or by FTPing a master file which is a textual
1096 The authoritative data for a zone is simply all of the RRs attached to
1097 all of the nodes from the top node of the zone down to leaf nodes or
1098 nodes above cuts around the bottom edge of the zone.
1100 Though logically part of the authoritative data, the RRs that describe
1101 the top node of the zone are especially important to the zone's
1102 management. These RRs are of two types: name server RRs that list, one
1103 per RR, all of the servers for the zone, and a single SOA RR that
1104 describes zone management parameters.
1106 The RRs that describe cuts around the bottom of the zone are NS RRs that
1107 name the servers for the subzones. Since the cuts are between nodes,
1108 these RRs are NOT part of the authoritative data of the zone, and should
1109 be exactly the same as the corresponding RRs in the top node of the
1110 subzone. Since name servers are always associated with zone boundaries,
1111 NS RRs are only found at nodes which are the top node of some zone. In
1112 the data that makes up a zone, NS RRs are found at the top node of the
1116 Mockapetris [Page 20]
1118 RFC 1034 Domain Concepts and Facilities November 1987
1121 zone (and are authoritative) and at cuts around the bottom of the zone
1122 (where they are not authoritative), but never in between.
1124 One of the goals of the zone structure is that any zone have all the
1125 data required to set up communications with the name servers for any
1126 subzones. That is, parent zones have all the information needed to
1127 access servers for their children zones. The NS RRs that name the
1128 servers for subzones are often not enough for this task since they name
1129 the servers, but do not give their addresses. In particular, if the
1130 name of the name server is itself in the subzone, we could be faced with
1131 the situation where the NS RRs tell us that in order to learn a name
1132 server's address, we should contact the server using the address we wish
1133 to learn. To fix this problem, a zone contains "glue" RRs which are not
1134 part of the authoritative data, and are address RRs for the servers.
1135 These RRs are only necessary if the name server's name is "below" the
1136 cut, and are only used as part of a referral response.
1138 4.2.2. Administrative considerations
1140 When some organization wants to control its own domain, the first step
1141 is to identify the proper parent zone, and get the parent zone's owners
1142 to agree to the delegation of control. While there are no particular
1143 technical constraints dealing with where in the tree this can be done,
1144 there are some administrative groupings discussed in [RFC-1032] which
1145 deal with top level organization, and middle level zones are free to
1146 create their own rules. For example, one university might choose to use
1147 a single zone, while another might choose to organize by subzones
1148 dedicated to individual departments or schools. [RFC-1033] catalogs
1149 available DNS software an discusses administration procedures.
1151 Once the proper name for the new subzone is selected, the new owners
1152 should be required to demonstrate redundant name server support. Note
1153 that there is no requirement that the servers for a zone reside in a
1154 host which has a name in that domain. In many cases, a zone will be
1155 more accessible to the internet at large if its servers are widely
1156 distributed rather than being within the physical facilities controlled
1157 by the same organization that manages the zone. For example, in the
1158 current DNS, one of the name servers for the United Kingdom, or UK
1159 domain, is found in the US. This allows US hosts to get UK data without
1160 using limited transatlantic bandwidth.
1162 As the last installation step, the delegation NS RRs and glue RRs
1163 necessary to make the delegation effective should be added to the parent
1164 zone. The administrators of both zones should insure that the NS and
1165 glue RRs which mark both sides of the cut are consistent and remain so.
1167 4.3. Name server internals
1172 Mockapetris [Page 21]
1174 RFC 1034 Domain Concepts and Facilities November 1987
1177 4.3.1. Queries and responses
1179 The principal activity of name servers is to answer standard queries.
1180 Both the query and its response are carried in a standard message format
1181 which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
1182 and QNAME, which describe the types and classes of desired information
1183 and the name of interest.
1185 The way that the name server answers the query depends upon whether it
1186 is operating in recursive mode or not:
1188 - The simplest mode for the server is non-recursive, since it
1189 can answer queries using only local information: the response
1190 contains an error, the answer, or a referral to some other
1191 server "closer" to the answer. All name servers must
1192 implement non-recursive queries.
1194 - The simplest mode for the client is recursive, since in this
1195 mode the name server acts in the role of a resolver and
1196 returns either an error or the answer, but never referrals.
1197 This service is optional in a name server, and the name server
1198 may also choose to restrict the clients which can use
1201 Recursive service is helpful in several situations:
1203 - a relatively simple requester that lacks the ability to use
1204 anything other than a direct answer to the question.
1206 - a request that needs to cross protocol or other boundaries and
1207 can be sent to a server which can act as intermediary.
1209 - a network where we want to concentrate the cache rather than
1210 having a separate cache for each client.
1212 Non-recursive service is appropriate if the requester is capable of
1213 pursuing referrals and interested in information which will aid future
1216 The use of recursive mode is limited to cases where both the client and
1217 the name server agree to its use. The agreement is negotiated through
1218 the use of two bits in query and response messages:
1220 - The recursion available, or RA bit, is set or cleared by a
1221 name server in all responses. The bit is true if the name
1222 server is willing to provide recursive service for the client,
1223 regardless of whether the client requested recursive service.
1224 That is, RA signals availability rather than use.
1228 Mockapetris [Page 22]
1230 RFC 1034 Domain Concepts and Facilities November 1987
1233 - Queries contain a bit called recursion desired or RD. This
1234 bit specifies specifies whether the requester wants recursive
1235 service for this query. Clients may request recursive service
1236 from any name server, though they should depend upon receiving
1237 it only from servers which have previously sent an RA, or
1238 servers which have agreed to provide service through private
1239 agreement or some other means outside of the DNS protocol.
1241 The recursive mode occurs when a query with RD set arrives at a server
1242 which is willing to provide recursive service; the client can verify
1243 that recursive mode was used by checking that both RA and RD are set in
1244 the reply. Note that the name server should never perform recursive
1245 service unless asked via RD, since this interferes with trouble shooting
1246 of name servers and their databases.
1248 If recursive service is requested and available, the recursive response
1249 to a query will be one of the following:
1251 - The answer to the query, possibly preface by one or more CNAME
1252 RRs that specify aliases encountered on the way to an answer.
1254 - A name error indicating that the name does not exist. This
1255 may include CNAME RRs that indicate that the original query
1256 name was an alias for a name which does not exist.
1258 - A temporary error indication.
1260 If recursive service is not requested or is not available, the non-
1261 recursive response will be one of the following:
1263 - An authoritative name error indicating that the name does not
1266 - A temporary error indication.
1268 - Some combination of:
1270 RRs that answer the question, together with an indication
1271 whether the data comes from a zone or is cached.
1273 A referral to name servers which have zones which are closer
1274 ancestors to the name than the server sending the reply.
1276 - RRs that the name server thinks will prove useful to the
1284 Mockapetris [Page 23]
1286 RFC 1034 Domain Concepts and Facilities November 1987
1291 The actual algorithm used by the name server will depend on the local OS
1292 and data structures used to store RRs. The following algorithm assumes
1293 that the RRs are organized in several tree structures, one for each
1294 zone, and another for the cache:
1296 1. Set or clear the value of recursion available in the response
1297 depending on whether the name server is willing to provide
1298 recursive service. If recursive service is available and
1299 requested via the RD bit in the query, go to step 5,
1302 2. Search the available zones for the zone which is the nearest
1303 ancestor to QNAME. If such a zone is found, go to step 3,
1306 3. Start matching down, label by label, in the zone. The
1307 matching process can terminate several ways:
1309 a. If the whole of QNAME is matched, we have found the
1312 If the data at the node is a CNAME, and QTYPE doesn't
1313 match CNAME, copy the CNAME RR into the answer section
1314 of the response, change QNAME to the canonical name in
1315 the CNAME RR, and go back to step 1.
1317 Otherwise, copy all RRs which match QTYPE into the
1318 answer section and go to step 6.
1320 b. If a match would take us out of the authoritative data,
1321 we have a referral. This happens when we encounter a
1322 node with NS RRs marking cuts along the bottom of a
1325 Copy the NS RRs for the subzone into the authority
1326 section of the reply. Put whatever addresses are
1327 available into the additional section, using glue RRs
1328 if the addresses are not available from authoritative
1329 data or the cache. Go to step 4.
1331 c. If at some label, a match is impossible (i.e., the
1332 corresponding label does not exist), look to see if a
1333 the "*" label exists.
1335 If the "*" label does not exist, check whether the name
1336 we are looking for is the original QNAME in the query
1340 Mockapetris [Page 24]
1342 RFC 1034 Domain Concepts and Facilities November 1987
1345 or a name we have followed due to a CNAME. If the name
1346 is original, set an authoritative name error in the
1347 response and exit. Otherwise just exit.
1349 If the "*" label does exist, match RRs at that node
1350 against QTYPE. If any match, copy them into the answer
1351 section, but set the owner of the RR to be QNAME, and
1352 not the node with the "*" label. Go to step 6.
1354 4. Start matching down in the cache. If QNAME is found in the
1355 cache, copy all RRs attached to it that match QTYPE into the
1356 answer section. If there was no delegation from
1357 authoritative data, look for the best one from the cache, and
1358 put it in the authority section. Go to step 6.
1360 5. Using the local resolver or a copy of its algorithm (see
1361 resolver section of this memo) to answer the query. Store
1362 the results, including any intermediate CNAMEs, in the answer
1363 section of the response.
1365 6. Using local data only, attempt to add other RRs which may be
1366 useful to the additional section of the query. Exit.
1370 In the previous algorithm, special treatment was given to RRs with owner
1371 names starting with the label "*". Such RRs are called wildcards.
1372 Wildcard RRs can be thought of as instructions for synthesizing RRs.
1373 When the appropriate conditions are met, the name server creates RRs
1374 with an owner name equal to the query name and contents taken from the
1377 This facility is most often used to create a zone which will be used to
1378 forward mail from the Internet to some other mail system. The general
1379 idea is that any name in that zone which is presented to server in a
1380 query will be assumed to exist, with certain properties, unless explicit
1381 evidence exists to the contrary. Note that the use of the term zone
1382 here, instead of domain, is intentional; such defaults do not propagate
1383 across zone boundaries, although a subzone may choose to achieve that
1384 appearance by setting up similar defaults.
1386 The contents of the wildcard RRs follows the usual rules and formats for
1387 RRs. The wildcards in the zone have an owner name that controls the
1388 query names they will match. The owner name of the wildcard RRs is of
1389 the form "*.<anydomain>", where <anydomain> is any domain name.
1390 <anydomain> should not contain other * labels, and should be in the
1391 authoritative data of the zone. The wildcards potentially apply to
1392 descendants of <anydomain>, but not to <anydomain> itself. Another way
1396 Mockapetris [Page 25]
1398 RFC 1034 Domain Concepts and Facilities November 1987
1401 to look at this is that the "*" label always matches at least one whole
1402 label and sometimes more, but always whole labels.
1404 Wildcard RRs do not apply:
1406 - When the query is in another zone. That is, delegation cancels
1407 the wildcard defaults.
1409 - When the query name or a name between the wildcard domain and
1410 the query name is know to exist. For example, if a wildcard
1411 RR has an owner name of "*.X", and the zone also contains RRs
1412 attached to B.X, the wildcards would apply to queries for name
1413 Z.X (presuming there is no explicit information for Z.X), but
1414 not to B.X, A.B.X, or X.
1416 A * label appearing in a query name has no special effect, but can be
1417 used to test for wildcards in an authoritative zone; such a query is the
1418 only way to get a response containing RRs with an owner name with * in
1419 it. The result of such a query should not be cached.
1421 Note that the contents of the wildcard RRs are not modified when used to
1424 To illustrate the use of wildcard RRs, suppose a large company with a
1425 large, non-IP/TCP, network wanted to create a mail gateway. If the
1426 company was called X.COM, and IP/TCP capable gateway machine was called
1427 A.X.COM, the following RRs might be entered into the COM zone:
1431 *.X.COM MX 10 A.X.COM
1434 A.X.COM MX 10 A.X.COM
1436 *.A.X.COM MX 10 A.X.COM
1438 This would cause any MX query for any domain name ending in X.COM to
1439 return an MX RR pointing at A.X.COM. Two wildcard RRs are required
1440 since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
1441 subtree by the explicit data for A.X.COM. Note also that the explicit
1442 MX data at X.COM and A.X.COM is required, and that none of the RRs above
1443 would match a query name of XX.COM.
1445 4.3.4. Negative response caching (Optional)
1447 The DNS provides an optional service which allows name servers to
1448 distribute, and resolvers to cache, negative results with TTLs. For
1452 Mockapetris [Page 26]
1454 RFC 1034 Domain Concepts and Facilities November 1987
1457 example, a name server can distribute a TTL along with a name error
1458 indication, and a resolver receiving such information is allowed to
1459 assume that the name does not exist during the TTL period without
1460 consulting authoritative data. Similarly, a resolver can make a query
1461 with a QTYPE which matches multiple types, and cache the fact that some
1462 of the types are not present.
1464 This feature can be particularly important in a system which implements
1465 naming shorthands that use search lists beacuse a popular shorthand,
1466 which happens to require a suffix toward the end of the search list,
1467 will generate multiple name errors whenever it is used.
1469 The method is that a name server may add an SOA RR to the additional
1470 section of a response when that response is authoritative. The SOA must
1471 be that of the zone which was the source of the authoritative data in
1472 the answer section, or name error if applicable. The MINIMUM field of
1473 the SOA controls the length of time that the negative result may be
1476 Note that in some circumstances, the answer section may contain multiple
1477 owner names. In this case, the SOA mechanism should only be used for
1478 the data which matches QNAME, which is the only authoritative data in
1481 Name servers and resolvers should never attempt to add SOAs to the
1482 additional section of a non-authoritative response, or attempt to infer
1483 results which are not directly stated in an authoritative response.
1484 There are several reasons for this, including: cached information isn't
1485 usually enough to match up RRs and their zone names, SOA RRs may be
1486 cached due to direct SOA queries, and name servers are not required to
1487 output the SOAs in the authority section.
1489 This feature is optional, although a refined version is expected to
1490 become part of the standard protocol in the future. Name servers are
1491 not required to add the SOA RRs in all authoritative responses, nor are
1492 resolvers required to cache negative results. Both are recommended.
1493 All resolvers and recursive name servers are required to at least be
1494 able to ignore the SOA RR when it is present in a response.
1496 Some experiments have also been proposed which will use this feature.
1497 The idea is that if cached data is known to come from a particular zone,
1498 and if an authoritative copy of the zone's SOA is obtained, and if the
1499 zone's SERIAL has not changed since the data was cached, then the TTL of
1500 the cached data can be reset to the zone MINIMUM value if it is smaller.
1501 This usage is mentioned for planning purposes only, and is not
1508 Mockapetris [Page 27]
1510 RFC 1034 Domain Concepts and Facilities November 1987
1513 4.3.5. Zone maintenance and transfers
1515 Part of the job of a zone administrator is to maintain the zones at all
1516 of the name servers which are authoritative for the zone. When the
1517 inevitable changes are made, they must be distributed to all of the name
1518 servers. While this distribution can be accomplished using FTP or some
1519 other ad hoc procedure, the preferred method is the zone transfer part
1520 of the DNS protocol.
1522 The general model of automatic zone transfer or refreshing is that one
1523 of the name servers is the master or primary for the zone. Changes are
1524 coordinated at the primary, typically by editing a master file for the
1525 zone. After editing, the administrator signals the master server to
1526 load the new zone. The other non-master or secondary servers for the
1527 zone periodically check for changes (at a selectable interval) and
1528 obtain new zone copies when changes have been made.
1530 To detect changes, secondaries just check the SERIAL field of the SOA
1531 for the zone. In addition to whatever other changes are made, the
1532 SERIAL field in the SOA of the zone is always advanced whenever any
1533 change is made to the zone. The advancing can be a simple increment, or
1534 could be based on the write date and time of the master file, etc. The
1535 purpose is to make it possible to determine which of two copies of a
1536 zone is more recent by comparing serial numbers. Serial number advances
1537 and comparisons use sequence space arithmetic, so there is a theoretic
1538 limit on how fast a zone can be updated, basically that old copies must
1539 die out before the serial number covers half of its 32 bit range. In
1540 practice, the only concern is that the compare operation deals properly
1541 with comparisons around the boundary between the most positive and most
1542 negative 32 bit numbers.
1544 The periodic polling of the secondary servers is controlled by
1545 parameters in the SOA RR for the zone, which set the minimum acceptable
1546 polling intervals. The parameters are called REFRESH, RETRY, and
1547 EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
1548 waits REFRESH seconds before checking with the primary for a new serial.
1549 If this check cannot be completed, new checks are started every RETRY
1550 seconds. The check is a simple query to the primary for the SOA RR of
1551 the zone. If the serial field in the secondary's zone copy is equal to
1552 the serial returned by the primary, then no changes have occurred, and
1553 the REFRESH interval wait is restarted. If the secondary finds it
1554 impossible to perform a serial check for the EXPIRE interval, it must
1555 assume that its copy of the zone is obsolete an discard it.
1557 When the poll shows that the zone has changed, then the secondary server
1558 must request a zone transfer via an AXFR request for the zone. The AXFR
1559 may cause an error, such as refused, but normally is answered by a
1560 sequence of response messages. The first and last messages must contain
1564 Mockapetris [Page 28]
1566 RFC 1034 Domain Concepts and Facilities November 1987
1569 the data for the top authoritative node of the zone. Intermediate
1570 messages carry all of the other RRs from the zone, including both
1571 authoritative and non-authoritative RRs. The stream of messages allows
1572 the secondary to construct a copy of the zone. Because accuracy is
1573 essential, TCP or some other reliable protocol must be used for AXFR
1576 Each secondary server is required to perform the following operations
1577 against the master, but may also optionally perform these operations
1578 against other secondary servers. This strategy can improve the transfer
1579 process when the primary is unavailable due to host downtime or network
1580 problems, or when a secondary server has better network access to an
1581 "intermediate" secondary than to the primary.
1587 Resolvers are programs that interface user programs to domain name
1588 servers. In the simplest case, a resolver receives a request from a
1589 user program (e.g., mail programs, TELNET, FTP) in the form of a
1590 subroutine call, system call etc., and returns the desired information
1591 in a form compatible with the local host's data formats.
1593 The resolver is located on the same machine as the program that requests
1594 the resolver's services, but it may need to consult name servers on
1595 other hosts. Because a resolver may need to consult several name
1596 servers, or may have the requested information in a local cache, the
1597 amount of time that a resolver will take to complete can vary quite a
1598 bit, from milliseconds to several seconds.
1600 A very important goal of the resolver is to eliminate network delay and
1601 name server load from most requests by answering them from its cache of
1602 prior results. It follows that caches which are shared by multiple
1603 processes, users, machines, etc., are more efficient than non-shared
1606 5.2. Client-resolver interface
1608 5.2.1. Typical functions
1610 The client interface to the resolver is influenced by the local host's
1611 conventions, but the typical resolver-client interface has three
1614 1. Host name to host address translation.
1616 This function is often defined to mimic a previous HOSTS.TXT
1620 Mockapetris [Page 29]
1622 RFC 1034 Domain Concepts and Facilities November 1987
1625 based function. Given a character string, the caller wants
1626 one or more 32 bit IP addresses. Under the DNS, it
1627 translates into a request for type A RRs. Since the DNS does
1628 not preserve the order of RRs, this function may choose to
1629 sort the returned addresses or select the "best" address if
1630 the service returns only one choice to the client. Note that
1631 a multiple address return is recommended, but a single
1632 address may be the only way to emulate prior HOSTS.TXT
1635 2. Host address to host name translation
1637 This function will often follow the form of previous
1638 functions. Given a 32 bit IP address, the caller wants a
1639 character string. The octets of the IP address are reversed,
1640 used as name components, and suffixed with "IN-ADDR.ARPA". A
1641 type PTR query is used to get the RR with the primary name of
1642 the host. For example, a request for the host name
1643 corresponding to IP address 1.2.3.4 looks for PTR RRs for
1644 domain name "4.3.2.1.IN-ADDR.ARPA".
1646 3. General lookup function
1648 This function retrieves arbitrary information from the DNS,
1649 and has no counterpart in previous systems. The caller
1650 supplies a QNAME, QTYPE, and QCLASS, and wants all of the
1651 matching RRs. This function will often use the DNS format
1652 for all RR data instead of the local host's, and returns all
1653 RR content (e.g., TTL) instead of a processed form with local
1654 quoting conventions.
1656 When the resolver performs the indicated function, it usually has one of
1657 the following results to pass back to the client:
1659 - One or more RRs giving the requested data.
1661 In this case the resolver returns the answer in the
1664 - A name error (NE).
1666 This happens when the referenced name does not exist. For
1667 example, a user may have mistyped a host name.
1669 - A data not found error.
1671 This happens when the referenced name exists, but data of the
1672 appropriate type does not. For example, a host address
1676 Mockapetris [Page 30]
1678 RFC 1034 Domain Concepts and Facilities November 1987
1681 function applied to a mailbox name would return this error
1682 since the name exists, but no address RR is present.
1684 It is important to note that the functions for translating between host
1685 names and addresses may combine the "name error" and "data not found"
1686 error conditions into a single type of error return, but the general
1687 function should not. One reason for this is that applications may ask
1688 first for one type of information about a name followed by a second
1689 request to the same name for some other type of information; if the two
1690 errors are combined, then useless queries may slow the application.
1694 While attempting to resolve a particular request, the resolver may find
1695 that the name in question is an alias. For example, the resolver might
1696 find that the name given for host name to address translation is an
1697 alias when it finds the CNAME RR. If possible, the alias condition
1698 should be signalled back from the resolver to the client.
1700 In most cases a resolver simply restarts the query at the new name when
1701 it encounters a CNAME. However, when performing the general function,
1702 the resolver should not pursue aliases when the CNAME RR matches the
1703 query type. This allows queries which ask whether an alias is present.
1704 For example, if the query type is CNAME, the user is interested in the
1705 CNAME RR itself, and not the RRs at the name it points to.
1707 Several special conditions can occur with aliases. Multiple levels of
1708 aliases should be avoided due to their lack of efficiency, but should
1709 not be signalled as an error. Alias loops and aliases which point to
1710 non-existent names should be caught and an error condition passed back
1713 5.2.3. Temporary failures
1715 In a less than perfect world, all resolvers will occasionally be unable
1716 to resolve a particular request. This condition can be caused by a
1717 resolver which becomes separated from the rest of the network due to a
1718 link failure or gateway problem, or less often by coincident failure or
1719 unavailability of all servers for a particular domain.
1721 It is essential that this sort of condition should not be signalled as a
1722 name or data not present error to applications. This sort of behavior
1723 is annoying to humans, and can wreak havoc when mail systems use the
1726 While in some cases it is possible to deal with such a temporary problem
1727 by blocking the request indefinitely, this is usually not a good choice,
1728 particularly when the client is a server process that could move on to
1732 Mockapetris [Page 31]
1734 RFC 1034 Domain Concepts and Facilities November 1987
1737 other tasks. The recommended solution is to always have temporary
1738 failure as one of the possible results of a resolver function, even
1739 though this may make emulation of existing HOSTS.TXT functions more
1742 5.3. Resolver internals
1744 Every resolver implementation uses slightly different algorithms, and
1745 typically spends much more logic dealing with errors of various sorts
1746 than typical occurances. This section outlines a recommended basic
1747 strategy for resolver operation, but leaves details to [RFC-1035].
1749 5.3.1. Stub resolvers
1751 One option for implementing a resolver is to move the resolution
1752 function out of the local machine and into a name server which supports
1753 recursive queries. This can provide an easy method of providing domain
1754 service in a PC which lacks the resources to perform the resolver
1755 function, or can centralize the cache for a whole local network or
1758 All that the remaining stub needs is a list of name server addresses
1759 that will perform the recursive requests. This type of resolver
1760 presumably needs the information in a configuration file, since it
1761 probably lacks the sophistication to locate it in the domain database.
1762 The user also needs to verify that the listed servers will perform the
1763 recursive service; a name server is free to refuse to perform recursive
1764 services for any or all clients. The user should consult the local
1765 system administrator to find name servers willing to perform the
1768 This type of service suffers from some drawbacks. Since the recursive
1769 requests may take an arbitrary amount of time to perform, the stub may
1770 have difficulty optimizing retransmission intervals to deal with both
1771 lost UDP packets and dead servers; the name server can be easily
1772 overloaded by too zealous a stub if it interprets retransmissions as new
1773 requests. Use of TCP may be an answer, but TCP may well place burdens
1774 on the host's capabilities which are similar to those of a real
1779 In addition to its own resources, the resolver may also have shared
1780 access to zones maintained by a local name server. This gives the
1781 resolver the advantage of more rapid access, but the resolver must be
1782 careful to never let cached information override zone data. In this
1783 discussion the term "local information" is meant to mean the union of
1784 the cache and such shared zones, with the understanding that
1788 Mockapetris [Page 32]
1790 RFC 1034 Domain Concepts and Facilities November 1987
1793 authoritative data is always used in preference to cached data when both
1796 The following resolver algorithm assumes that all functions have been
1797 converted to a general lookup function, and uses the following data
1798 structures to represent the state of a request in progress in the
1801 SNAME the domain name we are searching for.
1803 STYPE the QTYPE of the search request.
1805 SCLASS the QCLASS of the search request.
1807 SLIST a structure which describes the name servers and the
1808 zone which the resolver is currently trying to query.
1809 This structure keeps track of the resolver's current
1810 best guess about which name servers hold the desired
1811 information; it is updated when arriving information
1812 changes the guess. This structure includes the
1813 equivalent of a zone name, the known name servers for
1814 the zone, the known addresses for the name servers, and
1815 history information which can be used to suggest which
1816 server is likely to be the best one to try next. The
1817 zone name equivalent is a match count of the number of
1818 labels from the root down which SNAME has in common with
1819 the zone being queried; this is used as a measure of how
1820 "close" the resolver is to SNAME.
1822 SBELT a "safety belt" structure of the same form as SLIST,
1823 which is initialized from a configuration file, and
1824 lists servers which should be used when the resolver
1825 doesn't have any local information to guide name server
1826 selection. The match count will be -1 to indicate that
1827 no labels are known to match.
1829 CACHE A structure which stores the results from previous
1830 responses. Since resolvers are responsible for
1831 discarding old RRs whose TTL has expired, most
1832 implementations convert the interval specified in
1833 arriving RRs to some sort of absolute time when the RR
1834 is stored in the cache. Instead of counting the TTLs
1835 down individually, the resolver just ignores or discards
1836 old RRs when it runs across them in the course of a
1837 search, or discards them during periodic sweeps to
1838 reclaim the memory consumed by old RRs.
1844 Mockapetris [Page 33]
1846 RFC 1034 Domain Concepts and Facilities November 1987
1851 The top level algorithm has four steps:
1853 1. See if the answer is in local information, and if so return
1856 2. Find the best servers to ask.
1858 3. Send them queries until one returns a response.
1860 4. Analyze the response, either:
1862 a. if the response answers the question or contains a name
1863 error, cache the data as well as returning it back to
1866 b. if the response contains a better delegation to other
1867 servers, cache the delegation information, and go to
1870 c. if the response shows a CNAME and that is not the
1871 answer itself, cache the CNAME, change the SNAME to the
1872 canonical name in the CNAME RR and go to step 1.
1874 d. if the response shows a servers failure or other
1875 bizarre contents, delete the server from the SLIST and
1878 Step 1 searches the cache for the desired data. If the data is in the
1879 cache, it is assumed to be good enough for normal use. Some resolvers
1880 have an option at the user interface which will force the resolver to
1881 ignore the cached data and consult with an authoritative server. This
1882 is not recommended as the default. If the resolver has direct access to
1883 a name server's zones, it should check to see if the desired data is
1884 present in authoritative form, and if so, use the authoritative data in
1885 preference to cached data.
1887 Step 2 looks for a name server to ask for the required data. The
1888 general strategy is to look for locally-available name server RRs,
1889 starting at SNAME, then the parent domain name of SNAME, the
1890 grandparent, and so on toward the root. Thus if SNAME were
1891 Mockapetris.ISI.EDU, this step would look for NS RRs for
1892 Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
1893 These NS RRs list the names of hosts for a zone at or above SNAME. Copy
1894 the names into SLIST. Set up their addresses using local data. It may
1895 be the case that the addresses are not available. The resolver has many
1896 choices here; the best is to start parallel resolver processes looking
1900 Mockapetris [Page 34]
1902 RFC 1034 Domain Concepts and Facilities November 1987
1905 for the addresses while continuing onward with the addresses which are
1906 available. Obviously, the design choices and options are complicated
1907 and a function of the local host's capabilities. The recommended
1908 priorities for the resolver designer are:
1910 1. Bound the amount of work (packets sent, parallel processes
1911 started) so that a request can't get into an infinite loop or
1912 start off a chain reaction of requests or queries with other
1913 implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
1916 2. Get back an answer if at all possible.
1918 3. Avoid unnecessary transmissions.
1920 4. Get the answer as quickly as possible.
1922 If the search for NS RRs fails, then the resolver initializes SLIST from
1923 the safety belt SBELT. The basic idea is that when the resolver has no
1924 idea what servers to ask, it should use information from a configuration
1925 file that lists several servers which are expected to be helpful.
1926 Although there are special situations, the usual choice is two of the
1927 root servers and two of the servers for the host's domain. The reason
1928 for two of each is for redundancy. The root servers will provide
1929 eventual access to all of the domain space. The two local servers will
1930 allow the resolver to continue to resolve local names if the local
1931 network becomes isolated from the internet due to gateway or link
1934 In addition to the names and addresses of the servers, the SLIST data
1935 structure can be sorted to use the best servers first, and to insure
1936 that all addresses of all servers are used in a round-robin manner. The
1937 sorting can be a simple function of preferring addresses on the local
1938 network over others, or may involve statistics from past events, such as
1939 previous response times and batting averages.
1941 Step 3 sends out queries until a response is received. The strategy is
1942 to cycle around all of the addresses for all of the servers with a
1943 timeout between each transmission. In practice it is important to use
1944 all addresses of a multihomed host, and too aggressive a retransmission
1945 policy actually slows response when used by multiple resolvers
1946 contending for the same name server and even occasionally for a single
1947 resolver. SLIST typically contains data values to control the timeouts
1948 and keep track of previous transmissions.
1950 Step 4 involves analyzing responses. The resolver should be highly
1951 paranoid in its parsing of responses. It should also check that the
1952 response matches the query it sent using the ID field in the response.
1956 Mockapetris [Page 35]
1958 RFC 1034 Domain Concepts and Facilities November 1987
1961 The ideal answer is one from a server authoritative for the query which
1962 either gives the required data or a name error. The data is passed back
1963 to the user and entered in the cache for future use if its TTL is
1966 If the response shows a delegation, the resolver should check to see
1967 that the delegation is "closer" to the answer than the servers in SLIST
1968 are. This can be done by comparing the match count in SLIST with that
1969 computed from SNAME and the NS RRs in the delegation. If not, the reply
1970 is bogus and should be ignored. If the delegation is valid the NS
1971 delegation RRs and any address RRs for the servers should be cached.
1972 The name servers are entered in the SLIST, and the search is restarted.
1974 If the response contains a CNAME, the search is restarted at the CNAME
1975 unless the response has the data for the canonical name or if the CNAME
1976 is the answer itself.
1978 Details and implementation hints can be found in [RFC-1035].
1982 In our sample domain space, suppose we wanted separate administrative
1983 control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
1984 allocate name servers as follows:
1987 |(C.ISI.EDU,SRI-NIC.ARPA
1989 +---------------------+------------------+
1992 |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
1993 | A.ISI.EDU | C.ISI.EDU) |
1994 +-----+-----+ | +------+-----+-----+
1996 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
1998 +--------+------------------+---------------+--------+
2001 |(XX.LCS.MIT.EDU, ISI
2002 |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
2003 +---+---+ | A.ISI.EDU)
2005 LCS ACHILLES +--+-----+-----+--------+
2007 XX A C VAXA VENERA Mockapetris
2012 Mockapetris [Page 36]
2014 RFC 1034 Domain Concepts and Facilities November 1987
2017 In this example, the authoritative name server is shown in parentheses
2018 at the point in the domain tree at which is assumes control.
2020 Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
2021 A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
2022 EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
2023 may have zones which are contiguous or disjoint. In this scenario,
2024 C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
2025 has contiguous zones at the root and MIL domains, but also has a non-
2026 contiguous zone at ISI.EDU.
2028 6.1. C.ISI.EDU name server
2030 C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
2031 class, and would have zones for these domains. The zone data for the
2032 root domain might be:
2034 . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
2036 1800 ;refresh every 30 min
2037 300 ;retry every 5 min
2038 604800 ;expire after a week
2039 86400) ;minimum of a day
2044 MIL. 86400 NS SRI-NIC.ARPA.
2047 EDU. 86400 NS SRI-NIC.ARPA.
2050 SRI-NIC.ARPA. A 26.0.0.73
2053 HINFO DEC-2060 TOPS20
2055 ACC.ARPA. A 26.6.0.65
2056 HINFO PDP-11/70 UNIX
2059 USC-ISIC.ARPA. CNAME C.ISI.EDU.
2061 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2062 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
2063 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2064 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
2068 Mockapetris [Page 37]
2070 RFC 1034 Domain Concepts and Facilities November 1987
2073 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
2075 A.ISI.EDU. 86400 A 26.3.0.103
2076 C.ISI.EDU. 86400 A 10.0.0.52
2078 This data is represented as it would be in a master file. Most RRs are
2079 single line entries; the sole exception here is the SOA RR, which uses
2080 "(" to start a multi-line RR and ")" to show the end of a multi-line RR.
2081 Since the class of all RRs in a zone must be the same, only the first RR
2082 in a zone need specify the class. When a name server loads a zone, it
2083 forces the TTL of all authoritative RRs to be at least the MINIMUM field
2084 of the SOA, here 86400 seconds, or one day. The NS RRs marking
2085 delegation of the MIL and EDU domains, together with the glue RRs for
2086 the servers host addresses, are not part of the authoritative data in
2087 the zone, and hence have explicit TTLs.
2089 Four RRs are attached to the root node: the SOA which describes the root
2090 zone and the 3 NS RRs which list the name servers for the root. The
2091 data in the SOA RR describes the management of the zone. The zone data
2092 is maintained on host SRI-NIC.ARPA, and the responsible party for the
2093 zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
2094 second minimum TTL, which means that all authoritative data in the zone
2095 has at least that TTL, although higher values may be explicitly
2098 The NS RRs for the MIL and EDU domains mark the boundary between the
2099 root zone and the MIL and EDU zones. Note that in this example, the
2100 lower zones happen to be supported by name servers which also support
2103 The master file for the EDU zone might be stated relative to the origin
2104 EDU. The zone data for the EDU domain might be:
2106 EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
2108 1800 ;refresh every 30 minutes
2109 300 ;retry every 5 minutes
2110 604800 ;expire after a week
2111 86400 ;minimum of a day
2116 UCI 172800 NS ICS.UCI
2118 ICS.UCI 172800 A 192.5.19.1
2119 ROME.UCI 172800 A 192.5.19.31
2124 Mockapetris [Page 38]
2126 RFC 1034 Domain Concepts and Facilities November 1987
2129 ISI 172800 NS VAXA.ISI
2131 172800 NS VENERA.ISI.EDU.
2132 VAXA.ISI 172800 A 10.2.0.27
2134 VENERA.ISI.EDU. 172800 A 10.1.0.52
2136 A.ISI 172800 A 26.3.0.103
2138 UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
2139 172800 NS UMN-REI-UC.ARPA.
2140 LOUIE.UDEL.EDU. 172800 A 10.0.0.96
2143 YALE.EDU. 172800 NS YALE.ARPA.
2144 YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
2146 MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
2147 43200 NS ACHILLES.MIT.EDU.
2148 XX.LCS.MIT.EDU. 43200 A 10.0.0.44
2149 ACHILLES.MIT.EDU. 43200 A 18.72.0.8
2151 Note the use of relative names here. The owner name for the ISI.EDU. is
2152 stated using a relative name, as are two of the name server RR contents.
2153 Relative and absolute domain names may be freely intermixed in a master
2155 6.2. Example standard queries
2157 The following queries and responses illustrate name server behavior.
2158 Unless otherwise noted, the queries do not have recursion desired (RD)
2159 in the header. Note that the answers to non-recursive queries do depend
2160 on the server being asked, but do not depend on the identity of the
2180 Mockapetris [Page 39]
2182 RFC 1034 Domain Concepts and Facilities November 1987
2185 6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
2187 The query would look like:
2189 +---------------------------------------------------+
2190 Header | OPCODE=SQUERY |
2191 +---------------------------------------------------+
2192 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2193 +---------------------------------------------------+
2195 +---------------------------------------------------+
2196 Authority | <empty> |
2197 +---------------------------------------------------+
2198 Additional | <empty> |
2199 +---------------------------------------------------+
2201 The response from C.ISI.EDU would be:
2203 +---------------------------------------------------+
2204 Header | OPCODE=SQUERY, RESPONSE, AA |
2205 +---------------------------------------------------+
2206 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2207 +---------------------------------------------------+
2208 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2209 | 86400 IN A 10.0.0.51 |
2210 +---------------------------------------------------+
2211 Authority | <empty> |
2212 +---------------------------------------------------+
2213 Additional | <empty> |
2214 +---------------------------------------------------+
2216 The header of the response looks like the header of the query, except
2217 that the RESPONSE bit is set, indicating that this message is a
2218 response, not a query, and the Authoritative Answer (AA) bit is set
2219 indicating that the address RRs in the answer section are from
2220 authoritative data. The question section of the response matches the
2221 question section of the query.
2236 Mockapetris [Page 40]
2238 RFC 1034 Domain Concepts and Facilities November 1987
2241 If the same query was sent to some other server which was not
2242 authoritative for SRI-NIC.ARPA, the response might be:
2244 +---------------------------------------------------+
2245 Header | OPCODE=SQUERY,RESPONSE |
2246 +---------------------------------------------------+
2247 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2248 +---------------------------------------------------+
2249 Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
2250 | 1777 IN A 26.0.0.73 |
2251 +---------------------------------------------------+
2252 Authority | <empty> |
2253 +---------------------------------------------------+
2254 Additional | <empty> |
2255 +---------------------------------------------------+
2257 This response is different from the previous one in two ways: the header
2258 does not have AA set, and the TTLs are different. The inference is that
2259 the data did not come from a zone, but from a cache. The difference
2260 between the authoritative TTL and the TTL here is due to aging of the
2261 data in a cache. The difference in ordering of the RRs in the answer
2262 section is not significant.
2264 6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
2266 A query similar to the previous one, but using a QTYPE of *, would
2267 receive the following response from C.ISI.EDU:
2269 +---------------------------------------------------+
2270 Header | OPCODE=SQUERY, RESPONSE, AA |
2271 +---------------------------------------------------+
2272 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2273 +---------------------------------------------------+
2274 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2276 | MX 0 SRI-NIC.ARPA. |
2277 | HINFO DEC-2060 TOPS20 |
2278 +---------------------------------------------------+
2279 Authority | <empty> |
2280 +---------------------------------------------------+
2281 Additional | <empty> |
2282 +---------------------------------------------------+
2292 Mockapetris [Page 41]
2294 RFC 1034 Domain Concepts and Facilities November 1987
2297 If a similar query was directed to two name servers which are not
2298 authoritative for SRI-NIC.ARPA, the responses might be:
2300 +---------------------------------------------------+
2301 Header | OPCODE=SQUERY, RESPONSE |
2302 +---------------------------------------------------+
2303 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2304 +---------------------------------------------------+
2305 Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
2307 +---------------------------------------------------+
2308 Authority | <empty> |
2309 +---------------------------------------------------+
2310 Additional | <empty> |
2311 +---------------------------------------------------+
2315 +---------------------------------------------------+
2316 Header | OPCODE=SQUERY, RESPONSE |
2317 +---------------------------------------------------+
2318 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2319 +---------------------------------------------------+
2320 Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
2321 +---------------------------------------------------+
2322 Authority | <empty> |
2323 +---------------------------------------------------+
2324 Additional | <empty> |
2325 +---------------------------------------------------+
2327 Neither of these answers have AA set, so neither response comes from
2328 authoritative data. The different contents and different TTLs suggest
2329 that the two servers cached data at different times, and that the first
2330 server cached the response to a QTYPE=A query and the second cached the
2331 response to a HINFO query.
2348 Mockapetris [Page 42]
2350 RFC 1034 Domain Concepts and Facilities November 1987
2353 6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
2355 This type of query might be result from a mailer trying to look up
2356 routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
2357 The response from C.ISI.EDU would be:
2359 +---------------------------------------------------+
2360 Header | OPCODE=SQUERY, RESPONSE, AA |
2361 +---------------------------------------------------+
2362 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
2363 +---------------------------------------------------+
2364 Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
2365 +---------------------------------------------------+
2366 Authority | <empty> |
2367 +---------------------------------------------------+
2368 Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2370 +---------------------------------------------------+
2372 This response contains the MX RR in the answer section of the response.
2373 The additional section contains the address RRs because the name server
2374 at C.ISI.EDU guesses that the requester will need the addresses in order
2375 to properly use the information carried by the MX.
2377 6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
2379 C.ISI.EDU would reply to this query with:
2381 +---------------------------------------------------+
2382 Header | OPCODE=SQUERY, RESPONSE, AA |
2383 +---------------------------------------------------+
2384 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
2385 +---------------------------------------------------+
2387 +---------------------------------------------------+
2388 Authority | <empty> |
2389 +---------------------------------------------------+
2390 Additional | <empty> |
2391 +---------------------------------------------------+
2393 The only difference between the response and the query is the AA and
2394 RESPONSE bits in the header. The interpretation of this response is
2395 that the server is authoritative for the name, and the name exists, but
2396 no RRs of type NS are present there.
2398 6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
2400 If a user mistyped a host name, we might see this type of query.
2404 Mockapetris [Page 43]
2406 RFC 1034 Domain Concepts and Facilities November 1987
2409 C.ISI.EDU would answer it with:
2411 +---------------------------------------------------+
2412 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
2413 +---------------------------------------------------+
2414 Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
2415 +---------------------------------------------------+
2417 +---------------------------------------------------+
2418 Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
2419 | 870611 1800 300 604800 86400 |
2420 +---------------------------------------------------+
2421 Additional | <empty> |
2422 +---------------------------------------------------+
2424 This response states that the name does not exist. This condition is
2425 signalled in the response code (RCODE) section of the header.
2427 The SOA RR in the authority section is the optional negative caching
2428 information which allows the resolver using this response to assume that
2429 the name will not exist for the SOA MINIMUM (86400) seconds.
2431 6.2.6. QNAME=BRL.MIL, QTYPE=A
2433 If this query is sent to C.ISI.EDU, the reply would be:
2435 +---------------------------------------------------+
2436 Header | OPCODE=SQUERY, RESPONSE |
2437 +---------------------------------------------------+
2438 Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
2439 +---------------------------------------------------+
2441 +---------------------------------------------------+
2442 Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
2443 | 86400 NS A.ISI.EDU. |
2444 +---------------------------------------------------+
2445 Additional | A.ISI.EDU. A 26.3.0.103 |
2446 | SRI-NIC.ARPA. A 26.0.0.73 |
2448 +---------------------------------------------------+
2450 This response has an empty answer section, but is not authoritative, so
2451 it is a referral. The name server on C.ISI.EDU, realizing that it is
2452 not authoritative for the MIL domain, has referred the requester to
2453 servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
2460 Mockapetris [Page 44]
2462 RFC 1034 Domain Concepts and Facilities November 1987
2465 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
2467 The response to this query from A.ISI.EDU would be:
2469 +---------------------------------------------------+
2470 Header | OPCODE=SQUERY, RESPONSE, AA |
2471 +---------------------------------------------------+
2472 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2473 +---------------------------------------------------+
2474 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2475 | C.ISI.EDU. 86400 IN A 10.0.0.52 |
2476 +---------------------------------------------------+
2477 Authority | <empty> |
2478 +---------------------------------------------------+
2479 Additional | <empty> |
2480 +---------------------------------------------------+
2482 Note that the AA bit in the header guarantees that the data matching
2483 QNAME is authoritative, but does not say anything about whether the data
2484 for C.ISI.EDU is authoritative. This complete reply is possible because
2485 A.ISI.EDU happens to be authoritative for both the ARPA domain where
2486 USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
2489 If the same query was sent to C.ISI.EDU, its response might be the same
2490 as shown above if it had its own address in its cache, but might also
2516 Mockapetris [Page 45]
2518 RFC 1034 Domain Concepts and Facilities November 1987
2521 +---------------------------------------------------+
2522 Header | OPCODE=SQUERY, RESPONSE, AA |
2523 +---------------------------------------------------+
2524 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2525 +---------------------------------------------------+
2526 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2527 +---------------------------------------------------+
2528 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2530 | NS VENERA.ISI.EDU. |
2531 +---------------------------------------------------+
2532 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2533 | 172800 A 128.9.0.33 |
2534 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2535 | 172800 A 128.9.0.32 |
2536 | A.ISI.EDU. 172800 A 26.3.0.103 |
2537 +---------------------------------------------------+
2539 This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
2540 plus a referral to the name servers for ISI.EDU. This sort of reply
2541 isn't very likely given that the query is for the host name of the name
2542 server being asked, but would be common for other aliases.
2544 6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
2546 If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
2549 +---------------------------------------------------+
2550 Header | OPCODE=SQUERY, RESPONSE, AA |
2551 +---------------------------------------------------+
2552 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2553 +---------------------------------------------------+
2554 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2555 +---------------------------------------------------+
2556 Authority | <empty> |
2557 +---------------------------------------------------+
2558 Additional | <empty> |
2559 +---------------------------------------------------+
2561 Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
2562 server doesn't attempt to look up anything for C.ISI.EDU. (Except
2563 possibly for the additional section.)
2565 6.3. Example resolution
2567 The following examples illustrate the operations a resolver must perform
2568 for its client. We assume that the resolver is starting without a
2572 Mockapetris [Page 46]
2574 RFC 1034 Domain Concepts and Facilities November 1987
2577 cache, as might be the case after system boot. We further assume that
2578 the system is not one of the hosts in the data and that the host is
2579 located somewhere on net 26, and that its safety belt (SBELT) data
2580 structure has the following information:
2583 SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
2584 A.ISI.EDU. 26.3.0.103
2586 This information specifies servers to try, their addresses, and a match
2587 count of -1, which says that the servers aren't very close to the
2588 target. Note that the -1 isn't supposed to be an accurate closeness
2589 measure, just a value so that later stages of the algorithm will work.
2591 The following examples illustrate the use of a cache, so each example
2592 assumes that previous requests have completed.
2594 6.3.1. Resolve MX for ISI.EDU.
2596 Suppose the first request to the resolver comes from the local mailer,
2597 which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
2598 RRs for the domain name ISI.EDU.
2600 The resolver would look in its cache for MX RRs at ISI.EDU, but the
2601 empty cache wouldn't be helpful. The resolver would recognize that it
2602 needed to query foreign servers and try to determine the best servers to
2603 query. This search would look for NS RRs for the domains ISI.EDU, EDU,
2604 and the root. These searches of the cache would also fail. As a last
2605 resort, the resolver would use the information from the SBELT, copying
2606 it into its SLIST structure.
2608 At this point the resolver would need to pick one of the three available
2609 addresses to try. Given that the resolver is on net 26, it should
2610 choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would
2611 then send off a query of the form:
2628 Mockapetris [Page 47]
2630 RFC 1034 Domain Concepts and Facilities November 1987
2633 +---------------------------------------------------+
2634 Header | OPCODE=SQUERY |
2635 +---------------------------------------------------+
2636 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2637 +---------------------------------------------------+
2639 +---------------------------------------------------+
2640 Authority | <empty> |
2641 +---------------------------------------------------+
2642 Additional | <empty> |
2643 +---------------------------------------------------+
2645 The resolver would then wait for a response to its query or a timeout.
2646 If the timeout occurs, it would try different servers, then different
2647 addresses of the same servers, lastly retrying addresses already tried.
2648 It might eventually receive a reply from SRI-NIC.ARPA:
2650 +---------------------------------------------------+
2651 Header | OPCODE=SQUERY, RESPONSE |
2652 +---------------------------------------------------+
2653 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2654 +---------------------------------------------------+
2656 +---------------------------------------------------+
2657 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2659 | NS VENERA.ISI.EDU.|
2660 +---------------------------------------------------+
2661 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2662 | 172800 A 128.9.0.33 |
2663 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2664 | 172800 A 128.9.0.32 |
2665 | A.ISI.EDU. 172800 A 26.3.0.103 |
2666 +---------------------------------------------------+
2668 The resolver would notice that the information in the response gave a
2669 closer delegation to ISI.EDU than its existing SLIST (since it matches
2670 three labels). The resolver would then cache the information in this
2671 response and use it to set up a new SLIST:
2674 A.ISI.EDU. 26.3.0.103
2675 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2676 VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
2678 A.ISI.EDU appears on this list as well as the previous one, but that is
2679 purely coincidental. The resolver would again start transmitting and
2680 waiting for responses. Eventually it would get an answer:
2684 Mockapetris [Page 48]
2686 RFC 1034 Domain Concepts and Facilities November 1987
2689 +---------------------------------------------------+
2690 Header | OPCODE=SQUERY, RESPONSE, AA |
2691 +---------------------------------------------------+
2692 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2693 +---------------------------------------------------+
2694 Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. |
2695 | MX 20 VAXA.ISI.EDU. |
2696 +---------------------------------------------------+
2697 Authority | <empty> |
2698 +---------------------------------------------------+
2699 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2700 | 172800 A 128.9.0.33 |
2701 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2702 | 172800 A 128.9.0.32 |
2703 +---------------------------------------------------+
2705 The resolver would add this information to its cache, and return the MX
2708 6.3.2. Get the host name for address 26.6.0.65
2710 The resolver would translate this into a request for PTR RRs for
2711 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the
2712 resolver would look for foreign servers to ask. No servers would match,
2713 so it would use SBELT again. (Note that the servers for the ISI.EDU
2714 domain are in the cache, but ISI.EDU is not an ancestor of
2715 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
2717 Since this request is within the authoritative data of both servers in
2718 SBELT, eventually one would return:
2740 Mockapetris [Page 49]
2742 RFC 1034 Domain Concepts and Facilities November 1987
2745 +---------------------------------------------------+
2746 Header | OPCODE=SQUERY, RESPONSE, AA |
2747 +---------------------------------------------------+
2748 Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
2749 +---------------------------------------------------+
2750 Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
2751 +---------------------------------------------------+
2752 Authority | <empty> |
2753 +---------------------------------------------------+
2754 Additional | <empty> |
2755 +---------------------------------------------------+
2757 6.3.3. Get the host address of poneria.ISI.EDU
2759 This request would translate into a type A request for poneria.ISI.EDU.
2760 The resolver would not find any cached data for this name, but would
2761 find the NS RRs in the cache for ISI.EDU when it looks for foreign
2762 servers to ask. Using this data, it would construct a SLIST of the
2767 A.ISI.EDU. 26.3.0.103
2768 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2769 VENERA.ISI.EDU. 10.1.0.52
2771 A.ISI.EDU is listed first on the assumption that the resolver orders its
2772 choices by preference, and A.ISI.EDU is on the same network.
2774 One of these servers would answer the query.
2776 7. REFERENCES and BIBLIOGRAPHY
2778 [Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena
2779 Technical Plan - Name Service, April 1987, version 1.9.
2781 Describes the fundamentals of the Hesiod name service.
2783 [IEN-116] J. Postel, "Internet Name Server", IEN-116,
2784 USC/Information Sciences Institute, August 1979.
2786 A name service obsoleted by the Domain Name System, but
2796 Mockapetris [Page 50]
2798 RFC 1034 Domain Concepts and Facilities November 1987
2801 [Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
2802 Networks",Communications of the ACM, October 1986,
2803 volume 29, number 10.
2805 [RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2806 Information Center, SRI International, December 1977.
2808 [RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2809 USC/Information Sciences Institute, August 1980.
2811 [RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2812 USC/Information Sciences Institute, September 1981.
2814 [RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2817 Suggests introduction of a hierarchy in place of a flat
2818 name space for the Internet.
2820 [RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2821 USC/Information Sciences Institute, February 1982.
2823 [RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
2824 Internet Host Table Specification", RFC-810, Network
2825 Information Center, SRI International, March 1982.
2827 Obsolete. See RFC-952.
2829 [RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2830 Server", RFC-811, Network Information Center, SRI
2831 International, March 1982.
2833 Obsolete. See RFC-953.
2835 [RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2836 Network Information Center, SRI International, March
2839 [RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
2840 Internet User Applications", RFC-819, Network
2841 Information Center, SRI International, August 1982.
2843 Early thoughts on the design of the domain system.
2844 Current implementation is completely different.
2846 [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2847 USC/Information Sciences Institute, August 1980.
2852 Mockapetris [Page 51]
2854 RFC 1034 Domain Concepts and Facilities November 1987
2857 [RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2858 RFC-830, Network Information Center, SRI International,
2861 Early thoughts on the design of the domain system.
2862 Current implementation is completely different.
2864 [RFC-882] P. Mockapetris, "Domain names - Concepts and
2865 Facilities," RFC-882, USC/Information Sciences
2866 Institute, November 1983.
2868 Superceeded by this memo.
2870 [RFC-883] P. Mockapetris, "Domain names - Implementation and
2871 Specification," RFC-883, USC/Information Sciences
2872 Institute, November 1983.
2874 Superceeded by this memo.
2876 [RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2877 RFC-920, USC/Information Sciences Institute
2880 Explains the naming scheme for top level domains.
2882 [RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2883 Table Specification", RFC-952, SRI, October 1985.
2885 Specifies the format of HOSTS.TXT, the host/address
2886 table replaced by the DNS.
2888 [RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2889 RFC-953, SRI, October 1985.
2891 This RFC contains the official specification of the
2892 hostname server protocol, which is obsoleted by the DNS.
2893 This TCP based protocol accesses information stored in
2894 the RFC-952 format, and is used to obtain copies of the
2897 [RFC-973] P. Mockapetris, "Domain System Changes and
2898 Observations", RFC-973, USC/Information Sciences
2899 Institute, January 1986.
2901 Describes changes to RFC-882 and RFC-883 and reasons for
2908 Mockapetris [Page 52]
2910 RFC 1034 Domain Concepts and Facilities November 1987
2913 [RFC-974] C. Partridge, "Mail routing and the domain system",
2914 RFC-974, CSNET CIC BBN Labs, January 1986.
2916 Describes the transition from HOSTS.TXT based mail
2917 addressing to the more powerful MX system used with the
2920 [RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
2921 service on a TCP/UDP transport: Concepts and Methods",
2922 RFC-1001, March 1987.
2924 This RFC and RFC-1002 are a preliminary design for
2925 NETBIOS on top of TCP/IP which proposes to base NetBIOS
2926 name service on top of the DNS.
2928 [RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2929 service on a TCP/UDP transport: Detailed
2930 Specifications", RFC-1002, March 1987.
2932 [RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
2933 USC/Information Sciences Institute, May 1987
2935 Contains socket numbers and mnemonics for host names,
2936 operating systems, etc.
2938 [RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2941 Describes a plan for converting the MILNET to the DNS.
2943 [RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for
2944 Administrators", RFC-1032, November 1987.
2946 Describes the registration policies used by the NIC to
2947 administer the top level domains and delegate subzones.
2949 [RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide",
2950 RFC-1033, November 1987.
2952 A cookbook for domain administrators.
2954 [Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2955 Name Server", Computer Networks, vol 6, nr 3, July 1982.
2957 Describes a name service for CSNET which is independent
2958 from the DNS and DNS use in the CSNET.
2964 Mockapetris [Page 53]
2966 RFC 1034 Domain Concepts and Facilities November 1987
2977 Case of characters 7
2980 Completion queries 18
3012 Recursive service 22
3020 Mockapetris [Page 54]
3022 RFC 1034 Domain Concepts and Facilities November 1987
3076 Mockapetris [Page 55]
projects / FreeBSD / releng / 7.2.git / blob