brian@ucsd.EDU (Brian Kantor) (02/26/88)
---
- RR data in responses of dubious reliability. When a resolver
receives unsolicited responses or RR data other than that
requested, it should discard it without caching it. The basic
implication is that all sanity checks on a packet should be
performed before any of it is cached.
In a similar vein, when a resolver has a set of RRs for some name in a
response, and wants to cache the RRs, it should check its cache for
already existing RRs. Depending on the circumstances, either the data
in the response or the cache is preferred, but the two should never be
combined. If the data in the response is from authoritative data in the
answer section, it is always preferred.
8. MAIL SUPPORT
The domain system defines a standard for mapping mailboxes into domain
names, and two methods for using the mailbox information to derive mail
routing information. The first method is called mail exchange binding
and the other method is mailbox binding. The mailbox encoding standard
and mail exchange binding are part of the DNS official protocol, and are
the recommended method for mail routing in the Internet. Mailbox
binding is an experimental feature which is still under development and
subject to change.
Mockapetris [Page 47]
RFC 1035 Domain Implementation and Specification November 1987
The mailbox encoding standard assumes a mailbox name of the form
"<local-part>@<mail-domain>". While the syntax allowed in each of these
sections varies substantially between the various mail internets, the
preferred syntax for the ARPA Internet is given in [RFC-822].
The DNS encodes the <local-part> as a single label, and encodes the
<mail-domain> as a domain name. The single label from the <local-part>
is prefaced to the domain name from <mail-domain> to form the domain
name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
<local-part> contains dots or other special characters, its
representation in a master file will require the use of backslash
quoting to ensure that the domain name is properly encoded. For
example, the mailbox Action.domains@ISI.EDU would be represented as
Action\.domains.ISI.EDU.
8.1. Mail exchange binding
Mail exchange binding uses the <mail-domain> part of a mailbox
specification to determine where mail should be sent. The <local-part>
is not even consulted. [RFC-974] specifies this method in detail, and
should be consulted before attempting to use mail exchange support.
One of the advantages of this method is that it decouples mail
destination naming from the hosts used to support mail service, at the
cost of another layer of indirection in the lookup function. However,
the addition layer should eliminate the need for complicated "%", "!",
etc encodings in <local-part>.
The essence of the method is that the <mail-domain> is used as a domain
name to locate type MX RRs which list hosts willing to accept mail for
<mail-domain>, together with preference values which rank the hosts
according to an order specified by the administrators for <mail-domain>.
In this memo, the <mail-domain> ISI.EDU is used in examples, together
with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
addresses.
8.2. Mailbox binding (Experimental)
In mailbox binding, the mailer uses the entire mail destination
specification to construct a domain name. The encoded domain name for
the mailbox is used as the QNAME field in a QTYPE=MAILB query.
Several outcomes are possible for this query:
Mockapetris [Page 48]
RFC 1035 Domain Implementation and Specification November 1987
1. The query can return a name error indicating that the mailbox
does not exist as a domain name.
In the long term, this would indicate that the specified
mailbox doesn't exist. However, until the use of mailbox
binding is universal, this error condition should be
interpreted to mean that the organization identified by the
global part does not support mailbox binding. The
appropriate procedure is to revert to exchange binding at
this point.
2. The query can return a Mail Rename (MR) RR.
The MR RR carries new mailbox specification in its RDATA
field. The mailer should replace the old mailbox with the
new one and retry the operation.
3. The query can return a MB RR.
The MB RR carries a domain name for a host in its RDATA
field. The mailer should deliver the message to that host
via whatever protocol is applicable, e.g., b,SMTP.
4. The query can return one or more Mail Group (MG) RRs.
This condition means that the mailbox was actually a mailing
list or mail group, rather than a single mailbox. Each MG RR
has a RDATA field that identifies a mailbox that is a member
of the group. The mailer should deliver a copy of the
message to each member.
5. The query can return a MB RR as well as one or more MG RRs.
This condition means the the mailbox was actually a mailing
list. The mailer can either deliver the message to the host
specified by the MB RR, which will in turn do the delivery to
all members, or the mailer can use the MG RRs to do the
expansion itself.
In any of these cases, the response may include a Mail Information
(MINFO) RR. This RR is usually associated with a mail group, but is
legal with a MB. The MINFO RR identifies two mailboxes. One of these
identifies a responsible person for the original mailbox name. This
mailbox should be used for requests to be added to a mail group, etc.
The second mailbox name in the MINFO RR identifies a mailbox that should
receive error messages for mail failures. This is particularly
appropriate for mailing lists when errors in member names should be
reported to a person other than the one who sends a message to the list.
Mockapetris [Page 49]
RFC 1035 Domain Implementation and Specification November 1987
New fields may be added to this RR in the future.
9. REFERENCES and BIBLIOGRAPHY
[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
Technical Plan - Name Service, April 1987, version 1.9.
Describes the fundamentals of the Hesiod name service.
[IEN-116] J. Postel, "Internet Name Server", IEN-116,
USC/Information Sciences Institute, August 1979.
A name service obsoleted by the Domain Name System, but
still in use.
[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
Communications of the ACM, October 1986, volume 29, number
10.
[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
Information Center, SRI International, December 1977.
[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
USC/Information Sciences Institute, August 1980.
[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
USC/Information Sciences Institute, September 1981.
[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
September 1981.
Suggests introduction of a hierarchy in place of a flat
name space for the Internet.
[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
USC/Information Sciences Institute, February 1982.
[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
Internet Host Table Specification", RFC-810, Network
Information Center, SRI International, March 1982.
Obsolete. See RFC-952.
[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
Server", RFC-811, Network Information Center, SRI
International, March 1982.
Mockapetris [Page 50]
RFC 1035 Domain Implementation and Specification November 1987
Obsolete. See RFC-953.
[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
Network Information Center, SRI International, March
1982.
[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC-819, Network
Information Center, SRI International, August 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
USC/Information Sciences Institute, August 1980.
[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
RFC-830, Network Information Center, SRI International,
October 1982.
Early thoughts on the design of the domain system.
Current implementation is completely different.
[RFC-882] P. Mockapetris, "Domain names - Concepts and
Facilities," RFC-882, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
[RFC-883] P. Mockapetris, "Domain names - Implementation and
Specification," RFC-883, USC/Information Sciences
Institute, November 1983.
Superceeded by this memo.
[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
RFC-920, USC/Information Sciences Institute,
October 1984.
Explains the naming scheme for top level domains.
[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
Table Specification", RFC-952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address
table replaced by the DNS.
Mockapetris [Page 51]
RFC 1035 Domain Implementation and Specification November 1987
[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
RFC-953, SRI, October 1985.
This RFC contains the official specification of the
hostname server protocol, which is obsoleted by the DNS.
This TCP based protocol accesses information stored in
the RFC-952 format, and is used to obtain copies of the
host table.
[RFC-973] P. Mockapetris, "Domain System Changes and
Observations", RFC-973, USC/Information Sciences
Institute, January 1986.
Describes changes to RFC-882 and RFC-883 and reasons for
them.
[RFC-974] C. Partridge, "Mail routing and the domain system",
RFC-974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail
addressing to the more powerful MX system used with the
domain system.
[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Concepts and Methods",
RFC-1001, March 1987.
This RFC and RFC-1002 are a preliminary design for
NETBIOS on top of TCP/IP which proposes to base NetBIOS
name service on top of the DNS.
[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed
Specifications", RFC-1002, March 1987.
[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
Contains socket numbers and mnemonics for host names,
operating systems, etc.
[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
November 1987.
Describes a plan for converting the MILNET to the DNS.
[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
Administrators", RFC-1032, November 1987.
Mockapetris [Page 52]
RFC 1035 Domain Implementation and Specification November 1987
Describes the registration policies used by the NIC to
administer the top level domains and delegate subzones.
[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
RFC-1033, November 1987.
A cookbook for domain administrators.
[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
Name Server", Computer Networks, vol 6, nr 3, July 1982.
Describes a name service for CSNET which is independent
from the DNS and DNS use in the CSNET.
Mockapetris [Page 53]
RFC 1035 Domain Implementation and Specification November 1987
Index
* 13
; 33, 35
<character-string> 35
<domain-name> 34
@ 35
\ 35
A 12
Byte order 8
CH 13
Character case 9
CLASS 11
CNAME 12
Completion 42
CS 13
Hesiod 13
HINFO 12
HS 13
IN 13
IN-ADDR.ARPA domain 22
Inverse queries 40
Mailbox names 47
MB 12
MD 12
MF 12
MG 12
MINFO 12
MINIMUM 20
MR 12
MX 12
NS 12
NULL 12
Port numbers 32
Primary server 5
PTR 12, 18
Mockapetris [Page 54]
RFC 1035 Domain Implementation and Specification November 1987
QCLASS 13
QTYPE 12
RDATA 12
RDLENGTH 11
Secondary server 5
SOA 12
Stub resolvers 7
TCP 32
TXT 12
TYPE 11
UDP 32
WKS 12
Mockapetris [Page 55]