Return to rfc1035.lpr CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc

Annotation of 43BSDReno/usr.sbin/named/doc/rfc1035.lpr, revision 1.1

1.1     ! root        1: Network Working Group                                     P. Mockapetris
        !             2: Request for Comments: 1035                                           ISI
        !             3:                                                            November 1987
        !             4: Obsoletes: RFCs 882, 883, 973
        !             5: 
        !             6:             DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
        !             7: 
        !             8: 
        !             9: 1. STATUS OF THIS MEMO
        !            10: 
        !            11: This RFC describes the details of the domain system and protocol, and
        !            12: assumes that the reader is familiar with the concepts discussed in a
        !            13: companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
        !            14: 
        !            15: The domain system is a mixture of functions and data types which are an
        !            16: official protocol and functions and data types which are still
        !            17: experimental.  Since the domain system is intentionally extensible, new
        !            18: data types and experimental behavior should always be expected in parts
        !            19: of the system beyond the official protocol.  The official protocol parts
        !            20: include standard queries, responses and the Internet class RR data
        !            21: formats (e.g., host addresses).  Since the previous RFC set, several
        !            22: definitions have changed, so some previous definitions are obsolete.
        !            23: 
        !            24: Experimental or obsolete features are clearly marked in these RFCs, and
        !            25: such information should be used with caution.
        !            26: 
        !            27: The reader is especially cautioned not to depend on the values which
        !            28: appear in examples to be current or complete, since their purpose is
        !            29: primarily pedagogical.  Distribution of this memo is unlimited.
        !            30: 
        !            31:                            Table of Contents
        !            32: 
        !            33:   1. STATUS OF THIS MEMO                                              1
        !            34:   2. INTRODUCTION                                                     3
        !            35:       2.1. Overview                                                   3
        !            36:       2.2. Common configurations                                      4
        !            37:       2.3. Conventions                                                7
        !            38:           2.3.1. Preferred name syntax                                7
        !            39:           2.3.2. Data Transmission Order                              8
        !            40:           2.3.3. Character Case                                       9
        !            41:           2.3.4. Size limits                                         10
        !            42:   3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
        !            43:       3.1. Name space definitions                                    10
        !            44:       3.2. RR definitions                                            11
        !            45:           3.2.1. Format                                              11
        !            46:           3.2.2. TYPE values                                         12
        !            47:           3.2.3. QTYPE values                                        12
        !            48:           3.2.4. CLASS values                                        13
        !            49: 
        !            50: 
        !            51: 
        !            52: Mockapetris                                                     [Page 1]
        !            53: 
        !            54: RFC 1035        Domain Implementation and Specification    November 1987
        !            55: 
        !            56: 
        !            57:           3.2.5. QCLASS values                                       13
        !            58:       3.3. Standard RRs                                              13
        !            59:           3.3.1. CNAME RDATA format                                  14
        !            60:           3.3.2. HINFO RDATA format                                  14
        !            61:           3.3.3. MB RDATA format (EXPERIMENTAL)                      14
        !            62:           3.3.4. MD RDATA format (Obsolete)                          15
        !            63:           3.3.5. MF RDATA format (Obsolete)                          15
        !            64:           3.3.6. MG RDATA format (EXPERIMENTAL)                      16
        !            65:           3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
        !            66:           3.3.8. MR RDATA format (EXPERIMENTAL)                      17
        !            67:           3.3.9. MX RDATA format                                     17
        !            68:           3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
        !            69:           3.3.11. NS RDATA format                                    18
        !            70:           3.3.12. PTR RDATA format                                   18
        !            71:           3.3.13. SOA RDATA format                                   19
        !            72:           3.3.14. TXT RDATA format                                   20
        !            73:       3.4. ARPA Internet specific RRs                                20
        !            74:           3.4.1. A RDATA format                                      20
        !            75:           3.4.2. WKS RDATA format                                    21
        !            76:       3.5. IN-ADDR.ARPA domain                                       22
        !            77:       3.6. Defining new types, classes, and special namespaces       24
        !            78:   4. MESSAGES                                                        25
        !            79:       4.1. Format                                                    25
        !            80:           4.1.1. Header section format                               26
        !            81:           4.1.2. Question section format                             28
        !            82:           4.1.3. Resource record format                              29
        !            83:           4.1.4. Message compression                                 30
        !            84:       4.2. Transport                                                 32
        !            85:           4.2.1. UDP usage                                           32
        !            86:           4.2.2. TCP usage                                           32
        !            87:   5. MASTER FILES                                                    33
        !            88:       5.1. Format                                                    33
        !            89:       5.2. Use of master files to define zones                       35
        !            90:       5.3. Master file example                                       36
        !            91:   6. NAME SERVER IMPLEMENTATION                                      37
        !            92:       6.1. Architecture                                              37
        !            93:           6.1.1. Control                                             37
        !            94:           6.1.2. Database                                            37
        !            95:           6.1.3. Time                                                39
        !            96:       6.2. Standard query processing                                 39
        !            97:       6.3. Zone refresh and reload processing                        39
        !            98:       6.4. Inverse queries (Optional)                                40
        !            99:           6.4.1. The contents of inverse queries and responses       40
        !           100:           6.4.2. Inverse query and response example                  41
        !           101:           6.4.3. Inverse query processing                            42
        !           102: 
        !           103: 
        !           104: 
        !           105: 
        !           106: 
        !           107: 
        !           108: Mockapetris                                                     [Page 2]
        !           109: 
        !           110: RFC 1035        Domain Implementation and Specification    November 1987
        !           111: 
        !           112: 
        !           113:       6.5. Completion queries and responses                          42
        !           114:   7. RESOLVER IMPLEMENTATION                                         43
        !           115:       7.1. Transforming a user request into a query                  43
        !           116:       7.2. Sending the queries                                       44
        !           117:       7.3. Processing responses                                      46
        !           118:       7.4. Using the cache                                           47
        !           119:   8. MAIL SUPPORT                                                    47
        !           120:       8.1. Mail exchange binding                                     48
        !           121:       8.2. Mailbox binding (Experimental)                            48
        !           122:   9. REFERENCES and BIBLIOGRAPHY                                     50
        !           123:   Index                                                              54
        !           124: 
        !           125: 2. INTRODUCTION
        !           126: 
        !           127: 2.1. Overview
        !           128: 
        !           129: The goal of domain names is to provide a mechanism for naming resources
        !           130: in such a way that the names are usable in different hosts, networks,
        !           131: protocol families, internets, and administrative organizations.
        !           132: 
        !           133: From the user's point of view, domain names are useful as arguments to a
        !           134: local agent, called a resolver, which retrieves information associated
        !           135: with the domain name.  Thus a user might ask for the host address or
        !           136: mail information associated with a particular domain name.  To enable
        !           137: the user to request a particular type of information, an appropriate
        !           138: query type is passed to the resolver with the domain name.  To the user,
        !           139: the domain tree is a single information space; the resolver is
        !           140: responsible for hiding the distribution of data among name servers from
        !           141: the user.
        !           142: 
        !           143: From the resolver's point of view, the database that makes up the domain
        !           144: space is distributed among various name servers.  Different parts of the
        !           145: domain space are stored in different name servers, although a particular
        !           146: data item will be stored redundantly in two or more name servers.  The
        !           147: resolver starts with knowledge of at least one name server.  When the
        !           148: resolver processes a user query it asks a known name server for the
        !           149: information; in return, the resolver either receives the desired
        !           150: information or a referral to another name server.  Using these
        !           151: referrals, resolvers learn the identities and contents of other name
        !           152: servers.  Resolvers are responsible for dealing with the distribution of
        !           153: the domain space and dealing with the effects of name server failure by
        !           154: consulting redundant databases in other servers.
        !           155: 
        !           156: Name servers manage two kinds of data.  The first kind of data held in
        !           157: sets called zones; each zone is the complete database for a particular
        !           158: "pruned" subtree of the domain space.  This data is called
        !           159: authoritative.  A name server periodically checks to make sure that its
        !           160: zones are up to date, and if not, obtains a new copy of updated zones
        !           161: 
        !           162: 
        !           163: 
        !           164: Mockapetris                                                     [Page 3]
        !           165: 
        !           166: RFC 1035        Domain Implementation and Specification    November 1987
        !           167: 
        !           168: 
        !           169: from master files stored locally or in another name server.  The second
        !           170: kind of data is cached data which was acquired by a local resolver.
        !           171: This data may be incomplete, but improves the performance of the
        !           172: retrieval process when non-local data is repeatedly accessed.  Cached
        !           173: data is eventually discarded by a timeout mechanism.
        !           174: 
        !           175: This functional structure isolates the problems of user interface,
        !           176: failure recovery, and distribution in the resolvers and isolates the
        !           177: database update and refresh problems in the name servers.
        !           178: 
        !           179: 2.2. Common configurations
        !           180: 
        !           181: A host can participate in the domain name system in a number of ways,
        !           182: depending on whether the host runs programs that retrieve information
        !           183: from the domain system, name servers that answer queries from other
        !           184: hosts, or various combinations of both functions.  The simplest, and
        !           185: perhaps most typical, configuration is shown below:
        !           186: 
        !           187:                  Local Host                        |  Foreign
        !           188:                                                    |
        !           189:     +---------+               +----------+         |  +--------+
        !           190:     |         | user queries  |          |queries  |  |        |
        !           191:     |  User   |-------------->|          |---------|->|Foreign |
        !           192:     | Program |               | Resolver |         |  |  Name  |
        !           193:     |         |<--------------|          |<--------|--| Server |
        !           194:     |         | user responses|          |responses|  |        |
        !           195:     +---------+               +----------+         |  +--------+
        !           196:                                 |     A            |
        !           197:                 cache additions |     | references |
        !           198:                                 V     |            |
        !           199:                               +----------+         |
        !           200:                               |  cache   |         |
        !           201:                               +----------+         |
        !           202: 
        !           203: User programs interact with the domain name space through resolvers; the
        !           204: format of user queries and user responses is specific to the host and
        !           205: its operating system.  User queries will typically be operating system
        !           206: calls, and the resolver and its cache will be part of the host operating
        !           207: system.  Less capable hosts may choose to implement the resolver as a
        !           208: subroutine to be linked in with every program that needs its services.
        !           209: Resolvers answer user queries with information they acquire via queries
        !           210: to foreign name servers and the local cache.
        !           211: 
        !           212: Note that the resolver may have to make several queries to several
        !           213: different foreign name servers to answer a particular user query, and
        !           214: hence the resolution of a user query may involve several network
        !           215: accesses and an arbitrary amount of time.  The queries to foreign name
        !           216: servers and the corresponding responses have a standard format described
        !           217: 
        !           218: 
        !           219: 
        !           220: Mockapetris                                                     [Page 4]
        !           221: 
        !           222: RFC 1035        Domain Implementation and Specification    November 1987
        !           223: 
        !           224: 
        !           225: in this memo, and may be datagrams.
        !           226: 
        !           227: Depending on its capabilities, a name server could be a stand alone
        !           228: program on a dedicated machine or a process or processes on a large
        !           229: timeshared host.  A simple configuration might be:
        !           230: 
        !           231:                  Local Host                        |  Foreign
        !           232:                                                    |
        !           233:       +---------+                                  |
        !           234:      /         /|                                  |
        !           235:     +---------+ |             +----------+         |  +--------+
        !           236:     |         | |             |          |responses|  |        |
        !           237:     |         | |             |   Name   |---------|->|Foreign |
        !           238:     |  Master |-------------->|  Server  |         |  |Resolver|
        !           239:     |  files  | |             |          |<--------|--|        |
        !           240:     |         |/              |          | queries |  +--------+
        !           241:     +---------+               +----------+         |
        !           242: 
        !           243: Here a primary name server acquires information about one or more zones
        !           244: by reading master files from its local file system, and answers queries
        !           245: about those zones that arrive from foreign resolvers.
        !           246: 
        !           247: The DNS requires that all zones be redundantly supported by more than
        !           248: one name server.  Designated secondary servers can acquire zones and
        !           249: check for updates from the primary server using the zone transfer
        !           250: protocol of the DNS.  This configuration is shown below:
        !           251: 
        !           252:                  Local Host                        |  Foreign
        !           253:                                                    |
        !           254:       +---------+                                  |
        !           255:      /         /|                                  |
        !           256:     +---------+ |             +----------+         |  +--------+
        !           257:     |         | |             |          |responses|  |        |
        !           258:     |         | |             |   Name   |---------|->|Foreign |
        !           259:     |  Master |-------------->|  Server  |         |  |Resolver|
        !           260:     |  files  | |             |          |<--------|--|        |
        !           261:     |         |/              |          | queries |  +--------+
        !           262:     +---------+               +----------+         |
        !           263:                                 A     |maintenance |  +--------+
        !           264:                                 |     +------------|->|        |
        !           265:                                 |      queries     |  |Foreign |
        !           266:                                 |                  |  |  Name  |
        !           267:                                 +------------------|--| Server |
        !           268:                              maintenance responses |  +--------+
        !           269: 
        !           270: In this configuration, the name server periodically establishes a
        !           271: virtual circuit to a foreign name server to acquire a copy of a zone or
        !           272: to check that an existing copy has not changed.  The messages sent for
        !           273: 
        !           274: 
        !           275: 
        !           276: Mockapetris                                                     [Page 5]
        !           277: 
        !           278: RFC 1035        Domain Implementation and Specification    November 1987
        !           279: 
        !           280: 
        !           281: these maintenance activities follow the same form as queries and
        !           282: responses, but the message sequences are somewhat different.
        !           283: 
        !           284: The information flow in a host that supports all aspects of the domain
        !           285: name system is shown below:
        !           286: 
        !           287:                  Local Host                        |  Foreign
        !           288:                                                    |
        !           289:     +---------+               +----------+         |  +--------+
        !           290:     |         | user queries  |          |queries  |  |        |
        !           291:     |  User   |-------------->|          |---------|->|Foreign |
        !           292:     | Program |               | Resolver |         |  |  Name  |
        !           293:     |         |<--------------|          |<--------|--| Server |
        !           294:     |         | user responses|          |responses|  |        |
        !           295:     +---------+               +----------+         |  +--------+
        !           296:                                 |     A            |
        !           297:                 cache additions |     | references |
        !           298:                                 V     |            |
        !           299:                               +----------+         |
        !           300:                               |  Shared  |         |
        !           301:                               | database |         |
        !           302:                               +----------+         |
        !           303:                                 A     |            |
        !           304:       +---------+     refreshes |     | references |
        !           305:      /         /|               |     V            |
        !           306:     +---------+ |             +----------+         |  +--------+
        !           307:     |         | |             |          |responses|  |        |
        !           308:     |         | |             |   Name   |---------|->|Foreign |
        !           309:     |  Master |-------------->|  Server  |         |  |Resolver|
        !           310:     |  files  | |             |          |<--------|--|        |
        !           311:     |         |/              |          | queries |  +--------+
        !           312:     +---------+               +----------+         |
        !           313:                                 A     |maintenance |  +--------+
        !           314:                                 |     +------------|->|        |
        !           315:                                 |      queries     |  |Foreign |
        !           316:                                 |                  |  |  Name  |
        !           317:                                 +------------------|--| Server |
        !           318:                              maintenance responses |  +--------+
        !           319: 
        !           320: The shared database holds domain space data for the local name server
        !           321: and resolver.  The contents of the shared database will typically be a
        !           322: mixture of authoritative data maintained by the periodic refresh
        !           323: operations of the name server and cached data from previous resolver
        !           324: requests.  The structure of the domain data and the necessity for
        !           325: synchronization between name servers and resolvers imply the general
        !           326: characteristics of this database, but the actual format is up to the
        !           327: local implementor.
        !           328: 
        !           329: 
        !           330: 
        !           331: 
        !           332: Mockapetris                                                     [Page 6]
        !           333: 
        !           334: RFC 1035        Domain Implementation and Specification    November 1987
        !           335: 
        !           336: 
        !           337: Information flow can also be tailored so that a group of hosts act
        !           338: together to optimize activities.  Sometimes this is done to offload less
        !           339: capable hosts so that they do not have to implement a full resolver.
        !           340: This can be appropriate for PCs or hosts which want to minimize the
        !           341: amount of new network code which is required.  This scheme can also
        !           342: allow a group of hosts can share a small number of caches rather than
        !           343: maintaining a large number of separate caches, on the premise that the
        !           344: centralized caches will have a higher hit ratio.  In either case,
        !           345: resolvers are replaced with stub resolvers which act as front ends to
        !           346: resolvers located in a recursive server in one or more name servers
        !           347: known to perform that service:
        !           348: 
        !           349:                    Local Hosts                     |  Foreign
        !           350:                                                    |
        !           351:     +---------+                                    |
        !           352:     |         | responses                          |
        !           353:     | Stub    |<--------------------+              |
        !           354:     | Resolver|                     |              |
        !           355:     |         |----------------+    |              |
        !           356:     +---------+ recursive      |    |              |
        !           357:                 queries        |    |              |
        !           358:                                V    |              |
        !           359:     +---------+ recursive     +----------+         |  +--------+
        !           360:     |         | queries       |          |queries  |  |        |
        !           361:     | Stub    |-------------->| Recursive|---------|->|Foreign |
        !           362:     | Resolver|               | Server   |         |  |  Name  |
        !           363:     |         |<--------------|          |<--------|--| Server |
        !           364:     +---------+ responses     |          |responses|  |        |
        !           365:                               +----------+         |  +--------+
        !           366:                               |  Central |         |
        !           367:                               |   cache  |         |
        !           368:                               +----------+         |
        !           369: 
        !           370: In any case, note that domain components are always replicated for
        !           371: reliability whenever possible.
        !           372: 
        !           373: 2.3. Conventions
        !           374: 
        !           375: The domain system has several conventions dealing with low-level, but
        !           376: fundamental, issues.  While the implementor is free to violate these
        !           377: conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
        !           378: ALL behavior observed from other hosts.
        !           379: 
        !           380: 2.3.1. Preferred name syntax
        !           381: 
        !           382: The DNS specifications attempt to be as general as possible in the rules
        !           383: for constructing domain names.  The idea is that the name of any
        !           384: existing object can be expressed as a domain name with minimal changes.
        !           385: 
        !           386: 
        !           387: 
        !           388: Mockapetris                                                     [Page 7]
        !           389: 
        !           390: RFC 1035        Domain Implementation and Specification    November 1987
        !           391: 
        !           392: 
        !           393: However, when assigning a domain name for an object, the prudent user
        !           394: will select a name which satisfies both the rules of the domain system
        !           395: and any existing rules for the object, whether these rules are published
        !           396: or implied by existing programs.
        !           397: 
        !           398: For example, when naming a mail domain, the user should satisfy both the
        !           399: rules of this memo and those in RFC-822.  When creating a new host name,
        !           400: the old rules for HOSTS.TXT should be followed.  This avoids problems
        !           401: when old software is converted to use domain names.
        !           402: 
        !           403: The following syntax will result in fewer problems with many
        !           404: 
        !           405: applications that use domain names (e.g., mail, TELNET).
        !           406: 
        !           407: <domain> ::= <subdomain> | " "
        !           408: 
        !           409: <subdomain> ::= <label> | <subdomain> "." <label>
        !           410: 
        !           411: <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
        !           412: 
        !           413: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
        !           414: 
        !           415: <let-dig-hyp> ::= <let-dig> | "-"
        !           416: 
        !           417: <let-dig> ::= <letter> | <digit>
        !           418: 
        !           419: <letter> ::= any one of the 52 alphabetic characters A through Z in
        !           420: upper case and a through z in lower case
        !           421: 
        !           422: <digit> ::= any one of the ten digits 0 through 9
        !           423: 
        !           424: Note that while upper and lower case letters are allowed in domain
        !           425: names, no significance is attached to the case.  That is, two names with
        !           426: the same spelling but different case are to be treated as if identical.
        !           427: 
        !           428: The labels must follow the rules for ARPANET host names.  They must
        !           429: start with a letter, end with a letter or digit, and have as interior
        !           430: characters only letters, digits, and hyphen.  There are also some
        !           431: restrictions on the length.  Labels must be 63 characters or less.
        !           432: 
        !           433: For example, the following strings identify hosts in the Internet:
        !           434: 
        !           435: A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
        !           436: 
        !           437: 2.3.2. Data Transmission Order
        !           438: 
        !           439: The order of transmission of the header and data described in this
        !           440: document is resolved to the octet level.  Whenever a diagram shows a
        !           441: 
        !           442: 
        !           443: 
        !           444: Mockapetris                                                     [Page 8]
        !           445: 
        !           446: RFC 1035        Domain Implementation and Specification    November 1987
        !           447: 
        !           448: 
        !           449: group of octets, the order of transmission of those octets is the normal
        !           450: order in which they are read in English.  For example, in the following
        !           451: diagram, the octets are transmitted in the order they are numbered.
        !           452: 
        !           453:      0                   1
        !           454:      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        !           455:     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !           456:     |       1       |       2       |
        !           457:     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !           458:     |       3       |       4       |
        !           459:     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !           460:     |       5       |       6       |
        !           461:     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !           462: 
        !           463: Whenever an octet represents a numeric quantity, the left most bit in
        !           464: the diagram is the high order or most significant bit.  That is, the bit
        !           465: labeled 0 is the most significant bit.  For example, the following
        !           466: diagram represents the value 170 (decimal).
        !           467: 
        !           468:      0 1 2 3 4 5 6 7
        !           469:     +-+-+-+-+-+-+-+-+
        !           470:     |1 0 1 0 1 0 1 0|
        !           471:     +-+-+-+-+-+-+-+-+
        !           472: 
        !           473: Similarly, whenever a multi-octet field represents a numeric quantity
        !           474: the left most bit of the whole field is the most significant bit.  When
        !           475: a multi-octet quantity is transmitted the most significant octet is
        !           476: transmitted first.
        !           477: 
        !           478: 2.3.3. Character Case
        !           479: 
        !           480: For all parts of the DNS that are part of the official protocol, all
        !           481: comparisons between character strings (e.g., labels, domain names, etc.)
        !           482: are done in a case-insensitive manner.  At present, this rule is in
        !           483: force throughout the domain system without exception.  However, future
        !           484: additions beyond current usage may need to use the full binary octet
        !           485: capabilities in names, so attempts to store domain names in 7-bit ASCII
        !           486: or use of special bytes to terminate labels, etc., should be avoided.
        !           487: 
        !           488: When data enters the domain system, its original case should be
        !           489: preserved whenever possible.  In certain circumstances this cannot be
        !           490: done.  For example, if two RRs are stored in a database, one at x.y and
        !           491: one at X.Y, they are actually stored at the same place in the database,
        !           492: and hence only one casing would be preserved.  The basic rule is that
        !           493: case can be discarded only when data is used to define structure in a
        !           494: database, and two names are identical when compared in a case
        !           495: insensitive manner.
        !           496: 
        !           497: 
        !           498: 
        !           499: 
        !           500: Mockapetris                                                     [Page 9]
        !           501: 
        !           502: RFC 1035        Domain Implementation and Specification    November 1987
        !           503: 
        !           504: 
        !           505: Loss of case sensitive data must be minimized.  Thus while data for x.y
        !           506: and X.Y may both be stored under a single location x.y or X.Y, data for
        !           507: a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
        !           508: general, this preserves the case of the first label of a domain name,
        !           509: but forces standardization of interior node labels.
        !           510: 
        !           511: Systems administrators who enter data into the domain database should
        !           512: take care to represent the data they supply to the domain system in a
        !           513: case-consistent manner if their system is case-sensitive.  The data
        !           514: distribution system in the domain system will ensure that consistent
        !           515: representations are preserved.
        !           516: 
        !           517: 2.3.4. Size limits
        !           518: 
        !           519: Various objects and parameters in the DNS have size limits.  They are
        !           520: listed below.  Some could be easily changed, others are more
        !           521: fundamental.
        !           522: 
        !           523: labels          63 octets or less
        !           524: 
        !           525: names           255 octets or less
        !           526: 
        !           527: TTL             positive values of a signed 32 bit number.
        !           528: 
        !           529: UDP messages    512 octets or less
        !           530: 
        !           531: 3. DOMAIN NAME SPACE AND RR DEFINITIONS
        !           532: 
        !           533: 3.1. Name space definitions
        !           534: 
        !           535: Domain names in messages are expressed in terms of a sequence of labels.
        !           536: Each label is represented as a one octet length field followed by that
        !           537: number of octets.  Since every domain name ends with the null label of
        !           538: the root, a domain name is terminated by a length byte of zero.  The
        !           539: high order two bits of every length octet must be zero, and the
        !           540: remaining six bits of the length field limit the label to 63 octets or
        !           541: less.
        !           542: 
        !           543: To simplify implementations, the total length of a domain name (i.e.,
        !           544: label octets and label length octets) is restricted to 255 octets or
        !           545: less.
        !           546: 
        !           547: Although labels can contain any 8 bit values in octets that make up a
        !           548: label, it is strongly recommended that labels follow the preferred
        !           549: syntax described elsewhere in this memo, which is compatible with
        !           550: existing host naming conventions.  Name servers and resolvers must
        !           551: compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
        !           552: with zero parity.  Non-alphabetic codes must match exactly.
        !           553: 
        !           554: 
        !           555: 
        !           556: Mockapetris                                                    [Page 10]
        !           557: 
        !           558: RFC 1035        Domain Implementation and Specification    November 1987
        !           559: 
        !           560: 
        !           561: 3.2. RR definitions
        !           562: 
        !           563: 3.2.1. Format
        !           564: 
        !           565: All RRs have the same top level format shown below:
        !           566: 
        !           567:                                     1  1  1  1  1  1
        !           568:       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        !           569:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           570:     |                                               |
        !           571:     /                                               /
        !           572:     /                      NAME                     /
        !           573:     |                                               |
        !           574:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           575:     |                      TYPE                     |
        !           576:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           577:     |                     CLASS                     |
        !           578:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           579:     |                      TTL                      |
        !           580:     |                                               |
        !           581:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           582:     |                   RDLENGTH                    |
        !           583:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
        !           584:     /                     RDATA                     /
        !           585:     /                                               /
        !           586:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           587: 
        !           588: 
        !           589: where:
        !           590: 
        !           591: NAME            an owner name, i.e., the name of the node to which this
        !           592:                 resource record pertains.
        !           593: 
        !           594: TYPE            two octets containing one of the RR TYPE codes.
        !           595: 
        !           596: CLASS           two octets containing one of the RR CLASS codes.
        !           597: 
        !           598: TTL             a 32 bit signed integer that specifies the time interval
        !           599:                 that the resource record may be cached before the source
        !           600:                 of the information should again be consulted.  Zero
        !           601:                 values are interpreted to mean that the RR can only be
        !           602:                 used for the transaction in progress, and should not be
        !           603:                 cached.  For example, SOA records are always distributed
        !           604:                 with a zero TTL to prohibit caching.  Zero values can
        !           605:                 also be used for extremely volatile data.
        !           606: 
        !           607: RDLENGTH        an unsigned 16 bit integer that specifies the length in
        !           608:                 octets of the RDATA field.
        !           609: 
        !           610: 
        !           611: 
        !           612: Mockapetris                                                    [Page 11]
        !           613: 
        !           614: RFC 1035        Domain Implementation and Specification    November 1987
        !           615: 
        !           616: 
        !           617: RDATA           a variable length string of octets that describes the
        !           618:                 resource.  The format of this information varies
        !           619:                 according to the TYPE and CLASS of the resource record.
        !           620: 
        !           621: 3.2.2. TYPE values
        !           622: 
        !           623: TYPE fields are used in resource records.  Note that these types are a
        !           624: subset of QTYPEs.
        !           625: 
        !           626: TYPE            value and meaning
        !           627: 
        !           628: A               1 a host address
        !           629: 
        !           630: NS              2 an authoritative name server
        !           631: 
        !           632: MD              3 a mail destination (Obsolete - use MX)
        !           633: 
        !           634: MF              4 a mail forwarder (Obsolete - use MX)
        !           635: 
        !           636: CNAME           5 the canonical name for an alias
        !           637: 
        !           638: SOA             6 marks the start of a zone of authority
        !           639: 
        !           640: MB              7 a mailbox domain name (EXPERIMENTAL)
        !           641: 
        !           642: MG              8 a mail group member (EXPERIMENTAL)
        !           643: 
        !           644: MR              9 a mail rename domain name (EXPERIMENTAL)
        !           645: 
        !           646: NULL            10 a null RR (EXPERIMENTAL)
        !           647: 
        !           648: WKS             11 a well known service description
        !           649: 
        !           650: PTR             12 a domain name pointer
        !           651: 
        !           652: HINFO           13 host information
        !           653: 
        !           654: MINFO           14 mailbox or mail list information
        !           655: 
        !           656: MX              15 mail exchange
        !           657: 
        !           658: TXT             16 text strings
        !           659: 
        !           660: 3.2.3. QTYPE values
        !           661: 
        !           662: QTYPE fields appear in the question part of a query.  QTYPES are a
        !           663: superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
        !           664: following QTYPEs are defined:
        !           665: 
        !           666: 
        !           667: 
        !           668: Mockapetris                                                    [Page 12]
        !           669: 
        !           670: RFC 1035        Domain Implementation and Specification    November 1987
        !           671: 
        !           672: 
        !           673: AXFR            252 A request for a transfer of an entire zone
        !           674: 
        !           675: MAILB           253 A request for mailbox-related records (MB, MG or MR)
        !           676: 
        !           677: MAILA           254 A request for mail agent RRs (Obsolete - see MX)
        !           678: 
        !           679: *               255 A request for all records
        !           680: 
        !           681: 3.2.4. CLASS values
        !           682: 
        !           683: CLASS fields appear in resource records.  The following CLASS mnemonics
        !           684: and values are defined:
        !           685: 
        !           686: IN              1 the Internet
        !           687: 
        !           688: CS              2 the CSNET class (Obsolete - used only for examples in
        !           689:                 some obsolete RFCs)
        !           690: 
        !           691: CH              3 the CHAOS class
        !           692: 
        !           693: HS              4 Hesiod [Dyer 87]
        !           694: 
        !           695: 3.2.5. QCLASS values
        !           696: 
        !           697: QCLASS fields appear in the question section of a query.  QCLASS values
        !           698: are a superset of CLASS values; every CLASS is a valid QCLASS.  In
        !           699: addition to CLASS values, the following QCLASSes are defined:
        !           700: 
        !           701: *               255 any class
        !           702: 
        !           703: 3.3. Standard RRs
        !           704: 
        !           705: The following RR definitions are expected to occur, at least
        !           706: potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
        !           707: will be used in all classes, and have the same format in all classes.
        !           708: Because their RDATA format is known, all domain names in the RDATA
        !           709: section of these RRs may be compressed.
        !           710: 
        !           711: <domain-name> is a domain name represented as a series of labels, and
        !           712: terminated by a label with zero length.  <character-string> is a single
        !           713: length octet followed by that number of characters.  <character-string>
        !           714: is treated as binary information, and can be up to 256 characters in
        !           715: length (including the length octet).
        !           716: 
        !           717: 
        !           718: 
        !           719: 
        !           720: 
        !           721: 
        !           722: 
        !           723: 
        !           724: Mockapetris                                                    [Page 13]
        !           725: 
        !           726: RFC 1035        Domain Implementation and Specification    November 1987
        !           727: 
        !           728: 
        !           729: 3.3.1. CNAME RDATA format
        !           730: 
        !           731:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           732:     /                     CNAME                     /
        !           733:     /                                               /
        !           734:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           735: 
        !           736: where:
        !           737: 
        !           738: CNAME           A <domain-name> which specifies the canonical or primary
        !           739:                 name for the owner.  The owner name is an alias.
        !           740: 
        !           741: CNAME RRs cause no additional section processing, but name servers may
        !           742: choose to restart the query at the canonical name in certain cases.  See
        !           743: the description of name server logic in [RFC-1034] for details.
        !           744: 
        !           745: 3.3.2. HINFO RDATA format
        !           746: 
        !           747:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           748:     /                      CPU                      /
        !           749:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           750:     /                       OS                      /
        !           751:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           752: 
        !           753: where:
        !           754: 
        !           755: CPU             A <character-string> which specifies the CPU type.
        !           756: 
        !           757: OS              A <character-string> which specifies the operating
        !           758:                 system type.
        !           759: 
        !           760: Standard values for CPU and OS can be found in [RFC-1010].
        !           761: 
        !           762: HINFO records are used to acquire general information about a host.  The
        !           763: main use is for protocols such as FTP that can use special procedures
        !           764: when talking between machines or operating systems of the same type.
        !           765: 
        !           766: 3.3.3. MB RDATA format (EXPERIMENTAL)
        !           767: 
        !           768:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           769:     /                   MADNAME                     /
        !           770:     /                                               /
        !           771:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           772: 
        !           773: where:
        !           774: 
        !           775: MADNAME         A <domain-name> which specifies a host which has the
        !           776:                 specified mailbox.
        !           777: 
        !           778: 
        !           779: 
        !           780: Mockapetris                                                    [Page 14]
        !           781: 
        !           782: RFC 1035        Domain Implementation and Specification    November 1987
        !           783: 
        !           784: 
        !           785: MB records cause additional section processing which looks up an A type
        !           786: RRs corresponding to MADNAME.
        !           787: 
        !           788: 3.3.4. MD RDATA format (Obsolete)
        !           789: 
        !           790:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           791:     /                   MADNAME                     /
        !           792:     /                                               /
        !           793:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           794: 
        !           795: where:
        !           796: 
        !           797: MADNAME         A <domain-name> which specifies a host which has a mail
        !           798:                 agent for the domain which should be able to deliver
        !           799:                 mail for the domain.
        !           800: 
        !           801: MD records cause additional section processing which looks up an A type
        !           802: record corresponding to MADNAME.
        !           803: 
        !           804: MD is obsolete.  See the definition of MX and [RFC-974] for details of
        !           805: the new scheme.  The recommended policy for dealing with MD RRs found in
        !           806: a master file is to reject them, or to convert them to MX RRs with a
        !           807: preference of 0.
        !           808: 
        !           809: 3.3.5. MF RDATA format (Obsolete)
        !           810: 
        !           811:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           812:     /                   MADNAME                     /
        !           813:     /                                               /
        !           814:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           815: 
        !           816: where:
        !           817: 
        !           818: MADNAME         A <domain-name> which specifies a host which has a mail
        !           819:                 agent for the domain which will accept mail for
        !           820:                 forwarding to the domain.
        !           821: 
        !           822: MF records cause additional section processing which looks up an A type
        !           823: record corresponding to MADNAME.
        !           824: 
        !           825: MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
        !           826: the new scheme.  The recommended policy for dealing with MD RRs found in
        !           827: a master file is to reject them, or to convert them to MX RRs with a
        !           828: preference of 10.
        !           829: 
        !           830: 
        !           831: 
        !           832: 
        !           833: 
        !           834: 
        !           835: 
        !           836: Mockapetris                                                    [Page 15]
        !           837: 
        !           838: RFC 1035        Domain Implementation and Specification    November 1987
        !           839: 
        !           840: 
        !           841: 3.3.6. MG RDATA format (EXPERIMENTAL)
        !           842: 
        !           843:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           844:     /                   MGMNAME                     /
        !           845:     /                                               /
        !           846:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           847: 
        !           848: where:
        !           849: 
        !           850: MGMNAME         A <domain-name> which specifies a mailbox which is a
        !           851:                 member of the mail group specified by the domain name.
        !           852: 
        !           853: MG records cause no additional section processing.
        !           854: 
        !           855: 3.3.7. MINFO RDATA format (EXPERIMENTAL)
        !           856: 
        !           857:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           858:     /                    RMAILBX                    /
        !           859:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           860:     /                    EMAILBX                    /
        !           861:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           862: 
        !           863: where:
        !           864: 
        !           865: RMAILBX         A <domain-name> which specifies a mailbox which is
        !           866:                 responsible for the mailing list or mailbox.  If this
        !           867:                 domain name names the root, the owner of the MINFO RR is
        !           868:                 responsible for itself.  Note that many existing mailing
        !           869:                 lists use a mailbox X-request for the RMAILBX field of
        !           870:                 mailing list X, e.g., Msgroup-request for Msgroup.  This
        !           871:                 field provides a more general mechanism.
        !           872: 
        !           873: 
        !           874: EMAILBX         A <domain-name> which specifies a mailbox which is to
        !           875:                 receive error messages related to the mailing list or
        !           876:                 mailbox specified by the owner of the MINFO RR (similar
        !           877:                 to the ERRORS-TO: field which has been proposed).  If
        !           878:                 this domain name names the root, errors should be
        !           879:                 returned to the sender of the message.
        !           880: 
        !           881: MINFO records cause no additional section processing.  Although these
        !           882: records can be associated with a simple mailbox, they are usually used
        !           883: with a mailing list.
        !           884: 
        !           885: 
        !           886: 
        !           887: 
        !           888: 
        !           889: 
        !           890: 
        !           891: 
        !           892: Mockapetris                                                    [Page 16]
        !           893: 
        !           894: RFC 1035        Domain Implementation and Specification    November 1987
        !           895: 
        !           896: 
        !           897: 3.3.8. MR RDATA format (EXPERIMENTAL)
        !           898: 
        !           899:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           900:     /                   NEWNAME                     /
        !           901:     /                                               /
        !           902:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           903: 
        !           904: where:
        !           905: 
        !           906: NEWNAME         A <domain-name> which specifies a mailbox which is the
        !           907:                 proper rename of the specified mailbox.
        !           908: 
        !           909: MR records cause no additional section processing.  The main use for MR
        !           910: is as a forwarding entry for a user who has moved to a different
        !           911: mailbox.
        !           912: 
        !           913: 3.3.9. MX RDATA format
        !           914: 
        !           915:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           916:     |                  PREFERENCE                   |
        !           917:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           918:     /                   EXCHANGE                    /
        !           919:     /                                               /
        !           920:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           921: 
        !           922: where:
        !           923: 
        !           924: PREFERENCE      A 16 bit integer which specifies the preference given to
        !           925:                 this RR among others at the same owner.  Lower values
        !           926:                 are preferred.
        !           927: 
        !           928: EXCHANGE        A <domain-name> which specifies a host willing to act as
        !           929:                 a mail exchange for the owner name.
        !           930: 
        !           931: MX records cause type A additional section processing for the host
        !           932: specified by EXCHANGE.  The use of MX RRs is explained in detail in
        !           933: [RFC-974].
        !           934: 
        !           935: 3.3.10. NULL RDATA format (EXPERIMENTAL)
        !           936: 
        !           937:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           938:     /                  <anything>                   /
        !           939:     /                                               /
        !           940:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           941: 
        !           942: Anything at all may be in the RDATA field so long as it is 65535 octets
        !           943: or less.
        !           944: 
        !           945: 
        !           946: 
        !           947: 
        !           948: Mockapetris                                                    [Page 17]
        !           949: 
        !           950: RFC 1035        Domain Implementation and Specification    November 1987
        !           951: 
        !           952: 
        !           953: NULL records cause no additional section processing.  NULL RRs are not
        !           954: allowed in master files.  NULLs are used as placeholders in some
        !           955: experimental extensions of the DNS.
        !           956: 
        !           957: 3.3.11. NS RDATA format
        !           958: 
        !           959:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           960:     /                   NSDNAME                     /
        !           961:     /                                               /
        !           962:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           963: 
        !           964: where:
        !           965: 
        !           966: NSDNAME         A <domain-name> which specifies a host which should be
        !           967:                 authoritative for the specified class and domain.
        !           968: 
        !           969: NS records cause both the usual additional section processing to locate
        !           970: a type A record, and, when used in a referral, a special search of the
        !           971: zone in which they reside for glue information.
        !           972: 
        !           973: The NS RR states that the named host should be expected to have a zone
        !           974: starting at owner name of the specified class.  Note that the class may
        !           975: not indicate the protocol family which should be used to communicate
        !           976: with the host, although it is typically a strong hint.  For example,
        !           977: hosts which are name servers for either Internet (IN) or Hesiod (HS)
        !           978: class information are normally queried using IN class protocols.
        !           979: 
        !           980: 3.3.12. PTR RDATA format
        !           981: 
        !           982:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           983:     /                   PTRDNAME                    /
        !           984:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !           985: 
        !           986: where:
        !           987: 
        !           988: PTRDNAME        A <domain-name> which points to some location in the
        !           989:                 domain name space.
        !           990: 
        !           991: PTR records cause no additional section processing.  These RRs are used
        !           992: in special domains to point to some other location in the domain space.
        !           993: These records are simple data, and don't imply any special processing
        !           994: similar to that performed by CNAME, which identifies aliases.  See the
        !           995: description of the IN-ADDR.ARPA domain for an example.
        !           996: 
        !           997: 
        !           998: 
        !           999: 
        !          1000: 
        !          1001: 
        !          1002: 
        !          1003: 
        !          1004: Mockapetris                                                    [Page 18]
        !          1005: 
        !          1006: RFC 1035        Domain Implementation and Specification    November 1987
        !          1007: 
        !          1008: 
        !          1009: 3.3.13. SOA RDATA format
        !          1010: 
        !          1011:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1012:     /                     MNAME                     /
        !          1013:     /                                               /
        !          1014:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1015:     /                     RNAME                     /
        !          1016:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1017:     |                    SERIAL                     |
        !          1018:     |                                               |
        !          1019:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1020:     |                    REFRESH                    |
        !          1021:     |                                               |
        !          1022:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1023:     |                     RETRY                     |
        !          1024:     |                                               |
        !          1025:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1026:     |                    EXPIRE                     |
        !          1027:     |                                               |
        !          1028:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1029:     |                    MINIMUM                    |
        !          1030:     |                                               |
        !          1031:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1032: 
        !          1033: where:
        !          1034: 
        !          1035: MNAME           The <domain-name> of the name server that was the
        !          1036:                 original or primary source of data for this zone.
        !          1037: 
        !          1038: RNAME           A <domain-name> which specifies the mailbox of the
        !          1039:                 person responsible for this zone.
        !          1040: 
        !          1041: SERIAL          The unsigned 32 bit version number of the original copy
        !          1042:                 of the zone.  Zone transfers preserve this value.  This
        !          1043:                 value wraps and should be compared using sequence space
        !          1044:                 arithmetic.
        !          1045: 
        !          1046: REFRESH         A 32 bit time interval before the zone should be
        !          1047:                 refreshed.
        !          1048: 
        !          1049: RETRY           A 32 bit time interval that should elapse before a
        !          1050:                 failed refresh should be retried.
        !          1051: 
        !          1052: EXPIRE          A 32 bit time value that specifies the upper limit on
        !          1053:                 the time interval that can elapse before the zone is no
        !          1054:                 longer authoritative.
        !          1055: 
        !          1056: 
        !          1057: 
        !          1058: 
        !          1059: 
        !          1060: Mockapetris                                                    [Page 19]
        !          1061: 
        !          1062: RFC 1035        Domain Implementation and Specification    November 1987
        !          1063: 
        !          1064: 
        !          1065: MINIMUM         The unsigned 32 bit minimum TTL field that should be
        !          1066:                 exported with any RR from this zone.
        !          1067: 
        !          1068: SOA records cause no additional section processing.
        !          1069: 
        !          1070: All times are in units of seconds.
        !          1071: 
        !          1072: Most of these fields are pertinent only for name server maintenance
        !          1073: operations.  However, MINIMUM is used in all query operations that
        !          1074: retrieve RRs from a zone.  Whenever a RR is sent in a response to a
        !          1075: query, the TTL field is set to the maximum of the TTL field from the RR
        !          1076: and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
        !          1077: bound on the TTL field for all RRs in a zone.  Note that this use of
        !          1078: MINIMUM should occur when the RRs are copied into the response and not
        !          1079: when the zone is loaded from a master file or via a zone transfer.  The
        !          1080: reason for this provison is to allow future dynamic update facilities to
        !          1081: change the SOA RR with known semantics.
        !          1082: 
        !          1083: 
        !          1084: 3.3.14. TXT RDATA format
        !          1085: 
        !          1086:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1087:     /                   TXT-DATA                    /
        !          1088:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1089: 
        !          1090: where:
        !          1091: 
        !          1092: TXT-DATA        One or more <character-string>s.
        !          1093: 
        !          1094: TXT RRs are used to hold descriptive text.  The semantics of the text
        !          1095: depends on the domain where it is found.
        !          1096: 
        !          1097: 3.4. Internet specific RRs
        !          1098: 
        !          1099: 3.4.1. A RDATA format
        !          1100: 
        !          1101:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1102:     |                    ADDRESS                    |
        !          1103:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1104: 
        !          1105: where:
        !          1106: 
        !          1107: ADDRESS         A 32 bit Internet address.
        !          1108: 
        !          1109: Hosts that have multiple Internet addresses will have multiple A
        !          1110: records.
        !          1111: 
        !          1112: 
        !          1113: 
        !          1114: 
        !          1115: 
        !          1116: Mockapetris                                                    [Page 20]
        !          1117: 
        !          1118: RFC 1035        Domain Implementation and Specification    November 1987
        !          1119: 
        !          1120: 
        !          1121: A records cause no additional section processing.  The RDATA section of
        !          1122: an A line in a master file is an Internet address expressed as four
        !          1123: decimal numbers separated by dots without any imbedded spaces (e.g.,
        !          1124: "10.2.0.52" or "192.0.5.6").
        !          1125: 
        !          1126: 3.4.2. WKS RDATA format
        !          1127: 
        !          1128:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1129:     |                    ADDRESS                    |
        !          1130:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1131:     |       PROTOCOL        |                       |
        !          1132:     +--+--+--+--+--+--+--+--+                       |
        !          1133:     |                                               |
        !          1134:     /                   <BIT MAP>                   /
        !          1135:     /                                               /
        !          1136:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1137: 
        !          1138: where:
        !          1139: 
        !          1140: ADDRESS         An 32 bit Internet address
        !          1141: 
        !          1142: PROTOCOL        An 8 bit IP protocol number
        !          1143: 
        !          1144: <BIT MAP>       A variable length bit map.  The bit map must be a
        !          1145:                 multiple of 8 bits long.
        !          1146: 
        !          1147: The WKS record is used to describe the well known services supported by
        !          1148: a particular protocol on a particular internet address.  The PROTOCOL
        !          1149: field specifies an IP protocol number, and the bit map has one bit per
        !          1150: port of the specified protocol.  The first bit corresponds to port 0,
        !          1151: the second to port 1, etc.  If the bit map does not include a bit for a
        !          1152: protocol of interest, that bit is assumed zero.  The appropriate values
        !          1153: and mnemonics for ports and protocols are specified in [RFC-1010].
        !          1154: 
        !          1155: For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
        !          1156: 25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
        !          1157: port 25; if zero, SMTP service is not supported on the specified
        !          1158: address.
        !          1159: 
        !          1160: The purpose of WKS RRs is to provide availability information for
        !          1161: servers for TCP and UDP.  If a server supports both TCP and UDP, or has
        !          1162: multiple Internet addresses, then multiple WKS RRs are used.
        !          1163: 
        !          1164: WKS RRs cause no additional section processing.
        !          1165: 
        !          1166: In master files, both ports and protocols are expressed using mnemonics
        !          1167: or decimal numbers.
        !          1168: 
        !          1169: 
        !          1170: 
        !          1171: 
        !          1172: Mockapetris                                                    [Page 21]
        !          1173: 
        !          1174: RFC 1035        Domain Implementation and Specification    November 1987
        !          1175: 
        !          1176: 
        !          1177: 3.5. IN-ADDR.ARPA domain
        !          1178: 
        !          1179: The Internet uses a special domain to support gateway location and
        !          1180: Internet address to host mapping.  Other classes may employ a similar
        !          1181: strategy in other domains.  The intent of this domain is to provide a
        !          1182: guaranteed method to perform host address to host name mapping, and to
        !          1183: facilitate queries to locate all gateways on a particular network in the
        !          1184: Internet.
        !          1185: 
        !          1186: Note that both of these services are similar to functions that could be
        !          1187: performed by inverse queries; the difference is that this part of the
        !          1188: domain name space is structured according to address, and hence can
        !          1189: guarantee that the appropriate data can be located without an exhaustive
        !          1190: search of the domain space.
        !          1191: 
        !          1192: The domain begins at IN-ADDR.ARPA and has a substructure which follows
        !          1193: the Internet addressing structure.
        !          1194: 
        !          1195: Domain names in the IN-ADDR.ARPA domain are defined to have up to four
        !          1196: labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
        !          1197: one octet of an Internet address, and is expressed as a character string
        !          1198: for a decimal value in the range 0-255 (with leading zeros omitted
        !          1199: except in the case of a zero octet which is represented by a single
        !          1200: zero).
        !          1201: 
        !          1202: Host addresses are represented by domain names that have all four labels
        !          1203: specified.  Thus data for Internet address 10.2.0.52 is located at
        !          1204: domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
        !          1205: read, allows zones to be delegated which are exactly one network of
        !          1206: address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
        !          1207: data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
        !          1208: MILNET.  Address nodes are used to hold pointers to primary host names
        !          1209: in the normal domain space.
        !          1210: 
        !          1211: Network numbers correspond to some non-terminal nodes at various depths
        !          1212: in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
        !          1213: 2, or 3 octets.  Network nodes are used to hold pointers to the primary
        !          1214: host names of gateways attached to that network.  Since a gateway is, by
        !          1215: definition, on more than one network, it will typically have two or more
        !          1216: network nodes which point at it.  Gateways will also have host level
        !          1217: pointers at their fully qualified addresses.
        !          1218: 
        !          1219: Both the gateway pointers at network nodes and the normal host pointers
        !          1220: at full address nodes use the PTR RR to point back to the primary domain
        !          1221: names of the corresponding hosts.
        !          1222: 
        !          1223: For example, the IN-ADDR.ARPA domain will contain information about the
        !          1224: ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
        !          1225: 
        !          1226: 
        !          1227: 
        !          1228: Mockapetris                                                    [Page 22]
        !          1229: 
        !          1230: RFC 1035        Domain Implementation and Specification    November 1987
        !          1231: 
        !          1232: 
        !          1233: net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
        !          1234: gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
        !          1235: GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
        !          1236: and a name GW.LCS.MIT.EDU, the domain database would contain:
        !          1237: 
        !          1238:     10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
        !          1239:     10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
        !          1240:     18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
        !          1241:     26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
        !          1242:     22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
        !          1243:     103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
        !          1244:     77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
        !          1245:     4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
        !          1246:     103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
        !          1247:     6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
        !          1248: 
        !          1249: Thus a program which wanted to locate gateways on net 10 would originate
        !          1250: a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
        !          1251: would receive two RRs in response:
        !          1252: 
        !          1253:     10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
        !          1254:     10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
        !          1255: 
        !          1256: The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
        !          1257: GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
        !          1258: these gateways.
        !          1259: 
        !          1260: A resolver which wanted to find the host name corresponding to Internet
        !          1261: host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
        !          1262: QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
        !          1263: 
        !          1264:     6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
        !          1265: 
        !          1266: Several cautions apply to the use of these services:
        !          1267:    - Since the IN-ADDR.ARPA special domain and the normal domain
        !          1268:      for a particular host or gateway will be in different zones,
        !          1269:      the possibility exists that that the data may be inconsistent.
        !          1270: 
        !          1271:    - Gateways will often have two names in separate domains, only
        !          1272:      one of which can be primary.
        !          1273: 
        !          1274:    - Systems that use the domain database to initialize their
        !          1275:      routing tables must start with enough gateway information to
        !          1276:      guarantee that they can access the appropriate name server.
        !          1277: 
        !          1278:    - The gateway data only reflects the existence of a gateway in a
        !          1279:      manner equivalent to the current HOSTS.TXT file.  It doesn't
        !          1280:      replace the dynamic availability information from GGP or EGP.
        !          1281: 
        !          1282: 
        !          1283: 
        !          1284: Mockapetris                                                    [Page 23]
        !          1285: 
        !          1286: RFC 1035        Domain Implementation and Specification    November 1987
        !          1287: 
        !          1288: 
        !          1289: 3.6. Defining new types, classes, and special namespaces
        !          1290: 
        !          1291: The previously defined types and classes are the ones in use as of the
        !          1292: date of this memo.  New definitions should be expected.  This section
        !          1293: makes some recommendations to designers considering additions to the
        !          1294: existing facilities.  The mailing list [email protected] is the
        !          1295: forum where general discussion of design issues takes place.
        !          1296: 
        !          1297: In general, a new type is appropriate when new information is to be
        !          1298: added to the database about an existing object, or we need new data
        !          1299: formats for some totally new object.  Designers should attempt to define
        !          1300: types and their RDATA formats that are generally applicable to all
        !          1301: classes, and which avoid duplication of information.  New classes are
        !          1302: appropriate when the DNS is to be used for a new protocol, etc which
        !          1303: requires new class-specific data formats, or when a copy of the existing
        !          1304: name space is desired, but a separate management domain is necessary.
        !          1305: 
        !          1306: New types and classes need mnemonics for master files; the format of the
        !          1307: master files requires that the mnemonics for type and class be disjoint.
        !          1308: 
        !          1309: TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
        !          1310: respectively.
        !          1311: 
        !          1312: The present system uses multiple RRs to represent multiple values of a
        !          1313: type rather than storing multiple values in the RDATA section of a
        !          1314: single RR.  This is less efficient for most applications, but does keep
        !          1315: RRs shorter.  The multiple RRs assumption is incorporated in some
        !          1316: experimental work on dynamic update methods.
        !          1317: 
        !          1318: The present system attempts to minimize the duplication of data in the
        !          1319: database in order to insure consistency.  Thus, in order to find the
        !          1320: address of the host for a mail exchange, you map the mail domain name to
        !          1321: a host name, then the host name to addresses, rather than a direct
        !          1322: mapping to host address.  This approach is preferred because it avoids
        !          1323: the opportunity for inconsistency.
        !          1324: 
        !          1325: In defining a new type of data, multiple RR types should not be used to
        !          1326: create an ordering between entries or express different formats for
        !          1327: equivalent bindings, instead this information should be carried in the
        !          1328: body of the RR and a single type used.  This policy avoids problems with
        !          1329: caching multiple types and defining QTYPEs to match multiple types.
        !          1330: 
        !          1331: For example, the original form of mail exchange binding used two RR
        !          1332: types one to represent a "closer" exchange (MD) and one to represent a
        !          1333: "less close" exchange (MF).  The difficulty is that the presence of one
        !          1334: RR type in a cache doesn't convey any information about the other
        !          1335: because the query which acquired the cached information might have used
        !          1336: a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
        !          1337: 
        !          1338: 
        !          1339: 
        !          1340: Mockapetris                                                    [Page 24]
        !          1341: 
        !          1342: RFC 1035        Domain Implementation and Specification    November 1987
        !          1343: 
        !          1344: 
        !          1345: service used a single type (MX) with a "preference" value in the RDATA
        !          1346: section which can order different RRs.  However, if any MX RRs are found
        !          1347: in the cache, then all should be there.
        !          1348: 
        !          1349: 4. MESSAGES
        !          1350: 
        !          1351: 4.1. Format
        !          1352: 
        !          1353: All communications inside of the domain protocol are carried in a single
        !          1354: format called a message.  The top level format of message is divided
        !          1355: into 5 sections (some of which are empty in certain cases) shown below:
        !          1356: 
        !          1357:     +---------------------+
        !          1358:     |        Header       |
        !          1359:     +---------------------+
        !          1360:     |       Question      | the question for the name server
        !          1361:     +---------------------+
        !          1362:     |        Answer       | RRs answering the question
        !          1363:     +---------------------+
        !          1364:     |      Authority      | RRs pointing toward an authority
        !          1365:     +---------------------+
        !          1366:     |      Additional     | RRs holding additional information
        !          1367:     +---------------------+
        !          1368: 
        !          1369: The header section is always present.  The header includes fields that
        !          1370: specify which of the remaining sections are present, and also specify
        !          1371: whether the message is a query or a response, a standard query or some
        !          1372: other opcode, etc.
        !          1373: 
        !          1374: The names of the sections after the header are derived from their use in
        !          1375: standard queries.  The question section contains fields that describe a
        !          1376: question to a name server.  These fields are a query type (QTYPE), a
        !          1377: query class (QCLASS), and a query domain name (QNAME).  The last three
        !          1378: sections have the same format: a possibly empty list of concatenated
        !          1379: resource records (RRs).  The answer section contains RRs that answer the
        !          1380: question; the authority section contains RRs that point toward an
        !          1381: authoritative name server; the additional records section contains RRs
        !          1382: which relate to the query, but are not strictly answers for the
        !          1383: question.
        !          1384: 
        !          1385: 
        !          1386: 
        !          1387: 
        !          1388: 
        !          1389: 
        !          1390: 
        !          1391: 
        !          1392: 
        !          1393: 
        !          1394: 
        !          1395: 
        !          1396: Mockapetris                                                    [Page 25]
        !          1397: 
        !          1398: RFC 1035        Domain Implementation and Specification    November 1987
        !          1399: 
        !          1400: 
        !          1401: 4.1.1. Header section format
        !          1402: 
        !          1403: The header contains the following fields:
        !          1404: 
        !          1405:                                     1  1  1  1  1  1
        !          1406:       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        !          1407:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1408:     |                      ID                       |
        !          1409:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1410:     |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
        !          1411:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1412:     |                    QDCOUNT                    |
        !          1413:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1414:     |                    ANCOUNT                    |
        !          1415:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1416:     |                    NSCOUNT                    |
        !          1417:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1418:     |                    ARCOUNT                    |
        !          1419:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1420: 
        !          1421: where:
        !          1422: 
        !          1423: ID              A 16 bit identifier assigned by the program that
        !          1424:                 generates any kind of query.  This identifier is copied
        !          1425:                 the corresponding reply and can be used by the requester
        !          1426:                 to match up replies to outstanding queries.
        !          1427: 
        !          1428: QR              A one bit field that specifies whether this message is a
        !          1429:                 query (0), or a response (1).
        !          1430: 
        !          1431: OPCODE          A four bit field that specifies kind of query in this
        !          1432:                 message.  This value is set by the originator of a query
        !          1433:                 and copied into the response.  The values are:
        !          1434: 
        !          1435:                 0               a standard query (QUERY)
        !          1436: 
        !          1437:                 1               an inverse query (IQUERY)
        !          1438: 
        !          1439:                 2               a server status request (STATUS)
        !          1440: 
        !          1441:                 3-15            reserved for future use
        !          1442: 
        !          1443: AA              Authoritative Answer - this bit is valid in responses,
        !          1444:                 and specifies that the responding name server is an
        !          1445:                 authority for the domain name in question section.
        !          1446: 
        !          1447:                 Note that the contents of the answer section may have
        !          1448:                 multiple owner names because of aliases.  The AA bit
        !          1449: 
        !          1450: 
        !          1451: 
        !          1452: Mockapetris                                                    [Page 26]
        !          1453: 
        !          1454: RFC 1035        Domain Implementation and Specification    November 1987
        !          1455: 
        !          1456: 
        !          1457:                 corresponds to the name which matches the query name, or
        !          1458:                 the first owner name in the answer section.
        !          1459: 
        !          1460: TC              TrunCation - specifies that this message was truncated
        !          1461:                 due to length greater than that permitted on the
        !          1462:                 transmission channel.
        !          1463: 
        !          1464: RD              Recursion Desired - this bit may be set in a query and
        !          1465:                 is copied into the response.  If RD is set, it directs
        !          1466:                 the name server to pursue the query recursively.
        !          1467:                 Recursive query support is optional.
        !          1468: 
        !          1469: RA              Recursion Available - this be is set or cleared in a
        !          1470:                 response, and denotes whether recursive query support is
        !          1471:                 available in the name server.
        !          1472: 
        !          1473: Z               Reserved for future use.  Must be zero in all queries
        !          1474:                 and responses.
        !          1475: 
        !          1476: RCODE           Response code - this 4 bit field is set as part of
        !          1477:                 responses.  The values have the following
        !          1478:                 interpretation:
        !          1479: 
        !          1480:                 0               No error condition
        !          1481: 
        !          1482:                 1               Format error - The name server was
        !          1483:                                 unable to interpret the query.
        !          1484: 
        !          1485:                 2               Server failure - The name server was
        !          1486:                                 unable to process this query due to a
        !          1487:                                 problem with the name server.
        !          1488: 
        !          1489:                 3               Name Error - Meaningful only for
        !          1490:                                 responses from an authoritative name
        !          1491:                                 server, this code signifies that the
        !          1492:                                 domain name referenced in the query does
        !          1493:                                 not exist.
        !          1494: 
        !          1495:                 4               Not Implemented - The name server does
        !          1496:                                 not support the requested kind of query.
        !          1497: 
        !          1498:                 5               Refused - The name server refuses to
        !          1499:                                 perform the specified operation for
        !          1500:                                 policy reasons.  For example, a name
        !          1501:                                 server may not wish to provide the
        !          1502:                                 information to the particular requester,
        !          1503:                                 or a name server may not wish to perform
        !          1504:                                 a particular operation (e.g., zone
        !          1505: 
        !          1506: 
        !          1507: 
        !          1508: Mockapetris                                                    [Page 27]
        !          1509: 
        !          1510: RFC 1035        Domain Implementation and Specification    November 1987
        !          1511: 
        !          1512: 
        !          1513:                                 transfer) for particular data.
        !          1514: 
        !          1515:                 6-15            Reserved for future use.
        !          1516: 
        !          1517: QDCOUNT         an unsigned 16 bit integer specifying the number of
        !          1518:                 entries in the question section.
        !          1519: 
        !          1520: ANCOUNT         an unsigned 16 bit integer specifying the number of
        !          1521:                 resource records in the answer section.
        !          1522: 
        !          1523: NSCOUNT         an unsigned 16 bit integer specifying the number of name
        !          1524:                 server resource records in the authority records
        !          1525:                 section.
        !          1526: 
        !          1527: ARCOUNT         an unsigned 16 bit integer specifying the number of
        !          1528:                 resource records in the additional records section.
        !          1529: 
        !          1530: 4.1.2. Question section format
        !          1531: 
        !          1532: The question section is used to carry the "question" in most queries,
        !          1533: i.e., the parameters that define what is being asked.  The section
        !          1534: contains QDCOUNT (usually 1) entries, each of the following format:
        !          1535: 
        !          1536:                                     1  1  1  1  1  1
        !          1537:       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        !          1538:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1539:     |                                               |
        !          1540:     /                     QNAME                     /
        !          1541:     /                                               /
        !          1542:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1543:     |                     QTYPE                     |
        !          1544:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1545:     |                     QCLASS                    |
        !          1546:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1547: 
        !          1548: where:
        !          1549: 
        !          1550: QNAME           a domain name represented as a sequence of labels, where
        !          1551:                 each label consists of a length octet followed by that
        !          1552:                 number of octets.  The domain name terminates with the
        !          1553:                 zero length octet for the null label of the root.  Note
        !          1554:                 that this field may be an odd number of octets; no
        !          1555:                 padding is used.
        !          1556: 
        !          1557: QTYPE           a two octet code which specifies the type of the query.
        !          1558:                 The values for this field include all codes valid for a
        !          1559:                 TYPE field, together with some more general codes which
        !          1560:                 can match more than one type of RR.
        !          1561: 
        !          1562: 
        !          1563: 
        !          1564: Mockapetris                                                    [Page 28]
        !          1565: 
        !          1566: RFC 1035        Domain Implementation and Specification    November 1987
        !          1567: 
        !          1568: 
        !          1569: QCLASS          a two octet code that specifies the class of the query.
        !          1570:                 For example, the QCLASS field is IN for the Internet.
        !          1571: 
        !          1572: 4.1.3. Resource record format
        !          1573: 
        !          1574: The answer, authority, and additional sections all share the same
        !          1575: format: a variable number of resource records, where the number of
        !          1576: records is specified in the corresponding count field in the header.
        !          1577: Each resource record has the following format:
        !          1578:                                     1  1  1  1  1  1
        !          1579:       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        !          1580:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1581:     |                                               |
        !          1582:     /                                               /
        !          1583:     /                      NAME                     /
        !          1584:     |                                               |
        !          1585:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1586:     |                      TYPE                     |
        !          1587:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1588:     |                     CLASS                     |
        !          1589:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1590:     |                      TTL                      |
        !          1591:     |                                               |
        !          1592:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1593:     |                   RDLENGTH                    |
        !          1594:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
        !          1595:     /                     RDATA                     /
        !          1596:     /                                               /
        !          1597:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1598: 
        !          1599: where:
        !          1600: 
        !          1601: NAME            a domain name to which this resource record pertains.
        !          1602: 
        !          1603: TYPE            two octets containing one of the RR type codes.  This
        !          1604:                 field specifies the meaning of the data in the RDATA
        !          1605:                 field.
        !          1606: 
        !          1607: CLASS           two octets which specify the class of the data in the
        !          1608:                 RDATA field.
        !          1609: 
        !          1610: TTL             a 32 bit unsigned integer that specifies the time
        !          1611:                 interval (in seconds) that the resource record may be
        !          1612:                 cached before it should be discarded.  Zero values are
        !          1613:                 interpreted to mean that the RR can only be used for the
        !          1614:                 transaction in progress, and should not be cached.
        !          1615: 
        !          1616: 
        !          1617: 
        !          1618: 
        !          1619: 
        !          1620: Mockapetris                                                    [Page 29]
        !          1621: 
        !          1622: RFC 1035        Domain Implementation and Specification    November 1987
        !          1623: 
        !          1624: 
        !          1625: RDLENGTH        an unsigned 16 bit integer that specifies the length in
        !          1626:                 octets of the RDATA field.
        !          1627: 
        !          1628: RDATA           a variable length string of octets that describes the
        !          1629:                 resource.  The format of this information varies
        !          1630:                 according to the TYPE and CLASS of the resource record.
        !          1631:                 For example, the if the TYPE is A and the CLASS is IN,
        !          1632:                 the RDATA field is a 4 octet ARPA Internet address.
        !          1633: 
        !          1634: 4.1.4. Message compression
        !          1635: 
        !          1636: In order to reduce the size of messages, the domain system utilizes a
        !          1637: compression scheme which eliminates the repetition of domain names in a
        !          1638: message.  In this scheme, an entire domain name or a list of labels at
        !          1639: the end of a domain name is replaced with a pointer to a prior occurance
        !          1640: of the same name.
        !          1641: 
        !          1642: The pointer takes the form of a two octet sequence:
        !          1643: 
        !          1644:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1645:     | 1  1|                OFFSET                   |
        !          1646:     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1647: 
        !          1648: The first two bits are ones.  This allows a pointer to be distinguished
        !          1649: from a label, since the label must begin with two zero bits because
        !          1650: labels are restricted to 63 octets or less.  (The 10 and 01 combinations
        !          1651: are reserved for future use.)  The OFFSET field specifies an offset from
        !          1652: the start of the message (i.e., the first octet of the ID field in the
        !          1653: domain header).  A zero offset specifies the first byte of the ID field,
        !          1654: etc.
        !          1655: 
        !          1656: The compression scheme allows a domain name in a message to be
        !          1657: represented as either:
        !          1658: 
        !          1659:    - a sequence of labels ending in a zero octet
        !          1660: 
        !          1661:    - a pointer
        !          1662: 
        !          1663:    - a sequence of labels ending with a pointer
        !          1664: 
        !          1665: Pointers can only be used for occurances of a domain name where the
        !          1666: format is not class specific.  If this were not the case, a name server
        !          1667: or resolver would be required to know the format of all RRs it handled.
        !          1668: As yet, there are no such cases, but they may occur in future RDATA
        !          1669: formats.
        !          1670: 
        !          1671: If a domain name is contained in a part of the message subject to a
        !          1672: length field (such as the RDATA section of an RR), and compression is
        !          1673: 
        !          1674: 
        !          1675: 
        !          1676: Mockapetris                                                    [Page 30]
        !          1677: 
        !          1678: RFC 1035        Domain Implementation and Specification    November 1987
        !          1679: 
        !          1680: 
        !          1681: used, the length of the compressed name is used in the length
        !          1682: calculation, rather than the length of the expanded name.
        !          1683: 
        !          1684: Programs are free to avoid using pointers in messages they generate,
        !          1685: although this will reduce datagram capacity, and may cause truncation.
        !          1686: However all programs are required to understand arriving messages that
        !          1687: contain pointers.
        !          1688: 
        !          1689: For example, a datagram might need to use the domain names F.ISI.ARPA,
        !          1690: FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
        !          1691: message, these domain names might be represented as:
        !          1692: 
        !          1693:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1694:     20 |           1           |           F           |
        !          1695:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1696:     22 |           3           |           I           |
        !          1697:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1698:     24 |           S           |           I           |
        !          1699:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1700:     26 |           4           |           A           |
        !          1701:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1702:     28 |           R           |           P           |
        !          1703:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1704:     30 |           A           |           0           |
        !          1705:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1706: 
        !          1707:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1708:     40 |           3           |           F           |
        !          1709:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1710:     42 |           O           |           O           |
        !          1711:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1712:     44 | 1  1|                20                       |
        !          1713:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1714: 
        !          1715:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1716:     64 | 1  1|                26                       |
        !          1717:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1718: 
        !          1719:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1720:     92 |           0           |                       |
        !          1721:        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        !          1722: 
        !          1723: The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
        !          1724: FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
        !          1725: concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
        !          1726: domain name ARPA is defined at offset 64 using a pointer to the ARPA
        !          1727: component of the name F.ISI.ARPA at 20; note that this pointer relies on
        !          1728: ARPA being the last label in the string at 20.  The root domain name is
        !          1729: 
        !          1730: 
        !          1731: 
        !          1732: Mockapetris                                                    [Page 31]
        !          1733: 
        !          1734: RFC 1035        Domain Implementation and Specification    November 1987
        !          1735: 
        !          1736: 
        !          1737: defined by a single octet of zeros at 92; the root domain name has no
        !          1738: labels.
        !          1739: 
        !          1740: 4.2. Transport
        !          1741: 
        !          1742: The DNS assumes that messages will be transmitted as datagrams or in a
        !          1743: byte stream carried by a virtual circuit.  While virtual circuits can be
        !          1744: used for any DNS activity, datagrams are preferred for queries due to
        !          1745: their lower overhead and better performance.  Zone refresh activities
        !          1746: must use virtual circuits because of the need for reliable transfer.
        !          1747: 
        !          1748: The Internet supports name server access using TCP [RFC-793] on server
        !          1749: port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
        !          1750: port 53 (decimal).
        !          1751: 
        !          1752: 4.2.1. UDP usage
        !          1753: 
        !          1754: Messages sent using UDP user server port 53 (decimal).
        !          1755: 
        !          1756: Messages carried by UDP are restricted to 512 bytes (not counting the IP
        !          1757: or UDP headers).  Longer messages are truncated and the TC bit is set in
        !          1758: the header.
        !          1759: 
        !          1760: UDP is not acceptable for zone transfers, but is the recommended method
        !          1761: for standard queries in the Internet.  Queries sent using UDP may be
        !          1762: lost, and hence a retransmission strategy is required.  Queries or their
        !          1763: responses may be reordered by the network, or by processing in name
        !          1764: servers, so resolvers should not depend on them being returned in order.
        !          1765: 
        !          1766: The optimal UDP retransmission policy will vary with performance of the
        !          1767: Internet and the needs of the client, but the following are recommended:
        !          1768: 
        !          1769:    - The client should try other servers and server addresses
        !          1770:      before repeating a query to a specific address of a server.
        !          1771: 
        !          1772:    - The retransmission interval should be based on prior
        !          1773:      statistics if possible.  Too aggressive retransmission can
        !          1774:      easily slow responses for the community at large.  Depending
        !          1775:      on how well connected the client is to its expected servers,
        !          1776:      the minimum retransmission interval should be 2-5 seconds.
        !          1777: 
        !          1778: More suggestions on server selection and retransmission policy can be
        !          1779: found in the resolver section of this memo.
        !          1780: 
        !          1781: 4.2.2. TCP usage
        !          1782: 
        !          1783: Messages sent over TCP connections use server port 53 (decimal).  The
        !          1784: message is prefixed with a two byte length field which gives the message
        !          1785: 
        !          1786: 
        !          1787: 
        !          1788: Mockapetris                                                    [Page 32]
        !          1789: 
        !          1790: RFC 1035        Domain Implementation and Specification    November 1987
        !          1791: 
        !          1792: 
        !          1793: length, excluding the two byte length field.  This length field allows
        !          1794: the low-level processing to assemble a complete message before beginning
        !          1795: to parse it.
        !          1796: 
        !          1797: Several connection management policies are recommended:
        !          1798: 
        !          1799:    - The server should not block other activities waiting for TCP
        !          1800:      data.
        !          1801: 
        !          1802:    - The server should support multiple connections.
        !          1803: 
        !          1804:    - The server should assume that the client will initiate
        !          1805:      connection closing, and should delay closing its end of the
        !          1806:      connection until all outstanding client requests have been
        !          1807:      satisfied.
        !          1808: 
        !          1809:    - If the server needs to close a dormant connection to reclaim
        !          1810:      resources, it should wait until the connection has been idle
        !          1811:      for a period on the order of two minutes.  In particular, the
        !          1812:      server should allow the SOA and AXFR request sequence (which
        !          1813:      begins a refresh operation) to be made on a single connection.
        !          1814:      Since the server would be unable to answer queries anyway, a
        !          1815:      unilateral close or reset may be used instead of a graceful
        !          1816:      close.
        !          1817: 
        !          1818: 5. MASTER FILES
        !          1819: 
        !          1820: Master files are text files that contain RRs in text form.  Since the
        !          1821: contents of a zone can be expressed in the form of a list of RRs a
        !          1822: master file is most often used to define a zone, though it can be used
        !          1823: to list a cache's contents.  Hence, this section first discusses the
        !          1824: format of RRs in a master file, and then the special considerations when
        !          1825: a master file is used to create a zone in some name server.
        !          1826: 
        !          1827: 5.1. Format
        !          1828: 
        !          1829: The format of these files is a sequence of entries.  Entries are
        !          1830: predominantly line-oriented, though parentheses can be used to continue
        !          1831: a list of items across a line boundary, and text literals can contain
        !          1832: CRLF within the text.  Any combination of tabs and spaces act as a
        !          1833: delimiter between the separate items that make up an entry.  The end of
        !          1834: any line in the master file can end with a comment.  The comment starts
        !          1835: with a ";" (semicolon).
        !          1836: 
        !          1837: The following entries are defined:
        !          1838: 
        !          1839:     <blank>[<comment>]
        !          1840: 
        !          1841: 
        !          1842: 
        !          1843: 
        !          1844: Mockapetris                                                    [Page 33]
        !          1845: 
        !          1846: RFC 1035        Domain Implementation and Specification    November 1987
        !          1847: 
        !          1848: 
        !          1849:     $ORIGIN <domain-name> [<comment>]
        !          1850: 
        !          1851:     $INCLUDE <file-name> [<domain-name>] [<comment>]
        !          1852: 
        !          1853:     <domain-name><rr> [<comment>]
        !          1854: 
        !          1855:     <blank><rr> [<comment>]
        !          1856: 
        !          1857: Blank lines, with or without comments, are allowed anywhere in the file.
        !          1858: 
        !          1859: Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
        !          1860: followed by a domain name, and resets the current origin for relative
        !          1861: domain names to the stated name.  $INCLUDE inserts the named file into
        !          1862: the current file, and may optionally specify a domain name that sets the
        !          1863: relative domain name origin for the included file.  $INCLUDE may also
        !          1864: have a comment.  Note that a $INCLUDE entry never changes the relative
        !          1865: origin of the parent file, regardless of changes to the relative origin
        !          1866: made within the included file.
        !          1867: 
        !          1868: The last two forms represent RRs.  If an entry for an RR begins with a
        !          1869: blank, then the RR is assumed to be owned by the last stated owner.  If
        !          1870: an RR entry begins with a <domain-name>, then the owner name is reset.
        !          1871: 
        !          1872: <rr> contents take one of the following forms:
        !          1873: 
        !          1874:     [<TTL>] [<class>] <type> <RDATA>
        !          1875: 
        !          1876:     [<class>] [<TTL>] <type> <RDATA>
        !          1877: 
        !          1878: The RR begins with optional TTL and class fields, followed by a type and
        !          1879: RDATA field appropriate to the type and class.  Class and type use the
        !          1880: standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
        !          1881: values are default to the last explicitly stated values.  Since type and
        !          1882: class mnemonics are disjoint, the parse is unique.  (Note that this
        !          1883: order is different from the order used in examples and the order used in
        !          1884: the actual RRs; the given order allows easier parsing and defaulting.)
        !          1885: 
        !          1886: <domain-name>s make up a large share of the data in the master file.
        !          1887: The labels in the domain name are expressed as character strings and
        !          1888: separated by dots.  Quoting conventions allow arbitrary characters to be
        !          1889: stored in domain names.  Domain names that end in a dot are called
        !          1890: absolute, and are taken as complete.  Domain names which do not end in a
        !          1891: dot are called relative; the actual domain name is the concatenation of
        !          1892: the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
        !          1893: an argument to the master file loading routine.  A relative name is an
        !          1894: error when no origin is available.
        !          1895: 
        !          1896: 
        !          1897: 
        !          1898: 
        !          1899: 
        !          1900: Mockapetris                                                    [Page 34]
        !          1901: 
        !          1902: RFC 1035        Domain Implementation and Specification    November 1987
        !          1903: 
        !          1904: 
        !          1905: <character-string> is expressed in one or two ways: as a contiguous set
        !          1906: of characters without interior spaces, or as a string beginning with a "
        !          1907: and ending with a ".  Inside a " delimited string any character can
        !          1908: occur, except for a " itself, which must be quoted using \ (back slash).
        !          1909: 
        !          1910: Because these files are text files several special encodings are
        !          1911: necessary to allow arbitrary data to be loaded.  In particular:
        !          1912: 
        !          1913:                 of the root.
        !          1914: 
        !          1915: @               A free standing @ is used to denote the current origin.
        !          1916: 
        !          1917: \X              where X is any character other than a digit (0-9), is
        !          1918:                 used to quote that character so that its special meaning
        !          1919:                 does not apply.  For example, "\." can be used to place
        !          1920:                 a dot character in a label.
        !          1921: 
        !          1922: \DDD            where each D is a digit is the octet corresponding to
        !          1923:                 the decimal number described by DDD.  The resulting
        !          1924:                 octet is assumed to be text and is not checked for
        !          1925:                 special meaning.
        !          1926: 
        !          1927: ( )             Parentheses are used to group data that crosses a line
        !          1928:                 boundary.  In effect, line terminations are not
        !          1929:                 recognized within parentheses.
        !          1930: 
        !          1931: ;               Semicolon is used to start a comment; the remainder of
        !          1932:                 the line is ignored.
        !          1933: 
        !          1934: 5.2. Use of master files to define zones
        !          1935: 
        !          1936: When a master file is used to load a zone, the operation should be
        !          1937: suppressed if any errors are encountered in the master file.  The
        !          1938: rationale for this is that a single error can have widespread
        !          1939: consequences.  For example, suppose that the RRs defining a delegation
        !          1940: have syntax errors; then the server will return authoritative name
        !          1941: errors for all names in the subzone (except in the case where the
        !          1942: subzone is also present on the server).
        !          1943: 
        !          1944: Several other validity checks that should be performed in addition to
        !          1945: insuring that the file is syntactically correct:
        !          1946: 
        !          1947:    1. All RRs in the file should have the same class.
        !          1948: 
        !          1949:    2. Exactly one SOA RR should be present at the top of the zone.
        !          1950: 
        !          1951:    3. If delegations are present and glue information is required,
        !          1952:       it should be present.
        !          1953: 
        !          1954: 
        !          1955: 
        !          1956: Mockapetris                                                    [Page 35]
        !          1957: 
        !          1958: RFC 1035        Domain Implementation and Specification    November 1987
        !          1959: 
        !          1960: 
        !          1961:    4. Information present outside of the authoritative nodes in the
        !          1962:       zone should be glue information, rather than the result of an
        !          1963:       origin or similar error.
        !          1964: 
        !          1965: 5.3. Master file example
        !          1966: 
        !          1967: The following is an example file which might be used to define the
        !          1968: ISI.EDU zone.and is loaded with an origin of ISI.EDU:
        !          1969: 
        !          1970: @   IN  SOA     VENERA      Action\.domains (
        !          1971:                                  20     ; SERIAL
        !          1972:                                  7200   ; REFRESH
        !          1973:                                  600    ; RETRY
        !          1974:                                  3600000; EXPIRE
        !          1975:                                  60)    ; MINIMUM
        !          1976: 
        !          1977:         NS      A.ISI.EDU.
        !          1978:         NS      VENERA
        !          1979:         NS      VAXA
        !          1980:         MX      10      VENERA
        !          1981:         MX      20      VAXA
        !          1982: 
        !          1983: A       A       26.3.0.103
        !          1984: 
        !          1985: VENERA  A       10.1.0.52
        !          1986:         A       128.9.0.32
        !          1987: 
        !          1988: VAXA    A       10.2.0.27
        !          1989:         A       128.9.0.33
        !          1990: 
        !          1991: 
        !          1992: $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
        !          1993: 
        !          1994: Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
        !          1995: 
        !          1996:     MOE     MB      A.ISI.EDU.
        !          1997:     LARRY   MB      A.ISI.EDU.
        !          1998:     CURLEY  MB      A.ISI.EDU.
        !          1999:     STOOGES MG      MOE
        !          2000:             MG      LARRY
        !          2001:             MG      CURLEY
        !          2002: 
        !          2003: Note the use of the \ character in the SOA RR to specify the responsible
        !          2004: person mailbox "[email protected]".
        !          2005: 
        !          2006: 
        !          2007: 
        !          2008: 
        !          2009: 
        !          2010: 
        !          2011: 
        !          2012: Mockapetris                                                    [Page 36]
        !          2013: 
        !          2014: RFC 1035        Domain Implementation and Specification    November 1987
        !          2015: 
        !          2016: 
        !          2017: 6. NAME SERVER IMPLEMENTATION
        !          2018: 
        !          2019: 6.1. Architecture
        !          2020: 
        !          2021: The optimal structure for the name server will depend on the host
        !          2022: operating system and whether the name server is integrated with resolver
        !          2023: operations, either by supporting recursive service, or by sharing its
        !          2024: database with a resolver.  This section discusses implementation
        !          2025: considerations for a name server which shares a database with a
        !          2026: resolver, but most of these concerns are present in any name server.
        !          2027: 
        !          2028: 6.1.1. Control
        !          2029: 
        !          2030: A name server must employ multiple concurrent activities, whether they
        !          2031: are implemented as separate tasks in the host's OS or multiplexing
        !          2032: inside a single name server program.  It is simply not acceptable for a
        !          2033: name server to block the service of UDP requests while it waits for TCP
        !          2034: data for refreshing or query activities.  Similarly, a name server
        !          2035: should not attempt to provide recursive service without processing such
        !          2036: requests in parallel, though it may choose to serialize requests from a
        !          2037: single client, or to regard identical requests from the same client as
        !          2038: duplicates.  A name server should not substantially delay requests while
        !          2039: it reloads a zone from master files or while it incorporates a newly
        !          2040: refreshed zone into its database.
        !          2041: 
        !          2042: 6.1.2. Database
        !          2043: 
        !          2044: While name server implementations are free to use any internal data
        !          2045: structures they choose, the suggested structure consists of three major
        !          2046: parts:
        !          2047: 
        !          2048:    - A "catalog" data structure which lists the zones available to
        !          2049:      this server, and a "pointer" to the zone data structure.  The
        !          2050:      main purpose of this structure is to find the nearest ancestor
        !          2051:      zone, if any, for arriving standard queries.
        !          2052: 
        !          2053:    - Separate data structures for each of the zones held by the
        !          2054:      name server.
        !          2055: 
        !          2056:    - A data structure for cached data. (or perhaps separate caches
        !          2057:      for different classes)
        !          2058: 
        !          2059: All of these data structures can be implemented an identical tree
        !          2060: structure format, with different data chained off the nodes in different
        !          2061: parts: in the catalog the data is pointers to zones, while in the zone
        !          2062: and cache data structures, the data will be RRs.  In designing the tree
        !          2063: framework the designer should recognize that query processing will need
        !          2064: to traverse the tree using case-insensitive label comparisons; and that
        !          2065: 
        !          2066: 
        !          2067: 
        !          2068: Mockapetris                                                    [Page 37]
        !          2069: 
        !          2070: RFC 1035        Domain Implementation and Specification    November 1987
        !          2071: 
        !          2072: 
        !          2073: in real data, a few nodes have a very high branching factor (100-1000 or
        !          2074: more), but the vast majority have a very low branching factor (0-1).
        !          2075: 
        !          2076: One way to solve the case problem is to store the labels for each node
        !          2077: in two pieces: a standardized-case representation of the label where all
        !          2078: ASCII characters are in a single case, together with a bit mask that
        !          2079: denotes which characters are actually of a different case.  The
        !          2080: branching factor diversity can be handled using a simple linked list for
        !          2081: a node until the branching factor exceeds some threshold, and
        !          2082: transitioning to a hash structure after the threshold is exceeded.  In
        !          2083: any case, hash structures used to store tree sections must insure that
        !          2084: hash functions and procedures preserve the casing conventions of the
        !          2085: DNS.
        !          2086: 
        !          2087: The use of separate structures for the different parts of the database
        !          2088: is motivated by several factors:
        !          2089: 
        !          2090:    - The catalog structure can be an almost static structure that
        !          2091:      need change only when the system administrator changes the
        !          2092:      zones supported by the server.  This structure can also be
        !          2093:      used to store parameters used to control refreshing
        !          2094:      activities.
        !          2095: 
        !          2096:    - The individual data structures for zones allow a zone to be
        !          2097:      replaced simply by changing a pointer in the catalog.  Zone
        !          2098:      refresh operations can build a new structure and, when
        !          2099:      complete, splice it into the database via a simple pointer
        !          2100:      replacement.  It is very important that when a zone is
        !          2101:      refreshed, queries should not use old and new data
        !          2102:      simultaneously.
        !          2103: 
        !          2104:    - With the proper search procedures, authoritative data in zones
        !          2105:      will always "hide", and hence take precedence over, cached
        !          2106:      data.
        !          2107: 
        !          2108:    - Errors in zone definitions that cause overlapping zones, etc.,
        !          2109:      may cause erroneous responses to queries, but problem
        !          2110:      determination is simplified, and the contents of one "bad"
        !          2111:      zone can't corrupt another.
        !          2112: 
        !          2113:    - Since the cache is most frequently updated, it is most
        !          2114:      vulnerable to corruption during system restarts.  It can also
        !          2115:      become full of expired RR data.  In either case, it can easily
        !          2116:      be discarded without disturbing zone data.
        !          2117: 
        !          2118: A major aspect of database design is selecting a structure which allows
        !          2119: the name server to deal with crashes of the name server's host.  State
        !          2120: information which a name server should save across system crashes
        !          2121: 
        !          2122: 
        !          2123: 
        !          2124: Mockapetris                                                    [Page 38]
        !          2125: 
        !          2126: RFC 1035        Domain Implementation and Specification    November 1987
        !          2127: 
        !          2128: 
        !          2129: includes the catalog structure (including the state of refreshing for
        !          2130: each zone) and the zone data itself.
        !          2131: 
        !          2132: 6.1.3. Time
        !          2133: 
        !          2134: Both the TTL data for RRs and the timing data for refreshing activities
        !          2135: depends on 32 bit timers in units of seconds.  Inside the database,
        !          2136: refresh timers and TTLs for cached data conceptually "count down", while
        !          2137: data in the zone stays with constant TTLs.
        !          2138: 
        !          2139: A recommended implementation strategy is to store time in two ways:  as
        !          2140: a relative increment and as an absolute time.  One way to do this is to
        !          2141: use positive 32 bit numbers for one type and negative numbers for the
        !          2142: other.  The RRs in zones use relative times; the refresh timers and
        !          2143: cache data use absolute times.  Absolute numbers are taken with respect
        !          2144: to some known origin and converted to relative values when placed in the
        !          2145: response to a query.  When an absolute TTL is negative after conversion
        !          2146: to relative, then the data is expired and should be ignored.
        !          2147: 
        !          2148: 6.2. Standard query processing
        !          2149: 
        !          2150: The major algorithm for standard query processing is presented in
        !          2151: [RFC-1034].
        !          2152: 
        !          2153: When processing queries with QCLASS=*, or some other QCLASS which
        !          2154: matches multiple classes, the response should never be authoritative
        !          2155: unless the server can guarantee that the response covers all classes.
        !          2156: 
        !          2157: When composing a response, RRs which are to be inserted in the
        !          2158: additional section, but duplicate RRs in the answer or authority
        !          2159: sections, may be omitted from the additional section.
        !          2160: 
        !          2161: When a response is so long that truncation is required, the truncation
        !          2162: should start at the end of the response and work forward in the
        !          2163: datagram.  Thus if there is any data for the authority section, the
        !          2164: answer section is guaranteed to be unique.
        !          2165: 
        !          2166: The MINIMUM value in the SOA should be used to set a floor on the TTL of
        !          2167: data distributed from a zone.  This floor function should be done when
        !          2168: the data is copied into a response.  This will allow future dynamic
        !          2169: update protocols to change the SOA MINIMUM field without ambiguous
        !          2170: semantics.
        !          2171: 
        !          2172: 6.3. Zone refresh and reload processing
        !          2173: 
        !          2174: In spite of a server's best efforts, it may be unable to load zone data
        !          2175: from a master file due to syntax errors, etc., or be unable to refresh a
        !          2176: zone within the its expiration parameter.  In this case, the name server
        !          2177: 
        !          2178: 
        !          2179: 
        !          2180: Mockapetris                                                    [Page 39]
        !          2181: 
        !          2182: RFC 1035        Domain Implementation and Specification    November 1987
        !          2183: 
        !          2184: 
        !          2185: should answer queries as if it were not supposed to possess the zone.
        !          2186: 
        !          2187: If a master is sending a zone out via AXFR, and a new version is created
        !          2188: during the transfer, the master should continue to send the old version
        !          2189: if possible.  In any case, it should never send part of one version and
        !          2190: part of another.  If completion is not possible, the master should reset
        !          2191: the connection on which the zone transfer is taking place.
        !          2192: 
        !          2193: 6.4. Inverse queries (Optional)
        !          2194: 
        !          2195: Inverse queries are an optional part of the DNS.  Name servers are not
        !          2196: required to support any form of inverse queries.  If a name server
        !          2197: receives an inverse query that it does not support, it returns an error
        !          2198: response with the "Not Implemented" error set in the header.  While
        !          2199: inverse query support is optional, all name servers must be at least
        !          2200: able to return the error response.
        !          2201: 
        !          2202: 6.4.1. The contents of inverse queries and responses          Inverse
        !          2203: queries reverse the mappings performed by standard query operations;
        !          2204: while a standard query maps a domain name to a resource, an inverse
        !          2205: query maps a resource to a domain name.  For example, a standard query
        !          2206: might bind a domain name to a host address; the corresponding inverse
        !          2207: query binds the host address to a domain name.
        !          2208: 
        !          2209: Inverse queries take the form of a single RR in the answer section of
        !          2210: the message, with an empty question section.  The owner name of the
        !          2211: query RR and its TTL are not significant.  The response carries
        !          2212: questions in the question section which identify all names possessing
        !          2213: the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
        !          2214: about all of the domain name space, the response can never be assumed to
        !          2215: be complete.  Thus inverse queries are primarily useful for database
        !          2216: management and debugging activities.  Inverse queries are NOT an
        !          2217: acceptable method of mapping host addresses to host names; use the IN-
        !          2218: ADDR.ARPA domain instead.
        !          2219: 
        !          2220: Where possible, name servers should provide case-insensitive comparisons
        !          2221: for inverse queries.  Thus an inverse query asking for an MX RR of
        !          2222: "Venera.isi.edu" should get the same response as a query for
        !          2223: "VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
        !          2224: produce the same result as an inverse query for "IBM-pc unix".  However,
        !          2225: this cannot be guaranteed because name servers may possess RRs that
        !          2226: contain character strings but the name server does not know that the
        !          2227: data is character.
        !          2228: 
        !          2229: When a name server processes an inverse query, it either returns:
        !          2230: 
        !          2231:    1. zero, one, or multiple domain names for the specified
        !          2232:       resource as QNAMEs in the question section
        !          2233: 
        !          2234: 
        !          2235: 
        !          2236: Mockapetris                                                    [Page 40]
        !          2237: 
        !          2238: RFC 1035        Domain Implementation and Specification    November 1987
        !          2239: 
        !          2240: 
        !          2241:    2. an error code indicating that the name server doesn't support
        !          2242:       inverse mapping of the specified resource type.
        !          2243: 
        !          2244: When the response to an inverse query contains one or more QNAMEs, the
        !          2245: owner name and TTL of the RR in the answer section which defines the
        !          2246: inverse query is modified to exactly match an RR found at the first
        !          2247: QNAME.
        !          2248: 
        !          2249: RRs returned in the inverse queries cannot be cached using the same
        !          2250: mechanism as is used for the replies to standard queries.  One reason
        !          2251: for this is that a name might have multiple RRs of the same type, and
        !          2252: only one would appear.  For example, an inverse query for a single
        !          2253: address of a multiply homed host might create the impression that only
        !          2254: one address existed.
        !          2255: 
        !          2256: 6.4.2. Inverse query and response example          The overall structure
        !          2257: of an inverse query for retrieving the domain name that corresponds to
        !          2258: Internet address 10.1.0.52 is shown below:
        !          2259: 
        !          2260:                          +-----------------------------------------+
        !          2261:            Header        |          OPCODE=IQUERY, ID=997          |
        !          2262:                          +-----------------------------------------+
        !          2263:           Question       |                 <empty>                 |
        !          2264:                          +-----------------------------------------+
        !          2265:            Answer        |        <anyname> A IN 10.1.0.52         |
        !          2266:                          +-----------------------------------------+
        !          2267:           Authority      |                 <empty>                 |
        !          2268:                          +-----------------------------------------+
        !          2269:          Additional      |                 <empty>                 |
        !          2270:                          +-----------------------------------------+
        !          2271: 
        !          2272: This query asks for a question whose answer is the Internet style
        !          2273: address 10.1.0.52.  Since the owner name is not known, any domain name
        !          2274: can be used as a placeholder (and is ignored).  A single octet of zero,
        !          2275: signifying the root, is usually used because it minimizes the length of
        !          2276: the message.  The TTL of the RR is not significant.  The response to
        !          2277: this query might be:
        !          2278: 
        !          2279: 
        !          2280: 
        !          2281: 
        !          2282: 
        !          2283: 
        !          2284: 
        !          2285: 
        !          2286: 
        !          2287: 
        !          2288: 
        !          2289: 
        !          2290: 
        !          2291: 
        !          2292: Mockapetris                                                    [Page 41]
        !          2293: 
        !          2294: RFC 1035        Domain Implementation and Specification    November 1987
        !          2295: 
        !          2296: 
        !          2297:                          +-----------------------------------------+
        !          2298:            Header        |         OPCODE=RESPONSE, ID=997         |
        !          2299:                          +-----------------------------------------+
        !          2300:           Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
        !          2301:                          +-----------------------------------------+
        !          2302:            Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
        !          2303:                          +-----------------------------------------+
        !          2304:           Authority      |                 <empty>                 |
        !          2305:                          +-----------------------------------------+
        !          2306:          Additional      |                 <empty>                 |
        !          2307:                          +-----------------------------------------+
        !          2308: 
        !          2309: Note that the QTYPE in a response to an inverse query is the same as the
        !          2310: TYPE field in the answer section of the inverse query.  Responses to
        !          2311: inverse queries may contain multiple questions when the inverse is not
        !          2312: unique.  If the question section in the response is not empty, then the
        !          2313: RR in the answer section is modified to correspond to be an exact copy
        !          2314: of an RR at the first QNAME.
        !          2315: 
        !          2316: 6.4.3. Inverse query processing
        !          2317: 
        !          2318: Name servers that support inverse queries can support these operations
        !          2319: through exhaustive searches of their databases, but this becomes
        !          2320: impractical as the size of the database increases.  An alternative
        !          2321: approach is to invert the database according to the search key.
        !          2322: 
        !          2323: For name servers that support multiple zones and a large amount of data,
        !          2324: the recommended approach is separate inversions for each zone.  When a
        !          2325: particular zone is changed during a refresh, only its inversions need to
        !          2326: be redone.
        !          2327: 
        !          2328: Support for transfer of this type of inversion may be included in future
        !          2329: versions of the domain system, but is not supported in this version.
        !          2330: 
        !          2331: 6.5. Completion queries and responses
        !          2332: 
        !          2333: The optional completion services described in RFC-882 and RFC-883 have
        !          2334: been deleted.  Redesigned services may become available in the future.
        !          2335: 
        !          2336: 
        !          2337: 
        !          2338: 
        !          2339: 
        !          2340: 
        !          2341: 
        !          2342: 
        !          2343: 
        !          2344: 
        !          2345: 
        !          2346: 
        !          2347: 
        !          2348: Mockapetris                                                    [Page 42]
        !          2349: 
        !          2350: RFC 1035        Domain Implementation and Specification    November 1987
        !          2351: 
        !          2352: 
        !          2353: 7. RESOLVER IMPLEMENTATION
        !          2354: 
        !          2355: The top levels of the recommended resolver algorithm are discussed in
        !          2356: [RFC-1034].  This section discusses implementation details assuming the
        !          2357: database structure suggested in the name server implementation section
        !          2358: of this memo.
        !          2359: 
        !          2360: 7.1. Transforming a user request into a query
        !          2361: 
        !          2362: The first step a resolver takes is to transform the client's request,
        !          2363: stated in a format suitable to the local OS, into a search specification
        !          2364: for RRs at a specific name which match a specific QTYPE and QCLASS.
        !          2365: Where possible, the QTYPE and QCLASS should correspond to a single type
        !          2366: and a single class, because this makes the use of cached data much
        !          2367: simpler.  The reason for this is that the presence of data of one type
        !          2368: in a cache doesn't confirm the existence or non-existence of data of
        !          2369: other types, hence the only way to be sure is to consult an
        !          2370: authoritative source.  If QCLASS=* is used, then authoritative answers
        !          2371: won't be available.
        !          2372: 
        !          2373: Since a resolver must be able to multiplex multiple requests if it is to
        !          2374: perform its function efficiently, each pending request is usually
        !          2375: represented in some block of state information.  This state block will
        !          2376: typically contain:
        !          2377: 
        !          2378:    - A timestamp indicating the time the request began.
        !          2379:      The timestamp is used to decide whether RRs in the database
        !          2380:      can be used or are out of date.  This timestamp uses the
        !          2381:      absolute time format previously discussed for RR storage in
        !          2382:      zones and caches.  Note that when an RRs TTL indicates a
        !          2383:      relative time, the RR must be timely, since it is part of a
        !          2384:      zone.  When the RR has an absolute time, it is part of a
        !          2385:      cache, and the TTL of the RR is compared against the timestamp
        !          2386:      for the start of the request.
        !          2387: 
        !          2388:      Note that using the timestamp is superior to using a current
        !          2389:      time, since it allows RRs with TTLs of zero to be entered in
        !          2390:      the cache in the usual manner, but still used by the current
        !          2391:      request, even after intervals of many seconds due to system
        !          2392:      load, query retransmission timeouts, etc.
        !          2393: 
        !          2394:    - Some sort of parameters to limit the amount of work which will
        !          2395:      be performed for this request.
        !          2396: 
        !          2397:      The amount of work which a resolver will do in response to a
        !          2398:      client request must be limited to guard against errors in the
        !          2399:      database, such as circular CNAME references, and operational
        !          2400:      problems, such as network partition which prevents the
        !          2401: 
        !          2402: 
        !          2403: 
        !          2404: Mockapetris                                                    [Page 43]
        !          2405: 
        !          2406: RFC 1035        Domain Implementation and Specification    November 1987
        !          2407: 
        !          2408: 
        !          2409:      resolver from accessing the name servers it needs.  While
        !          2410:      local limits on the number of times a resolver will retransmit
        !          2411:      a particular query to a particular name server address are
        !          2412:      essential, the resolver should have a global per-request
        !          2413:      counter to limit work on a single request.  The counter should
        !          2414:      be set to some initial value and decremented whenever the
        !          2415:      resolver performs any action (retransmission timeout,
        !          2416:      retransmission, etc.)  If the counter passes zero, the request
        !          2417:      is terminated with a temporary error.
        !          2418: 
        !          2419:      Note that if the resolver structure allows one request to
        !          2420:      start others in parallel, such as when the need to access a
        !          2421:      name server for one request causes a parallel resolve for the
        !          2422:      name server's addresses, the spawned request should be started
        !          2423:      with a lower counter.  This prevents circular references in
        !          2424:      the database from starting a chain reaction of resolver
        !          2425:      activity.
        !          2426: 
        !          2427:    - The SLIST data structure discussed in [RFC-1034].
        !          2428: 
        !          2429:      This structure keeps track of the state of a request if it
        !          2430:      must wait for answers from foreign name servers.
        !          2431: 
        !          2432: 7.2. Sending the queries
        !          2433: 
        !          2434: As described in [RFC-1034], the basic task of the resolver is to
        !          2435: formulate a query which will answer the client's request and direct that
        !          2436: query to name servers which can provide the information.  The resolver
        !          2437: will usually only have very strong hints about which servers to ask, in
        !          2438: the form of NS RRs, and may have to revise the query, in response to
        !          2439: CNAMEs, or revise the set of name servers the resolver is asking, in
        !          2440: response to delegation responses which point the resolver to name
        !          2441: servers closer to the desired information.  In addition to the
        !          2442: information requested by the client, the resolver may have to call upon
        !          2443: its own services to determine the address of name servers it wishes to
        !          2444: contact.
        !          2445: 
        !          2446: In any case, the model used in this memo assumes that the resolver is
        !          2447: multiplexing attention between multiple requests, some from the client,
        !          2448: and some internally generated.  Each request is represented by some
        !          2449: state information, and the desired behavior is that the resolver
        !          2450: transmit queries to name servers in a way that maximizes the probability
        !          2451: that the request is answered, minimizes the time that the request takes,
        !          2452: and avoids excessive transmissions.  The key algorithm uses the state
        !          2453: information of the request to select the next name server address to
        !          2454: query, and also computes a timeout which will cause the next action
        !          2455: should a response not arrive.  The next action will usually be a
        !          2456: transmission to some other server, but may be a temporary error to the
        !          2457: 
        !          2458: 
        !          2459: 
        !          2460: Mockapetris                                                    [Page 44]
        !          2461: 
        !          2462: RFC 1035        Domain Implementation and Specification    November 1987
        !          2463: 
        !          2464: 
        !          2465: client.
        !          2466: 
        !          2467: The resolver always starts with a list of server names to query (SLIST).
        !          2468: This list will be all NS RRs which correspond to the nearest ancestor
        !          2469: zone that the resolver knows about.  To avoid startup problems, the
        !          2470: resolver should have a set of default servers which it will ask should
        !          2471: it have no current NS RRs which are appropriate.  The resolver then adds
        !          2472: to SLIST all of the known addresses for the name servers, and may start
        !          2473: parallel requests to acquire the addresses of the servers when the
        !          2474: resolver has the name, but no addresses, for the name servers.
        !          2475: 
        !          2476: To complete initialization of SLIST, the resolver attaches whatever
        !          2477: history information it has to the each address in SLIST.  This will
        !          2478: usually consist of some sort of weighted averages for the response time
        !          2479: of the address, and the batting average of the address (i.e., how often
        !          2480: the address responded at all to the request).  Note that this
        !          2481: information should be kept on a per address basis, rather than on a per
        !          2482: name server basis, because the response time and batting average of a
        !          2483: particular server may vary considerably from address to address.  Note
        !          2484: also that this information is actually specific to a resolver address /
        !          2485: server address pair, so a resolver with multiple addresses may wish to
        !          2486: keep separate histories for each of its addresses.  Part of this step
        !          2487: must deal with addresses which have no such history; in this case an
        !          2488: expected round trip time of 5-10 seconds should be the worst case, with
        !          2489: lower estimates for the same local network, etc.
        !          2490: 
        !          2491: Note that whenever a delegation is followed, the resolver algorithm
        !          2492: reinitializes SLIST.
        !          2493: 
        !          2494: The information establishes a partial ranking of the available name
        !          2495: server addresses.  Each time an address is chosen and the state should
        !          2496: be altered to prevent its selection again until all other addresses have
        !          2497: been tried.  The timeout for each transmission should be 50-100% greater
        !          2498: than the average predicted value to allow for variance in response.
        !          2499: 
        !          2500: Some fine points:
        !          2501: 
        !          2502:    - The resolver may encounter a situation where no addresses are
        !          2503:      available for any of the name servers named in SLIST, and
        !          2504:      where the servers in the list are precisely those which would
        !          2505:      normally be used to look up their own addresses.  This
        !          2506:      situation typically occurs when the glue address RRs have a
        !          2507:      smaller TTL than the NS RRs marking delegation, or when the
        !          2508:      resolver caches the result of a NS search.  The resolver
        !          2509:      should detect this condition and restart the search at the
        !          2510:      next ancestor zone, or alternatively at the root.
        !          2511: 
        !          2512: 
        !          2513: 
        !          2514: 
        !          2515: 
        !          2516: Mockapetris                                                    [Page 45]
        !          2517: 
        !          2518: RFC 1035        Domain Implementation and Specification    November 1987
        !          2519: 
        !          2520: 
        !          2521:    - If a resolver gets a server error or other bizarre response
        !          2522:      from a name server, it should remove it from SLIST, and may
        !          2523:      wish to schedule an immediate transmission to the next
        !          2524:      candidate server address.
        !          2525: 
        !          2526: 7.3. Processing responses
        !          2527: 
        !          2528: The first step in processing arriving response datagrams is to parse the
        !          2529: response.  This procedure should include:
        !          2530: 
        !          2531:    - Check the header for reasonableness.  Discard datagrams which
        !          2532:      are queries when responses are expected.
        !          2533: 
        !          2534:    - Parse the sections of the message, and insure that all RRs are
        !          2535:      correctly formatted.
        !          2536: 
        !          2537:    - As an optional step, check the TTLs of arriving data looking
        !          2538:      for RRs with excessively long TTLs.  If a RR has an
        !          2539:      excessively long TTL, say greater than 1 week, either discard
        !          2540:      the whole response, or limit all TTLs in the response to 1
        !          2541:      week.
        !          2542: 
        !          2543: The next step is to match the response to a current resolver request.
        !          2544: The recommended strategy is to do a preliminary matching using the ID
        !          2545: field in the domain header, and then to verify that the question section
        !          2546: corresponds to the information currently desired.  This requires that
        !          2547: the transmission algorithm devote several bits of the domain ID field to
        !          2548: a request identifier of some sort.  This step has several fine points:
        !          2549: 
        !          2550:    - Some name servers send their responses from different
        !          2551:      addresses than the one used to receive the query.  That is, a
        !          2552:      resolver cannot rely that a response will come from the same
        !          2553:      address which it sent the corresponding query to.  This name
        !          2554:      server bug is typically encountered in UNIX systems.
        !          2555: 
        !          2556:    - If the resolver retransmits a particular request to a name
        !          2557:      server it should be able to use a response from any of the
        !          2558:      transmissions.  However, if it is using the response to sample
        !          2559:      the round trip time to access the name server, it must be able
        !          2560:      to determine which transmission matches the response (and keep
        !          2561:      transmission times for each outgoing message), or only
        !          2562:      calculate round trip times based on initial transmissions.
        !          2563: 
        !          2564:    - A name server will occasionally not have a current copy of a
        !          2565:      zone which it should have according to some NS RRs.  The
        !          2566:      resolver should simply remove the name server from the current
        !          2567:      SLIST, and continue.
        !          2568: 
        !          2569: 
        !          2570: 
        !          2571: 
        !          2572: Mockapetris                                                    [Page 46]
        !          2573: 
        !          2574: RFC 1035        Domain Implementation and Specification    November 1987
        !          2575: 
        !          2576: 
        !          2577: 7.4. Using the cache
        !          2578: 
        !          2579: In general, we expect a resolver to cache all data which it receives in
        !          2580: responses since it may be useful in answering future client requests.
        !          2581: However, there are several types of data which should not be cached:
        !          2582: 
        !          2583:    - When several RRs of the same type are available for a
        !          2584:      particular owner name, the resolver should either cache them
        !          2585:      all or none at all.  When a response is truncated, and a
        !          2586:      resolver doesn't know whether it has a complete set, it should
        !          2587:      not cache a possibly partial set of RRs.
        !          2588: 
        !          2589:    - Cached data should never be used in preference to
        !          2590:      authoritative data, so if caching would cause this to happen
        !          2591:      the data should not be cached.
        !          2592: 
        !          2593:    - The results of an inverse query should not be cached.
        !          2594: 
        !          2595:    - The results of standard queries where the QNAME contains "*"
        !          2596:      labels if the data might be used to construct wildcards.  The
        !          2597:      reason is that the cache does not necessarily contain existing
        !          2598:      RRs or zone boundary information which is necessary to
        !          2599:      restrict the application of the wildcard RRs.
        !          2600: 
        !          2601:    - RR data in responses of dubious reliability.  When a resolver
        !          2602:      receives unsolicited responses or RR data other than that
        !          2603:      requested, it should discard it without caching it.  The basic
        !          2604:      implication is that all sanity checks on a packet should be
        !          2605:      performed before any of it is cached.
        !          2606: 
        !          2607: In a similar vein, when a resolver has a set of RRs for some name in a
        !          2608: response, and wants to cache the RRs, it should check its cache for
        !          2609: already existing RRs.  Depending on the circumstances, either the data
        !          2610: in the response or the cache is preferred, but the two should never be
        !          2611: combined.  If the data in the response is from authoritative data in the
        !          2612: answer section, it is always preferred.
        !          2613: 
        !          2614: 8. MAIL SUPPORT
        !          2615: 
        !          2616: The domain system defines a standard for mapping mailboxes into domain
        !          2617: names, and two methods for using the mailbox information to derive mail
        !          2618: routing information.  The first method is called mail exchange binding
        !          2619: and the other method is mailbox binding.  The mailbox encoding standard
        !          2620: and mail exchange binding are part of the DNS official protocol, and are
        !          2621: the recommended method for mail routing in the Internet.  Mailbox
        !          2622: binding is an experimental feature which is still under development and
        !          2623: subject to change.
        !          2624: 
        !          2625: 
        !          2626: 
        !          2627: 
        !          2628: Mockapetris                                                    [Page 47]
        !          2629: 
        !          2630: RFC 1035        Domain Implementation and Specification    November 1987
        !          2631: 
        !          2632: 
        !          2633: The mailbox encoding standard assumes a mailbox name of the form
        !          2634: "<local-part>@<mail-domain>".  While the syntax allowed in each of these
        !          2635: sections varies substantially between the various mail internets, the
        !          2636: preferred syntax for the ARPA Internet is given in [RFC-822].
        !          2637: 
        !          2638: The DNS encodes the <local-part> as a single label, and encodes the
        !          2639: <mail-domain> as a domain name.  The single label from the <local-part>
        !          2640: is prefaced to the domain name from <mail-domain> to form the domain
        !          2641: name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
        !          2642: NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
        !          2643: <local-part> contains dots or other special characters, its
        !          2644: representation in a master file will require the use of backslash
        !          2645: quoting to ensure that the domain name is properly encoded.  For
        !          2646: example, the mailbox [email protected] would be represented as
        !          2647: Action\.domains.ISI.EDU.
        !          2648: 
        !          2649: 8.1. Mail exchange binding
        !          2650: 
        !          2651: Mail exchange binding uses the <mail-domain> part of a mailbox
        !          2652: specification to determine where mail should be sent.  The <local-part>
        !          2653: is not even consulted.  [RFC-974] specifies this method in detail, and
        !          2654: should be consulted before attempting to use mail exchange support.
        !          2655: 
        !          2656: One of the advantages of this method is that it decouples mail
        !          2657: destination naming from the hosts used to support mail service, at the
        !          2658: cost of another layer of indirection in the lookup function.  However,
        !          2659: the addition layer should eliminate the need for complicated "%", "!",
        !          2660: etc encodings in <local-part>.
        !          2661: 
        !          2662: The essence of the method is that the <mail-domain> is used as a domain
        !          2663: name to locate type MX RRs which list hosts willing to accept mail for
        !          2664: <mail-domain>, together with preference values which rank the hosts
        !          2665: according to an order specified by the administrators for <mail-domain>.
        !          2666: 
        !          2667: In this memo, the <mail-domain> ISI.EDU is used in examples, together
        !          2668: with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
        !          2669: ISI.EDU.  If a mailer had a message for [email protected], it would
        !          2670: route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
        !          2671: VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
        !          2672: addresses.
        !          2673: 
        !          2674: 8.2. Mailbox binding (Experimental)
        !          2675: 
        !          2676: In mailbox binding, the mailer uses the entire mail destination
        !          2677: specification to construct a domain name.  The encoded domain name for
        !          2678: the mailbox is used as the QNAME field in a QTYPE=MAILB query.
        !          2679: 
        !          2680: Several outcomes are possible for this query:
        !          2681: 
        !          2682: 
        !          2683: 
        !          2684: Mockapetris                                                    [Page 48]
        !          2685: 
        !          2686: RFC 1035        Domain Implementation and Specification    November 1987
        !          2687: 
        !          2688: 
        !          2689:    1. The query can return a name error indicating that the mailbox
        !          2690:       does not exist as a domain name.
        !          2691: 
        !          2692:       In the long term, this would indicate that the specified
        !          2693:       mailbox doesn't exist.  However, until the use of mailbox
        !          2694:       binding is universal, this error condition should be
        !          2695:       interpreted to mean that the organization identified by the
        !          2696:       global part does not support mailbox binding.  The
        !          2697:       appropriate procedure is to revert to exchange binding at
        !          2698:       this point.
        !          2699: 
        !          2700:    2. The query can return a Mail Rename (MR) RR.
        !          2701: 
        !          2702:       The MR RR carries new mailbox specification in its RDATA
        !          2703:       field.  The mailer should replace the old mailbox with the
        !          2704:       new one and retry the operation.
        !          2705: 
        !          2706:    3. The query can return a MB RR.
        !          2707: 
        !          2708:       The MB RR carries a domain name for a host in its RDATA
        !          2709:       field.  The mailer should deliver the message to that host
        !          2710:       via whatever protocol is applicable, e.g., b,SMTP.
        !          2711: 
        !          2712:    4. The query can return one or more Mail Group (MG) RRs.
        !          2713: 
        !          2714:       This condition means that the mailbox was actually a mailing
        !          2715:       list or mail group, rather than a single mailbox.  Each MG RR
        !          2716:       has a RDATA field that identifies a mailbox that is a member
        !          2717:       of the group.  The mailer should deliver a copy of the
        !          2718:       message to each member.
        !          2719: 
        !          2720:    5. The query can return a MB RR as well as one or more MG RRs.
        !          2721: 
        !          2722:       This condition means the the mailbox was actually a mailing
        !          2723:       list.  The mailer can either deliver the message to the host
        !          2724:       specified by the MB RR, which will in turn do the delivery to
        !          2725:       all members, or the mailer can use the MG RRs to do the
        !          2726:       expansion itself.
        !          2727: 
        !          2728: In any of these cases, the response may include a Mail Information
        !          2729: (MINFO) RR.  This RR is usually associated with a mail group, but is
        !          2730: legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
        !          2731: identifies a responsible person for the original mailbox name.  This
        !          2732: mailbox should be used for requests to be added to a mail group, etc.
        !          2733: The second mailbox name in the MINFO RR identifies a mailbox that should
        !          2734: receive error messages for mail failures.  This is particularly
        !          2735: appropriate for mailing lists when errors in member names should be
        !          2736: reported to a person other than the one who sends a message to the list.
        !          2737: 
        !          2738: 
        !          2739: 
        !          2740: Mockapetris                                                    [Page 49]
        !          2741: 
        !          2742: RFC 1035        Domain Implementation and Specification    November 1987
        !          2743: 
        !          2744: 
        !          2745: New fields may be added to this RR in the future.
        !          2746: 
        !          2747: 
        !          2748: 9. REFERENCES and BIBLIOGRAPHY
        !          2749: 
        !          2750: [Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
        !          2751:                 Technical Plan - Name Service, April 1987, version 1.9.
        !          2752: 
        !          2753:                 Describes the fundamentals of the Hesiod name service.
        !          2754: 
        !          2755: [IEN-116]       J. Postel, "Internet Name Server", IEN-116,
        !          2756:                 USC/Information Sciences Institute, August 1979.
        !          2757: 
        !          2758:                 A name service obsoleted by the Domain Name System, but
        !          2759:                 still in use.
        !          2760: 
        !          2761: [Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
        !          2762:                 Communications of the ACM, October 1986, volume 29, number
        !          2763:                 10.
        !          2764: 
        !          2765: [RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
        !          2766:                 Information Center, SRI International, December 1977.
        !          2767: 
        !          2768: [RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
        !          2769:                 USC/Information Sciences Institute, August 1980.
        !          2770: 
        !          2771: [RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
        !          2772:                 USC/Information Sciences Institute, September 1981.
        !          2773: 
        !          2774: [RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
        !          2775:                 September 1981.
        !          2776: 
        !          2777:                 Suggests introduction of a hierarchy in place of a flat
        !          2778:                 name space for the Internet.
        !          2779: 
        !          2780: [RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
        !          2781:                 USC/Information Sciences Institute, February 1982.
        !          2782: 
        !          2783: [RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
        !          2784:                 Internet Host Table Specification", RFC-810, Network
        !          2785:                 Information Center, SRI International, March 1982.
        !          2786: 
        !          2787:                 Obsolete.  See RFC-952.
        !          2788: 
        !          2789: [RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
        !          2790:                 Server", RFC-811, Network Information Center, SRI
        !          2791:                 International, March 1982.
        !          2792: 
        !          2793: 
        !          2794: 
        !          2795: 
        !          2796: Mockapetris                                                    [Page 50]
        !          2797: 
        !          2798: RFC 1035        Domain Implementation and Specification    November 1987
        !          2799: 
        !          2800: 
        !          2801:                 Obsolete.  See RFC-953.
        !          2802: 
        !          2803: [RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
        !          2804:                 Network Information Center, SRI International, March
        !          2805:                 1982.
        !          2806: 
        !          2807: [RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
        !          2808:                 Internet User Applications", RFC-819, Network
        !          2809:                 Information Center, SRI International, August 1982.
        !          2810: 
        !          2811:                 Early thoughts on the design of the domain system.
        !          2812:                 Current implementation is completely different.
        !          2813: 
        !          2814: [RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
        !          2815:                 USC/Information Sciences Institute, August 1980.
        !          2816: 
        !          2817: [RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
        !          2818:                 RFC-830, Network Information Center, SRI International,
        !          2819:                 October 1982.
        !          2820: 
        !          2821:                 Early thoughts on the design of the domain system.
        !          2822:                 Current implementation is completely different.
        !          2823: 
        !          2824: [RFC-882]       P. Mockapetris, "Domain names - Concepts and
        !          2825:                 Facilities," RFC-882, USC/Information Sciences
        !          2826:                 Institute, November 1983.
        !          2827: 
        !          2828:                 Superceeded by this memo.
        !          2829: 
        !          2830: [RFC-883]       P. Mockapetris, "Domain names - Implementation and
        !          2831:                 Specification," RFC-883, USC/Information Sciences
        !          2832:                 Institute, November 1983.
        !          2833: 
        !          2834:                 Superceeded by this memo.
        !          2835: 
        !          2836: [RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
        !          2837:                 RFC-920, USC/Information Sciences Institute,
        !          2838:                 October 1984.
        !          2839: 
        !          2840:                 Explains the naming scheme for top level domains.
        !          2841: 
        !          2842: [RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
        !          2843:                 Table Specification", RFC-952, SRI, October 1985.
        !          2844: 
        !          2845:                 Specifies the format of HOSTS.TXT, the host/address
        !          2846:                 table replaced by the DNS.
        !          2847: 
        !          2848: 
        !          2849: 
        !          2850: 
        !          2851: 
        !          2852: Mockapetris                                                    [Page 51]
        !          2853: 
        !          2854: RFC 1035        Domain Implementation and Specification    November 1987
        !          2855: 
        !          2856: 
        !          2857: [RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
        !          2858:                 RFC-953, SRI, October 1985.
        !          2859: 
        !          2860:                 This RFC contains the official specification of the
        !          2861:                 hostname server protocol, which is obsoleted by the DNS.
        !          2862:                 This TCP based protocol accesses information stored in
        !          2863:                 the RFC-952 format, and is used to obtain copies of the
        !          2864:                 host table.
        !          2865: 
        !          2866: [RFC-973]       P. Mockapetris, "Domain System Changes and
        !          2867:                 Observations", RFC-973, USC/Information Sciences
        !          2868:                 Institute, January 1986.
        !          2869: 
        !          2870:                 Describes changes to RFC-882 and RFC-883 and reasons for
        !          2871:                 them.
        !          2872: 
        !          2873: [RFC-974]       C. Partridge, "Mail routing and the domain system",
        !          2874:                 RFC-974, CSNET CIC BBN Labs, January 1986.
        !          2875: 
        !          2876:                 Describes the transition from HOSTS.TXT based mail
        !          2877:                 addressing to the more powerful MX system used with the
        !          2878:                 domain system.
        !          2879: 
        !          2880: [RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
        !          2881:                 service on a TCP/UDP transport: Concepts and Methods",
        !          2882:                 RFC-1001, March 1987.
        !          2883: 
        !          2884:                 This RFC and RFC-1002 are a preliminary design for
        !          2885:                 NETBIOS on top of TCP/IP which proposes to base NetBIOS
        !          2886:                 name service on top of the DNS.
        !          2887: 
        !          2888: [RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
        !          2889:                 service on a TCP/UDP transport: Detailed
        !          2890:                 Specifications", RFC-1002, March 1987.
        !          2891: 
        !          2892: [RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
        !          2893:                 USC/Information Sciences Institute, May 1987.
        !          2894: 
        !          2895:                 Contains socket numbers and mnemonics for host names,
        !          2896:                 operating systems, etc.
        !          2897: 
        !          2898: [RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
        !          2899:                 November 1987.
        !          2900: 
        !          2901:                 Describes a plan for converting the MILNET to the DNS.
        !          2902: 
        !          2903: [RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
        !          2904:                 Administrators", RFC-1032, November 1987.
        !          2905: 
        !          2906: 
        !          2907: 
        !          2908: Mockapetris                                                    [Page 52]
        !          2909: 
        !          2910: RFC 1035        Domain Implementation and Specification    November 1987
        !          2911: 
        !          2912: 
        !          2913:                 Describes the registration policies used by the NIC to
        !          2914:                 administer the top level domains and delegate subzones.
        !          2915: 
        !          2916: [RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
        !          2917:                 RFC-1033, November 1987.
        !          2918: 
        !          2919:                 A cookbook for domain administrators.
        !          2920: 
        !          2921: [Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
        !          2922:                 Name Server", Computer Networks, vol 6, nr 3, July 1982.
        !          2923: 
        !          2924:                 Describes a name service for CSNET which is independent
        !          2925:                 from the DNS and DNS use in the CSNET.
        !          2926: 
        !          2927: 
        !          2928: 
        !          2929: 
        !          2930: 
        !          2931: 
        !          2932: 
        !          2933: 
        !          2934: 
        !          2935: 
        !          2936: 
        !          2937: 
        !          2938: 
        !          2939: 
        !          2940: 
        !          2941: 
        !          2942: 
        !          2943: 
        !          2944: 
        !          2945: 
        !          2946: 
        !          2947: 
        !          2948: 
        !          2949: 
        !          2950: 
        !          2951: 
        !          2952: 
        !          2953: 
        !          2954: 
        !          2955: 
        !          2956: 
        !          2957: 
        !          2958: 
        !          2959: 
        !          2960: 
        !          2961: 
        !          2962: 
        !          2963: 
        !          2964: Mockapetris                                                    [Page 53]
        !          2965: 
        !          2966: RFC 1035        Domain Implementation and Specification    November 1987
        !          2967: 
        !          2968: 
        !          2969: Index
        !          2970: 
        !          2971:           *   13
        !          2972: 
        !          2973:           ;   33, 35
        !          2974: 
        !          2975:           <character-string>   35
        !          2976:           <domain-name>   34
        !          2977: 
        !          2978:           @   35
        !          2979: 
        !          2980:           \   35
        !          2981: 
        !          2982:           A   12
        !          2983: 
        !          2984:           Byte order   8
        !          2985: 
        !          2986:           CH   13
        !          2987:           Character case   9
        !          2988:           CLASS   11
        !          2989:           CNAME   12
        !          2990:           Completion   42
        !          2991:           CS   13
        !          2992: 
        !          2993:           Hesiod   13
        !          2994:           HINFO   12
        !          2995:           HS   13
        !          2996: 
        !          2997:           IN   13
        !          2998:           IN-ADDR.ARPA domain   22
        !          2999:           Inverse queries   40
        !          3000: 
        !          3001:           Mailbox names   47
        !          3002:           MB   12
        !          3003:           MD   12
        !          3004:           MF   12
        !          3005:           MG   12
        !          3006:           MINFO   12
        !          3007:           MINIMUM   20
        !          3008:           MR   12
        !          3009:           MX   12
        !          3010: 
        !          3011:           NS   12
        !          3012:           NULL   12
        !          3013: 
        !          3014:           Port numbers   32
        !          3015:           Primary server   5
        !          3016:           PTR   12, 18
        !          3017: 
        !          3018: 
        !          3019: 
        !          3020: Mockapetris                                                    [Page 54]
        !          3021: 
        !          3022: RFC 1035        Domain Implementation and Specification    November 1987
        !          3023: 
        !          3024: 
        !          3025:           QCLASS   13
        !          3026:           QTYPE   12
        !          3027: 
        !          3028:           RDATA   12
        !          3029:           RDLENGTH  11
        !          3030: 
        !          3031:           Secondary server   5
        !          3032:           SOA   12
        !          3033:           Stub resolvers   7
        !          3034: 
        !          3035:           TCP   32
        !          3036:           TXT   12
        !          3037:           TYPE   11
        !          3038: 
        !          3039:           UDP   32
        !          3040: 
        !          3041:           WKS   12
        !          3042: 
        !          3043: 
        !          3044: 
        !          3045: 
        !          3046: 
        !          3047: 
        !          3048: 
        !          3049: 
        !          3050: 
        !          3051: 
        !          3052: 
        !          3053: 
        !          3054: 
        !          3055: 
        !          3056: 
        !          3057: 
        !          3058: 
        !          3059: 
        !          3060: 
        !          3061: 
        !          3062: 
        !          3063: 
        !          3064: 
        !          3065: 
        !          3066: 
        !          3067: 
        !          3068: 
        !          3069: 
        !          3070: 
        !          3071: 
        !          3072: 
        !          3073: 
        !          3074: 
        !          3075: 
        !          3076: Mockapetris                                                    [Page 55]
        !          3077: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.