rfc883.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,582 行 · 第 1/5 页
TXT
1,582 行
authoritative name server.
Standard query and response example
The overall structure of a query for retrieving information for
Internet mail for domain F.ISI.ARPA is shown below:
+-----------------------------------------+
Header | OPCODE=QUERY, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
The header includes an opcode field that specifies that this
datagram is a query, and an ID field that will be used to
associate replies with the original query. (Some additional
header fields have been omitted for clarity.) The question
section specifies that the type of the query is for mail agent
information, that only ARPA Internet information is to be
considered, and that the domain name of interest is F.ISI.ARPA.
The remaining sections are empty, and would not use any octets in
a real query.
Mockapetris [Page 15]
RFC 883 November 1983
Domain Names - Implementation and Specification
One possible response to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | ARPA NS IN A.ISI.ARPA |
| ------- |
| ARPA NS IN F.ISI.ARPA |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
This type of response would be returned by a name server that was
not an authority for the domain name F.ISI.ARPA. The header field
specifies that the datagram is a response to a query with an ID of
2304. The question section is copied from the question section in
the query datagram.
The answer section is empty because the name server did not have
any information that would answer the query. (Name servers may
happen to have cached information even if they are not
authoritative for the query.)
The best that this name server could do was to pass back
information for the domain ARPA. The authority section specifies
two name servers for the domain ARPA using the Internet family:
A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence
that F.ISI.ARPA is a name server for ARPA as well as the subject
of the query.
In this case, the name server included in the additional records
section the Internet addresses for the two hosts specified in the
authority section. Such additional data is almost always
available.
Given this response, the process that originally sent the query
might resend the query to the name server on A.ISI.ARPA, with a
new ID of 2305.
Mockapetris [Page 16]
RFC 883 November 1983
Domain Names - Implementation and Specification
The name server on A.ISI.ARPA might return a response:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2305 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA MD IN F.ISI.ARPA |
| ------- |
| F.ISI.ARPA MF IN A.ISI.ARPA |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
This query was directed to an authoritative name server, and hence
the response includes an answer but no authority records. In this
case, the answer section specifies that mail for F.ISI.ARPA can
either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The
additional records section specifies the Internet addresses of
these hosts.
The contents of inverse queries and responses
Inverse queries reverse the mappings performed by standard query
operations; while a standard query maps a domain name to a
resource, an inverse query maps a resource to a domain name. For
example, a standard query might bind a domain name to a host
address; the corresponding inverse query binds the host address to
a domain name.
Inverse query mappings are not guaranteed to be unique or complete
because the domain system does not have any internal mechanism for
determining authority from resource records that parallels the
capability for determining authority as a function of domain name.
In general, resolvers will be configured to direct inverse queries
to a name server which is known to have the desired information.
Name servers are not required to support any form of inverse
queries; it is anticipated that most name servers will support
address to domain name conversions, but no other inverse mappings.
If a name server receives an inverse query that it does not
support, it returns an error response with the "Not Implemented"
error set in the header. While inverse query support is optional,
all name servers must be at least able to return the error
response.
Mockapetris [Page 17]
RFC 883 November 1983
Domain Names - Implementation and Specification
When a name server processes an inverse query, it either returns:
1. zero, one, or multiple domain names for the specified
resource
2. an error code indicating that the name server doesn't
support inverse mapping of the specified resource type.
Inverse query and response example
The overall structure of an inverse query for retrieving the
domain name that corresponds to Internet address 10.2.0.52 is
shown below:
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
This query asks for a question whose answer is the Internet style
address 10.2.0.52. Since the owner name is not known, any domain
name can be used as a placeholder (and is ignored). The response
to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
Note that the QTYPE in a response to an inverse query is the same
as the TYPE field in the answer section of the inverse query.
Responses to inverse queries may contain multiple questions when
the inverse is not unique.
Mockapetris [Page 18]
RFC 883 November 1983
Domain Names - Implementation and Specification
Completion queries and responses
Completion queries ask a name server to complete a partial domain
name and return a set of RRs whose domain names meet a specified
set of criteria for "closeness" to the partial input. This type
of query can provide a local shorthand for domain names or command
completion similar to that in TOPS-20.
Implementation of completion query processing is optional in a
name server. However, a name server must return a "Not
Implemented" (NI) error response if it does not support
completion.
The arguments in a completion query specify:
1. A type in QTYPE that specifies the type of the desired name.
The type is used to restrict the type of RRs which will match
the partial input so that completion queries can be used for
mailbox names, host names, or any other type of RR in the
domain system without concern for matches to the wrong type of
resource.
2. A class in QCLASS which specifies the desired class of the RR.
3. A partial domain name that gives the input to be completed.
All returned RRs will begin with the partial string. The
search process first looks for names which qualify under the
assumption that the partial string ends with a full label
("whole label match"); if this search fails, the search
continues under the assumption that the last label in the
partial sting may be an incomplete label ("partial label
match"). For example, if the partial string "Smith" was used
in a mailbox completion, it would match Smith@ISI.ARPA in
preference to Smithsonian@ISI.ARPA.
The partial name is supplied by the user through the user
program that is using domain services. For example, if the
user program is a mail handler, the string might be "Mockap"
which the user intends as a shorthand for the mailbox
Mockapetris@ISI.ARPA; if the user program is TELNET, the user
might specify "F" for F.ISI.ARPA.
In order to make parsing of messages consistent, the partial
name is supplied in domain name format (i.e. a sequence of
labels terminated with a zero length octet). However, the
trailing root label is ignored during matching.
4. A target domain name which specifies the domain which is to be
examined for matches. This name is specified in the additional
Mockapetris [Page 19]
RFC 883 November 1983
Domain Names - Implementation and Specification
section using a NULL RR. All returned names will end with the
target name.
The user program which constructs the query uses the target
name to restrict the search. For example, user programs
running at ISI might restrict completion to names that end in
ISI.ARPA; user programs running at MIT might restrict
completion to the domain MIT.ARPA.
The target domain name is also used by the resolver to
determine the name server which should be used to process the
query. In general, queries should be directed to a name server
that is authoritative for the target domain name. User
programs which wish to provide completion for a more than one
target can issue multiple completion queries, each directed at
a different target. Selection of the target name and the
number of searches will depend on the goals of the user
program.
5. An opcode for the query. The two types of completion queries
are "Completion Query - Multiple", or CQUERYM, which asks for
all RRs which could complete the specified input, and
"Completion Query - Unique", or CQUERYU, which asks for the
"best" completion.
CQUERYM is used by user programs which want to know if
ambiguities exist or wants to do its own determinations as to
the best choice of the available candidates.
CQUERYU is used by user programs which either do not wish to
deal with multiple choices or are willing to use the closeness
criteria used by CQUERYU to select the best match.
When a name server receives either completion query, it first
looks for RRs that begin (on the left) with the same labels as are
found in QNAME (with the root deleted), and which match the QTYPE
and QCLASS. This search is called "whole label" matching. If one
or more hits are found the name server either returns all of the
hits (CQUERYM) or uses the closeness criteria described below to
eliminate all but one of the matches (CQUERYU).
If the whole label match fails to find any candidates, then the
name server assumes that the rightmost label of QNAME (after root
deletion) is not a complete label, and looks for candidates that
would match if characters were added (on the right) to the
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?