rfc882.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,379 行 · 第 1/5 页
TXT
1,379 行
the existence to the appropriate administrators of other domains
so that they can incorporate NS records for the new name server
into their databases.
Name server logic
The processing steps that a name server performs in responding to
a query are conceptually simple, although implementations may have
internal databases that are quite complex.
For purposes of explanation, we assume that the query consists of
a type QTYPE, a class QCLASS, and a domain name QNAME; we assume
that the name server stores its RRs in sets where each set has all
of the RRs for a particular domain. Note that this database
structure and the following algorithms are meant to illustrate one
possible implementation, rather than a specification of how all
servers must be implemented.
The following notation is used:
ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME.
findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
for DOMAIN-NAME, or NULL if there is no such
information.
set(POINTER) refers to a set located previously by
findset, where POINTER is the value returned
by findset.
relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
relevant to the specified QTYPE. For
example, relevant(MAILA,MF) is true and
relevant(MAILA,NS) is false.
right(NAME,NUMBER) returns a domain name that is the rightmost
NUMBER labels in the string NAME.
Mockapetris [Page 15]
RFC 882 November 1983
Domain Names - Concepts and Facilities
copy(RR) copies the resource record specified by RR
into the response.
The name server code could be represented as the following
sequence of steps:
{ find out whether the database makes this server
authoritative for the domain name specified by QNAME }
for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
do begin
ptr:=findset(right(QNAME,i));
if ptr<>NULL
then { there is domain data for this domain name }
begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr:=ptr
end;
for all RRs in set(ptr)
do if type(RR)=SOA and class(RR)=QCLASS
then auth:=true
end
end;
end;
{ copy out authority search results }
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
{ Copy all RRs that answer the question }
for all RRs in set(ptr)
do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);
The first section of the code (delimited by the for loop over all
Mockapetris [Page 16]
RFC 882 November 1983
Domain Names - Concepts and Facilities
of the subnodes of QNAME) discovers whether the name server is
authoritative for the domain specified by QNAME. It sequences
through all containing domains of QNAME, starting at the root. If
it encounters a SOA it knows that the name server is authoritative
unless it finds a lower NS RR which delegates authority. If the
name server is authoritative, it sets auth=true; if the name
server is not authoritative, it sets NSptr to point to the set
which contains the NS RR closest to the domain specified by QNAME.
The second section of the code reflects the result of the
authority search into the response. If the name server is
authoritative, the code checks to see that the domain specified by
QNAME exists; if not, a name error is returned. If the name
server is not authoritative, the code copies the RRs for a closer
name server into the response.
The last section of the code copies all relevant RRs into the
response.
Note that this code is not meant as an actual implementation and
is incomplete in several aspects. For example, it doesn't deal
with providing additional information, wildcards, QCLASS=*, or
with overlapping zones. The first two of these issues are dealt
with in the following discussions, the remaining issues are
discussed in [14].
Additional information
When a resolver returns information to a user program, the
returned information will often lead to a second query. For
example, if a mailer asks a resolver for the appropriate mail
agent for a particular domain name, the name server queried by the
resolver returns a domain name that identifies the agent. In
general, we would expect that the mailer would then request the
domain name to address binding for the mail agent, and a new name
server query would result.
To avoid this duplication of effort, name servers return
additional information with a response which satisfies the
anticipated query. This information is kept in a separate section
of the response. Name servers are required to complete the
appropriate additional information if such information is
available, but the requestor should not depend on the presence of
the information since the name server may not have it. If the
resolver caches the additional information, it can respond to the
second query without an additional network transaction.
The appropriate information is defined in [14], but generally
Mockapetris [Page 17]
RFC 882 November 1983
Domain Names - Concepts and Facilities
consists of host to address bindings for domain names in returned
RRs.
Aliases and canonical names
In existing systems, hosts and other resources often have several
names that identify the same resource. For example, under current
ARPA Internet naming support, USC-ISIF and ISIF both identify the
same host. Similarly, in the case of mailboxes, many
organizations provide many names that actually go to the same
mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all
go to the same mailbox (although the mechanism behind this is
somewhat complicated).
Most of these systems have a notion that one of the equivalent set
of names is the canonical name and all others are aliases.
The domain system provides a similar feature using the canonical
name (CNAME) RR. When a name server fails to find a desired RR in
a set associated with some domain name, it checks to see if the
resource set contains a CNAME record with a matching class. If
so, the name server includes the CNAME record in the response, and
continues the query at the domain name specified in the data field
of the CNAME record.
Suppose a name server was processing a query with QNAME=ISIF.ARPA,
QTYPE=A, and QCLASS=IN, and had the following resource records:
ISIF.ARPA CNAME IN F.ISI.ARPA
F.ISI.ARPA A IN 10.2.0.52
Both of these RRs would be returned in the response.
In the above example, because ISIF.ARPA has no RRs other than the
CNAME RR, the resources associated with ISIF.ARPA will appear to
be exactly those associated with F.ISI.ARPA for the IN CLASS.
Since the CNAME is effective only when the search fails, a CNAME
can also be used to construct defaults. For example, suppose the
name server had the following set of RRs:
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA MD IN F.ISI.ARPA
XXXX.ARPA CNAME IN F.ISI.ARPA
XXXX.ARPA MF IN A.ISI.ARPA
Using this database, type A queries for XXXX.ARPA would return the
XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF
queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any
information from F.ISI.ARPA. This structure might be used to send
Mockapetris [Page 18]
RFC 882 November 1983
Domain Names - Concepts and Facilities
mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for
XXXX.ARPA to F.ISI.ARPA.
Wildcards
In certain cases, an administrator may wish to associate default
resource information for all or part of a domain. For example,
the CSNET domain administrator may wish to establish IN class mail
forwarding for all hosts in the CSNET domain without IN
capability. In such a case, the domain system provides a special
label "*" that matches any other label. Note that "*" matches
only a single label, and not zero or more than one label. Note
also that the "*" is distinct from the "*" values for QCLASS and
QTYPE.
The semantics of "*" depend upon whether it appears in a query
domain name (QNAME) or in a RR in a database.
When an "*" is used in a QNAME, it can only match a "*" in a
resource record.
When "*" appears in a RR in a database, it can never override
an existing exact match. For example, if a name server
received a query for the domain UDEL.CSNET, and had appropriate
RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would
be used and the *.CSNET RRs would be ignored. If a query to
the same database specified FOO.CSNET, the *.CSNET RR would be
used, but the corresponding labels from the QNAME would replace
the "*". Thus the FOO.CSNET query would match the *.CSNET RR
and return a RR for FOO.CSNET rather than *.CSNET.
RRs containing "*" labels are copied exactly when zones are
transfered via name server maintenance operations.
These semantics are easily implemented by having the name server
first search for an exact match for a query, and then replacing
the leftmost label with a "*" and trying again, repeating the
process until all labels became "*" or the search succeeded.
TYPE=* in RRs is prohibited. If it were to be allowed, the
requestor would have no way of interpreting the data in the RR
because this data is type dependent.
CLASS=* is also prohibited. Similar effects can be achieved using
QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
complexities without apparent benefit.
Mockapetris [Page 19]
RFC 882 November 1983
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?