RFC 0883
Domain names: Implementation specification
field in the new SOA record with the SERIAL field in the SOA
record of the existing zone copy. If these values match, the zone
has not been updated since the last copy and hence there is no
reason to recopy the zone. In this case the name server resets
the times in the existing SOA record and closes the virtual
circuit to complete the operation.
If this is initial load, or the SERIAL fields were different, the
name server requests a copy of the zone by sending the foreign
name server an AXFR query which specifies the zone by its QCLASS
and QNAME fields.
When the foreign name server receives the AXFR request, it sends
each node from the zone to the requestor in a separate message.
It begins with the node that contains the SOA record, walks the
tree in breadth-first order, and completes the transfer by
resending the node containing the SOA record.
Several error conditions are possible:
If the AXFR request cannot be matched to a SOA, the foreign
name server will return a single message in response that does
not contain the AXFR request. (The normal SOA query preceding
the AXFR is designed to avoid this condition, but it is still
possible.)
The foreign name server can detect an internal error or detect
some other condition (e.g. system going down, out of resources,
etc.) that forces the transfer to be aborted. If so, it sends
a message with the "Server failure" condition set. If the AXFR
can be immediately retried with some chance of success, it
leaves the virtual open; otherwise it initiates a close.
If the foreign name server doesn't wish to perform the
operation for policy reasons (i.e. the system administrator
wishes to forbid zone copies), the foreign server returns a
"Refused" condition.
The requestor receives these records and builds a new tree. This
tree is not yet in the status table, so its data are not used to
process queries. The old copy of the zone, if any, may be used to
satisfy request while the transfer is in progress.
When the requestor receives the second copy of the SOA node, it
compares the SERIAL field in the first copy of the SOA against the
SERIAL field in the last copy of the SOA record. If these don't
match, the foreign server updated its zone while the transfer was
in progress. In this case the requestor repeats the AXFR request
to acquire the newer version.
If the AXFR transfer eventually succeeds, the name server closes
the virtual circuit and and creates new versions of inversion data
structures for this zone. When this operation is complete, the
name server acquires the main lock in write mode and then replaces
any old copy of the zone and inversion data structures with new
ones. The name server then releases the main lock, and can
reclaim the storage used by the old copy.
If an error occurs during the AXFR transfer, the name server can
copy any partial information into its cache tree if it wishes,
although it will not normally do so if the zone transfer was a
refresh rather than an initial load.
RESOLVER ALGORITHMS
Operations
Resolvers have a great deal of latitude in the semantics they
allow in user calls. For example, a resolver might support
different user calls that specify whether the returned information
must be from and authoritative name server or not. Resolvers are
also responsible for enforcement of any local restrictions on
access, etc.
In any case, the resolver will transform the user query into a
number of shared database accesses and queries to remote name
servers. When a user requests a resource associated with a
particular domain name, the resolver will execute the following
steps:
1. The resolver first checks the local shared database, if any,
for the desired information. If found, it checks the
applicable timeout. If the timeout check succeeds, the
information is used to satisfy the user request. If not, the
resolver goes to step 2.
2. In this step, the resolver consults the shared database for the
name server that most closely matches the domain name in the
user query. Multiple redundant name servers may be found. The
resolver goes to step 3.
3. In this step the resolver chooses one of the available name
servers and sends off a query. If the query fails, it tries
another name server. If all fail, an error indication is
returned to the user. If a reply is received the resolver adds
the returned RRs to its database and goes to step 4.
4. In this step, the resolver interprets the reply. If the reply
contains the desired information, the resolver returns the
information to the user. The the reply indicates that the
domain name in the user query doesn't exist, then the resolver
returns an error to the user. If the reply contains a
transient name server failure, the resolver can either wait and
retry the query or go back to step 3 and try a different name
server. If the reply doesn't contain the desired information,
but does contain a pointer to a closer name server, the
resolver returns to step 2, where the closer name servers will
be queried.
Several modifications to this algorithm are possible. A resolver
may not support a local cache and instead only cache information
during the course of a single user request, discarding it upon
completion. The resolver may also find that a datagram reply was
truncated, and open a virtual circuit so that the complete reply
can be recovered.
Inverse and completion queries must be treated in an
environment-sensitive manner, because the domain system doesn't
provide a method for guaranteeing that it can locate the correct
information. The typical choice will be to configure a resolver
to use a particular set of known name servers for inverse queries.
DOMAIN SUPPORT FOR MAIL
Introduction
Mail service is a particularly sensitive issue for users of the
domain system because of the lack of a consistent system for
naming mailboxes and even hosts, and the need to support continued
operation of existing services. This section discusses an
evolutionary approach for adding consistent domain name support
for mail.
The crucial issue is deciding on the types of binding to be
supported. Most mail systems specify a mail destination with a
two part construct such as X@Y. The left hand side, X, is an
string, often a user or account, and Y is a string, often a host.
This section refers to the part on the left, i.e. X, as the local
part, and refers to the part on the right, i.e. Y, as the global
part.
Most existing mail systems route mail based on the global part; a
mailer with mail to deliver to X@Y will decide on the host to be
contacted using only Y. We refer to this type of binding as
"agent binding".
For example, mail addressed to Mockapetris@ISIF is delivered to
host USC-ISIF (USC-ISIF is the official name for the host
specified by nickname ISIF).
More sophisticated mail systems use both the local and global
parts, i.e. both X and Y to determine which host should receive
the mail. These more sophisticated systems usually separate the
binding of the destination to the host from the actual delivery.
This allows the global part to be a generic name rather than
constraining it to a single host. We refer to this type of
binding as "mailbox binding".
For example, mail addressed to Mockapetris@ISI might be bound
to host F.ISI.ARPA, and subsequently delivered to that host,
while mail for Cohen@ISI might be bound to host B.ISI.ARPA.
The domain support for mail consists of two levels of support,
corresponding to these two binding models.
The first level, agent binding, is compatible with existing
ARPA Internet mail procedures and uses maps a global part onto
one or more hosts that will accept the mail. This type of
binding uses the MAILA QTYPE.
The second level, mailbox binding, offers extended services
that map a local part and a global part onto one or more sets
of data via the MAILB QTYPE. The sets of data include hosts
that will accept the mail, mailing list members (mail groups),
and mailboxes for reporting errors or requests to change a mail
group.
The domain system encodes the global part of a mail destination as
a domain name and uses dots in the global part to separate labels
in the encoded domain name. The domain system encodes the local
part of a mail destination as a single label, and any dots in this
part are simply copied into the label. The domain system forms a
complete mail destination as the local label concatenated to the
domain string for the global part. We call this a mailbox.
For example, the mailbox Mockapetris@F.ISI.ARPA has a global
domain name of three labels, F.ISI.ARPA. The domain name
encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The
mailbox Mockapetris.cad@F.ISI.ARPA has the same domain name for
the global part and a 4 label domain name for the mailbox of
Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label,
its merely used to denote the "quoted" dot).
It is anticipated that the Internet system will adopt agent
binding as part of the initial implementation of the domain
system, and that mailbox binding will eventually become the
preferred style as organizations convert their mail systems to the
new style. To facilitate this approach, the domain information
for these two binding styles is organized to allow a requestor to
determine which types of support are available, and the
information is kept in two disjoint classes.
Agent binding
In agent binding, a mail system uses the global part of the mail
destination as a domain name, with dots denoting structure. The
domain name is resolved using a MAILA query which return MF and MD
RRs to specify the domain name of the appropriate host to receive
the mail. MD (Mail delivery) RRs specify hosts that are expected
to have the mailbox in question; MF (Mail forwarding) RRs specify
hosts that are expected to be intermediaries willing to accept the
mail for eventual forwarding. The hosts are hints, rather than
definite answers, since the query is made without the full mail
destination specification.
For example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a
query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return
two RRs:
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
The mailer would interpret these to mean that the mail agent on
F.ISI.ARPA should be able to deliver the mail directly, but that
A.ISI.ARPA is willing to accept the mail for probable forwarding.
Using this system, an organization could implement a system that
uses organization names for global parts, rather than the usual
host names, but all mail for the organization would be routed the
same, regardless of its local part. Hence and organization with
many hosts would expect to see many forwarding operations.
Mailbox binding
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:
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 agent 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. 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. New fields may be added
to this RR in the future.
Appendix 1 - Domain Name Syntax Specification
The preferred syntax of domain names is given by the following BNF
rules. Adherence to this syntax will result in fewer problems with
many applications that use domain names (e.g., mail, TELNET). Note
that some applications use domain names containing binary information
and hence do not follow this syntax.
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in domain
names no significance is attached to the case. That is, two names
with the same spelling but different case are to be treated as if
identical.
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
For example, the following strings identify hosts in the ARPA
Internet:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Appendix 2 - Field formats and encodings
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| The following formats are preliminary and |
| are included for purposes of explanation only.|
| In particular, new RR types will be added, |
| and the size, position, and encoding of |
| fields are subject to change. |
| |
+-----------------------------------------------+
TYPE values
TYPE fields are used in resource records. Note that these types
are not the same as the QTYPE fields used in queries, although the
functions are often similar.
TYPE value meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination
MF 4 a mail forwarder
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name
MG 8 a mail group member
MR 9 a mail rename domain name
NULL 10 a null RR
WKS 11 a well known service description
PTR 12 a domain name pointer
HINFO 13 host information
MINFO 14 mailbox or mail list information
QTYPE values
QTYPE fields appear in the question part of a query. They include
the values of TYPE with the following additions:
AXFR 252 A request for a transfer of an entire zone of authority
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (MD and MF)
* 255 A request for all records
CLASS values
CLASS fields appear in resource records
CLASS value meaning
IN 1 the ARPA Internet
CS 2 the computer science network (CSNET)
QCLASS values
QCLASS fields appear in the question section of a query. They
include the values of CLASS with the following additions:
* 255 any class
Standard resource record formats
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME - a compressed domain name to which this resource
record pertains.
TYPE - two octets containing one of the RR type codes
defined in Appendix 2. This field specifies the
meaning of the data in the RDATA field.
CLASS - two octets which specifies the class of the data in
the RDATA field.
TTL - a 16 bit signed integer that specifies the time
interval that the resource record may be cached
before the source of the information should again be
consulted. Zero values are interpreted to mean that
the RR can only be used for the transaction in
progress, and should not be cached. For example, SOA
records are always distributed with a zero TTL to
prohibit caching. Zero values can also be used for
extremely volatile data.
RDLENGTH- an unsigned 16 bit integer that specifies the length
in octets of the RDATA field.
RDATA - a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource
record.
The format of the RDATA field is standard for all classes for the
RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and
NULL. These formats are shown below together with the appropriate
additional section RR processing.
CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME - A compressed domain name which specifies that the
domain name of the RR is an alias for a canonical
name specified by CNAME.
CNAME records cause no additional section processing. The
RDATA section of a CNAME line in a master file is a standard
printed domain name.
HINFO RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CPU - A character string which specifies the CPU type. The
character string is represented as a single octet
length followed by that number of characters. The
following standard strings are defined:.
PDP-11/70 C/30 C/70 VAX-11/780
H-316 H-516 DEC-2060 DEC-1090T
ALTO IBM-PC IBM-PC/XT PERQ
IBM-360/67 IBM-370/145
OS - A character string which specifies the operating system
type. The character string is represented as a single octet
length followed by that number of characters. The following
standard types are defined:.
ASP AUGUST BKY CCP
DOS/360 ELF EPOS EXEC-8
GCOS GPOS ITS INTERCOM
KRONOS MCP MOS MPX-RT
MULTICS MVT NOS NOS/BE
OS/MVS OS/MVT RIG RSX11
RSX11M RT11 SCOPE SIGNAL
SINTRAN TENEX TOPS10 TOPS20
TSS UNIX VM/370 VM/CMS
VMS WAITS
HINFO records cause no additional section processing.
HINFO records are used to acquire general information about a
host. The main use is for protocols such as FTP that can use
special procedures when talking between machines or operating
systems of the same type.
MB RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has the specified mailbox.
MB records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MB line in a master file is a standard printed domain
name.
MD RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has a mail agent for the domain which should be able
to deliver mail for the domain.
MD records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MD line in a master file is a standard printed domain
name.
MF RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has a mail agent for the domain which will accept
mail for forwarding to the domain.
MF records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MF line in a master file is a standard printed domain
name.
MG RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MGMNAME - A compressed domain name which specifies a mailbox
which is a member of the mail group specified by the
domain name.
MF records cause no additional section processing. The RDATA
section of a MF line in a master file is a standard printed
domain name.
MINFO RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EMAILBX /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
RMAILBX - A compressed domain name which specifies a mailbox
which is responsible for the mailing list or mailbox.
If this domain name names the root, the owner of the
MINFO RR is responsible for itself. Note that many
existing mailing lists use a mailbox X-request for
the RMAILBX field of mailing list X, e.g.
Msgroup-request for Msgroup. This field provides a
more general mechanism.
EMAILBX - A compressed domain name which specifies a mailbox
which is to receive error messages related to the
mailing list or mailbox specified by the owner of the
MINFO RR (similar to the ERRORS-TO: field which has
been proposed). If this domain name names the root,
errors should be returned to the sender of the
message.
MINFO records cause no additional section processing. Although
these records can be associated with a simple mailbox, they are
usually used with a mailing list. The MINFO section of a MF
line in a master file is a standard printed domain name.
MR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NEWNAME - A compressed domain name which specifies a mailbox
which is the proper rename of the specified mailbox.
MR records cause no additional section processing. The RDATA
section of a MR line in a master file is a standard printed
domain name.
NULL RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is
65535 octets or less.
NULL records cause no additional section processing. NULL RRs
are not allowed in master files.
NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME - A compressed domain name which specifies a host which
has a name server for the domain.
NS records cause both the usual additional section processing
to locate a type A record, and a special search of the zone in
which they reside. The RDATA section of a NS line in a master
file is a standard printed domain name.
PTR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME - A compressed domain name which points to some
location in the domain name space.
PTR records cause no additional section processing. These RRs
are used in special domains to point to some other location in
the domain space. These records are simple data, and don't
imply any special processing similar to that performed by
CNAME, which identifies aliases. Appendix 3 discusses the use
of these records in the ARPA Internet address domain.
SOA RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MNAME - The domain name of the name server that was the
original source of data for this zone.
RNAME - A domain name which specifies the mailbox of the
person responsible for this zone.
SERIAL - The unsigned 16 bit version number of the of the
original copy of the zone. This value wraps and
should be compared using sequence space arithmetic.
REFRESH - The unsigned 32 bit time interval before the zone
should be refreshed.
RETRY - The unsigned 32 bit time interval that should elapse
before a failed refresh should be retried.
EXPIRE - A 32 bit time value that specifies the upper limit on
the time interval that can elapse before the zone is
no longer authoritative.
MINIMUM - The unsigned 16 bit minimum TTL field that should be
exported with any RR from this zone (other than the
SOA itself).
SOA records cause no additional section processing. The RDATA
section of a SOA line in a master file is a standard printed
domain name for MNAME, a standard X@Y mailbox specification for
RNAME, and decimal numbers for the remaining parameters.
All times are in units of seconds.
Most of these fields are pertinent only for name server
maintenance operations. However, MINIMUM is used in all query
operations that retrieve RRs from a zone. Whenever a RR is
sent in a response to a query, the TTL field is set to the
maximum of the TTL field from the RR and the MINIMUM field in
the appropriate SOA. Thus MINIMUM is a lower bound on the TTL
field for all RRs in a zone. RRs in a zone are never discarded
due to timeout unless the whole zone is deleted. This prevents
partial copies of zones.
Appendix 3 - Internet specific field formats and operations
Message transport
The Internet supports name server access using TCP [10] on server
port 53 (decimal) as well as datagram access using UDP [11] on UDP
port 53 (decimal). Messages sent over TCP virtual circuits are
preceded by an unsigned 16 bit length field which describes the
length of the message, excluding the length field itself.
+-----------------------------------------------+
| |
| ***** WARNING ***** |
| |
| The following formats are preliminary and |
| are included for purposes of explanation only.|
| In particular, new RR types will be added, |
| and the size, position, and encoding of |
| fields are subject to change. |
| |
+-----------------------------------------------+
A RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS - A 32 bit ARPA internet address
Hosts that have multiple ARPA Internet addresses will have
multiple A records.
A records cause no additional section processing. The RDATA
section of an A line in a master file is an Internet address
expressed as four decimal numbers separated by dots without any
imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
WKS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS - An 32 bit ARPA Internet address
PROTOCOL - An 8 bit IP protocol number
<BIT MAP> - A variable length bit map. The bit map must be a
multiple of 8 bits long.
The WKS record is used to describe the well known services
supported by a particular protocol on a particular internet
address. The PROTOCOL field specifies an IP protocol number, and
the bit map has one bit per port of the specified protocol. The
first bit corresponds to port 0, the second to port 1, etc. If
less than 256 bits are present, the remainder are assumed to be
zero. The appropriate values for ports and protocols are
specified in [13].
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
port 25 (SMTP). If this bit is set, a SMTP server should be
listening on TCP port 25; if zero, SMTP service is not supported
on the specified address.
The anticipated use of WKS RRs is to provide availability
information for servers for TCP and UDP. If a server supports
both TCP and UDP, or has multiple Internet addresses, then
multiple WKS RRs are used.
WKS RRs cause no additional section processing. The RDATA section
of a WKS record consists of a decimal protocol number followed by
mnemonic identifiers which specify bits to be set to 1.
IN-ADDR special domain
The ARPA internet uses a special domain to support gateway
location and ARPA Internet address to host mapping. The intent of
this domain is to allow queries to locate all gateways on a
particular network in the ARPA Internet, and also to provide a
guaranteed method to perform host address to host name mapping.
Note that both of these services are similar to functions that
could be performed by inverse queries; the difference is that this
part of the domain name space is structured according to address,
and hence can guarantee that the appropriate data can be located
without an exhaustive search of the domain space. It is
anticipated that the special tree will be used by ARPA Internet
resolvers for all gateway location services, but that address to
name resolution will be performed by first trying the inverse
query on the local name server database followed by a query in the
special space if the inverse query fails.
The domain is a top level domain called IN-ADDR whose substructure
follows the ARPA Internet addressing structure.
Domain names in the IN-ADDR domain are defined to have up to four
labels in addition to the IN-ADDR label. Each label is a
character string which expresses a decimal value in the range
0-255 (with leading zeros omitted except in the case of a zero
octet which is represented by a single zero). These labels
correspond to the 4 octets of an ARPA Internet address.
Host addresses are represented by domain names that have all four
labels specified. Thus data for ARPA Internet address 10.2.0.52
is located at domain name 52.0.2.10.IN-ADDR. The reversal, though
awkward to read, allows zones to follow the natural grouping of
hosts within networks. For example, 10.IN-ADDR can be a zone
containing data for the ARPANET, while 26.IN-ADDR can be a
separate zone for MILNET. Address nodes are used to hold pointers
to primary host names in the normal domain space.
Network addresses correspond to some of the non-terminal nodes in
the IN-ADDR tree, since ARPA Internet network numbers are either
1, 2, or 3 octets. Network nodes are used to hold pointers to
primary host names (which happen to be gateways) in the normal
domain space. Since a gateway is, by definition, on more than one
network, it will typically have two or more network nodes that
point at the gateway. Gateways will also have host level pointers
at their fully qualified addresses.
Both the gateway pointers at network nodes and the normal host
pointers at full address nodes use the PTR RR to point back to the
primary domain names of the corresponding hosts.
For example, part of the IN-ADDR domain will contain information
about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and
MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses
10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the
MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name
GW.MIT.ARPA, the domain database would contain:
10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
10.IN-ADDR PTR IN GW.MIT.ARPA
18.IN-ADDR PTR IN GW.MIT.ARPA
26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA
4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA
52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA
6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
Thus a program which wanted to locate gateways on net 10 would
originate a query of the form QTYPE=PTR, QCLASS=IN,
QNAME=10.IN-ADDR. It would receive two RRs in response:
10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
10.IN-ADDR PTR IN GW.MIT.ARPA
The program could then originate QTYPE=A, QCLASS=IN queries for
MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet
addresses of these gateways.
A resolver which wanted to find the host name corresponding to
ARPA Internet host address 10.0.0.6 might first try an inverse
query on the local name server, but find that this information
wasn't available. It could then try a query of the form
QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive:
6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
Several cautions apply to the use of these services:
Since the IN-ADDR special domain and the normal domain for a
particular host or gateway will be in different zones, the
possibility exists that that the data may be inconsistent.
Gateways will often have two names in separate domains, only
one of which can be primary.
Systems that use the domain database to initialize their
routing tables must start with enough gateway information to
guarantee that they can access the appropriate name server.
The gateway data only reflects the existence of a gateway in a
manner equivalent to the current HOSTS.TXT file. It doesn't
replace the dynamic availability information from GGP or EGP.
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982. [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982. [4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982. [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. [8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982. [10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980. [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983. [14] P. Mockapetris, "Domain names - Concepts and Facilities," RFC 882, USC/Information Sciences Institute, November 1983.
INDEX
* usage........................................................37, 57
A RDATA format.....................................................67
byte order..........................................................6
cache queue....................................................35, 42
character case..................................................7, 31
CLASS...........................................................9, 58
completion.........................................................19
compression........................................................31
CNAME RR...........................................................60
header format......................................................26
HINFO RR...........................................................60
include files......................................................43
inverse queries....................................................17
mailbox names......................................................53
master files.......................................................43
MB RR..............................................................61
MD RR..............................................................61
message format.....................................................13
MF RR..............................................................62
MG RR..............................................................62
MINFO RR...........................................................63
MR RR..............................................................63
NULL RR............................................................64
NS RR..............................................................64
PTR RR.........................................................64, 69
QCLASS.............................................................58
QTYPE..............................................................57
queries (standard).................................................15
recursive service..................................................24
RR format..........................................................59
SOA RR.............................................................65
Special domains....................................................68
TYPE...............................................................57
WKS type RR........................................................68