RR
Click on the red underlined text to get to the source
... RR types and data formats for describing the object.
...
... which is a subset of the usual text representation for domain names,
together with RR formats for describing host addresses, etc. Because we
...
... information, which may be empty. The set of resource information
associated with a particular name is composed of separate resource
records (RRs). The order of RRs in a set is not significant, and need
not be preserved by name servers, resolvers, or other parts of the DNS ...
... associated with a particular name is composed of separate resource
records (RRs). The order of RRs in a set is not significant, and need
not be preserved by name servers, resolvers, or other parts of the DNS.
...
...
When we talk about a specific RR, we assume it has the following:
...
... which is the domain name where the RR is found. ...
... integer in units of seconds, an is primarily used by
resolvers when they cache RRs. The TTL describes how
long a RR ...
...
The owner name is often implicit, rather than forming an integral part
of the RR. For example, many name servers internally form tree or hash
...
... hash
structures for the name space, and chain RRs off nodes. The remaining
RR parts are the fixed ...
... class, TTL) which is consistent for
all RRs, and a variable part (RDATA) that fits the needs of the resource
being described.
...
...
The meaning of the TTL field is a time limit on how long an RR can be
kept in a cache. This limit does not apply to authoritative data in
...
...
The data in the RDATA section of RRs is carried as a combination of
binary strings and domain names. The domain names ...
... Textual expression of RRs ...
...
RRs are represented in binary form in the packets of the DNS protocol,
and are usually represented in highly encoded form when stored in a name
server ...
... and are usually represented in highly encoded form when stored in a name
server or resolver. In this memo, we adopt a style similar to that used
in master files in order to show the contents of RRs. In this format,
most RRs are shown on a single line, although continuation lines are
...
... in master files in order to show the contents of RRs. In this format,
most RRs are shown on a single line, although continuation lines are
possible using parentheses.
...
...
The start of the line gives the owner of the RR. If a line begins with
a blank, then the owner is assumed to be the same as that of the
previous RR ...
... RR. If a line begins with
a blank, then the owner is assumed to be the same as that of the
previous RR. Blank lines are often included for readability.
...
... Following the owner, we list the TTL, type, and class of the RR. Class
and type use the mnemonics ...
...
The resource data or RDATA section of the RR are given using knowledge
of the typical representation for the data.
...
...
For example, we might show the RRs carried in a message as:
...
... followed by a domain name. The address RRs use a standard IP address
format to contain a 32 bit ...
... CNAME) RR. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical ...
... specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node ...
... section of the
RR. If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical ...
... cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
...
... DNS software. When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
...
...
Domain names in RRs which point at another name should always point at
the primary name and not the alias. This avoids extra indirections in
...
... alias. This avoids extra indirections in
accessing information. For example, the address to name RR for the
above host should be:
...
... containing a number of fixed fields which
are always present, and four sections which carry query parameters and
RRs.
...
... Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
...
... Carries RRs which describe other authoritative servers.
May optionally carry the SOA RR for the authoritative
data in the answer section. ...
... (QTYPE), and query class (QCLASS) and asks for RRs which match. This
type of query makes up such a vast majority of DNS queries ...
... matches all RR types. ...
... domain name, QTYPE, and QCLASS, the name server looks
for matching RRs. In addition to relevant records, the name server may
return RRs ...
... RRs. In addition to relevant records, the name server may
return RRs that point toward a name server that has the desired
information or RRs ...
... RRs that point toward a name server that has the desired
information or RRs that are expected to be useful in interpreting the
relevant RRs. For example, a name server ...
... information or RRs that are expected to be useful in interpreting the
relevant RRs. For example, a name server that doesn't have the
requested information may know a name server ...
... name server
that returns a domain name in a relevant RR may also return the RR that
binds that domain name ...
... that returns a domain name in a relevant RR may also return the RR that
binds that domain name to an address ...
... example, while a standard query might map a domain name to a SOA RR, the
corresponding inverse query might map the SOA RR ...
... queries may not return the proper TTL, and do not indicate cases
where the identified RR is one of a set (for example, one address for a
host having ...
... for a
host having multiple addresses). Therefore, the RRs returned in inverse
queries should never be cached.
...
...
All of this data is expressed in the form of RRs, so a zone can be
completely described in terms of a set of RRs. Whole zones can be
...
... All of this data is expressed in the form of RRs, so a zone can be
completely described in terms of a set of RRs. Whole zones can be
transferred between name servers by transferring the RRs, either carried
...
... completely described in terms of a set of RRs. Whole zones can be
transferred between name servers by transferring the RRs, either carried
in a series of messages or by FTPing a master file which is a textual
representation.
...
...
The authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node ...
...
Though logically part of the authoritative data, the RRs that describe
the top node of the zone are especially important to the zone's
...
... the top node of the zone are especially important to the zone's
management. These RRs are of two types: name server RRs that list, one
...
... management. These RRs are of two types: name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR ...
... name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
describes zone management ...
... RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
describes zone management parameters.
...
... The RRs that describe cuts around the bottom of the zone are NS RRs that
name the servers for the subzones. Since the cuts are between nodes,
...
... name the servers for the subzones. Since the cuts are between nodes,
these RRs are NOT part of the authoritative data of the zone, and should
be exactly the same as the corresponding RRs in the top node ...
... these RRs are NOT part of the authoritative data of the zone, and should
be exactly the same as the corresponding RRs in the top node of the
subzone. Since name servers are always associated with zone boundaries,
...
... of the
subzone. Since name servers are always associated with zone boundaries,
NS RRs are only found at nodes which are the top node of some zone. In
...
... node of some zone. In
the data that makes up a zone, NS RRs are found at the top node of the
zone (and are authoritative) and at cuts around the bottom of the zone
...
... subzones. That is, parent zones have all the information needed to
access servers for their children zones. The NS RRs that name the
servers for subzones are often not enough for this task since they name
the servers, but do not give their addresses ...
... name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address ...
... address, we should contact the server using the address we wish
to learn. To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs ...
... RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server ...
... address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.
...
... As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation ...
... delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
...
... administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.
...
... query, possibly preface by one or more CNAME
RRs that specify aliases encountered on the way to an answer.
...
... name error indicating that the name does not exist. This
may include CNAME RRs that indicate that the original query
name was an alias ...
...
RRs that answer the question, together with an indication
whether the data comes from a zone or is cached.
...
... RRs that the name server thinks will prove useful to the
requester. ...
... name server will depend on the local OS
and data structures used to store RRs. The following algorithm assumes
that the RRs ...
... RRs. The following algorithm assumes
that the RRs are organized in several tree structures, one for each
zone, and another for the cache ...
... match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
...
...
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
...
...
Copy the NS RRs for the subzone into the authority
section of the reply. Put whatever addresses ...
... section of the reply. Put whatever addresses are
available into the additional section, using glue RRs
if the addresses are not available from authoritative
...
...
If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit.
If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer ... ... node
against QTYPE. If any match, copy them into the answer
section, but set the owner of the RR to be QNAME, and
not the node with the "*" label. Go to step 6.
...
... cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If there was no delegation from
...
...
Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
...
...
In the previous algorithm, special treatment was given to RRs with owner
names starting with the label "*". Such RRs ...
... are called wildcards.
Wildcard RRs can be thought of as instructions for synthesizing RRs.
When the appropriate conditions are met, the name server ...
... .
Wildcard RRs can be thought of as instructions for synthesizing RRs.
When the appropriate conditions are met, the name server creates ...
... When the appropriate conditions are met, the name server creates RRs
with an owner name equal to the query name and contents taken from the
...
...
The contents of the wildcard RRs follows the usual rules and formats for
RRs. The wildcards in the zone have an owner name that controls the
...
... The contents of the wildcard RRs follows the usual rules and formats for
RRs. The wildcards in the zone have an owner name that controls the
query names they will match. The owner name of the ...
... in the zone have an owner name that controls the
query names they will match. The owner name of the wildcard RRs is of
the form "*.<anydomain>", where <anydomain> is any domain name.
...
... query name is know to exist. For example, if a wildcard
RR has an owner name of "*.X", and the zone also contains RRs
attached to B.X, the wildcards ...
... wildcard
RR has an owner name of "*.X", and the zone also contains RRs
attached to B.X, the wildcards would apply to queries ...
... wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it. The result of such a query should not be cached.
...
... IP/TCP capable gateway machine was called
A.X.COM, the following RRs might be entered into the COM zone:
...
... query for any domain name ending in X.COM to
return an MX RR pointing at A.X.COM. Two wildcard RRs are required
...
... return an MX RR pointing at A.X.COM. Two wildcard RRs are required
since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
...
... at *.X.COM is inhibited in the A.X.COM
subtree by the explicit data for A.X.COM. Note also that the explicit
MX data at X.COM and A.X.COM is required, and that none of the RRs above
would match a query name of XX.COM.
...
... The method is that a name server may add an SOA RR to the additional
section of a response when that response is authoritative. The SOA must
be that of the zone which was the source of the authoritative data in
...
... results which are not directly stated in an authoritative response.
There are several reasons for this, including: cached information isn't
usually enough to match up RRs and their zone names, SOA RRs may be
cached due to direct SOA queries ...
... There are several reasons for this, including: cached information isn't
usually enough to match up RRs and their zone names, SOA RRs may be
cached due to direct SOA queries, and name servers are not required to
...
... version is expected to
become part of the standard protocol in the future. Name servers are
not required to add the SOA RRs in all authoritative responses, nor are
resolvers required to cache negative results. Both are recommended.
...
... cache negative results. Both are recommended.
All resolvers and recursive name servers are required to at least be
able to ignore the SOA RR when it is present in a response.
...
...
The periodic polling of the secondary servers is controlled by
parameters in the SOA RR for the zone, which set the minimum acceptable
polling intervals. The parameters are called REFRESH, RETRY, and
...
... If this check cannot be completed, new checks are started every RETRY
seconds. The check is a simple query to the primary for the SOA RR of
the zone. If the serial field in the secondary's zone copy is equal to
the serial returned by the primary, then no changes have occurred, and
...
... the data for the top authoritative node of the zone. Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs. The stream ...
... messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs. The stream of messages allows
the secondary to construct a copy of the zone. Because accuracy is
...
... IP addresses. Under the DNS, it
translates into a request for type A RRs. Since the DNS does
not preserve the order of RRs ...
... RRs. Since the DNS does
not preserve the order of RRs, this function may choose to
sort the returned addresses or select the "best" address ...
... IN-ADDR.ARPA". A
type PTR query is used to get the RR with the primary name of
the host. For example, a request for the host name ...
... host name
corresponding to IP address 1.2.3.4 looks for PTR RRs for
domain name "4.3.2.1.IN-ADDR.ARPA ...
... caller
supplies a QNAME, QTYPE, and QCLASS, and wants all of the
matching RRs. This function will often use the DNS format
for all RR ...
... RRs. This function will often use the DNS format
for all RR data instead of the local host's, and returns all
RR ...
... RR data instead of the local host's, and returns all
RR content (e.g., TTL) instead of a processed form with local
quoting conventions.
...
... One or more RRs giving the requested data. ...
... translation is an
alias when it finds the CNAME RR. If possible, the alias condition
should be signalled back from the resolver to the client ...
... the resolver should not pursue aliases when the CNAME RR matches the
query type. This allows queries which ask whether an ...
... is CNAME, the user is interested in the
CNAME RR itself, and not the RRs at the name it points to.
...
... A structure which stores the results from previous
responses. Since resolvers are responsible for
discarding old RRs whose TTL has expired, most
implementations convert the interval specified in
...
... TTL has expired, most
implementations convert the interval specified in
arriving RRs to some sort of absolute time when the RR
is stored in the cache ...
... implementations convert the interval specified in
arriving RRs to some sort of absolute time when the RR
is stored in the cache. Instead of counting the TTLs ...
... TTLs
down individually, the resolver just ignores or discards
old RRs when it runs across them in the course of a
search, or discards them during periodic sweeps to
...
... canonical name in the CNAME RR and go to step 1.
d. if the response shows a servers failure or other
...
... name server to ask for the required data. The
general strategy is to look for locally-available name server RRs,
starting at SNAME, then the parent domain name of SNAME, the
...
... root. Thus if SNAME were
Mockapetris.ISI.EDU, this step would look for NS RRs for
Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
...
... root).
These NS RRs list the names of hosts for a zone at or above SNAME. Copy
the names into SLIST. Set up their addresses ...
... If the search for NS RRs fails, then the resolver initializes SLIST from
the safety belt SBELT. The basic idea is that when the resolver has no
idea what servers to ask, it should use information from a configuration
file ...
... are. This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation. If not, the reply
is bogus and should be ignored. If the delegation ...
... delegation RRs and any address RRs for the servers should be cached.
The name servers are entered in the SLIST, and the search is restarted.
...
...
This data is represented as it would be in a master file. Most RRs are
single line entries; the sole exception here is the SOA RR, which uses
...
... This data is represented as it would be in a master file. Most RRs are
single line entries; the sole exception here is the SOA RR, which uses
"(" to start a multi-line RR ...
... RR, which uses
"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
Since the class ...
... "(" to start a multi-line RR and ")" to show the end of a multi-line RR.
Since the class of all RRs ...
... RR.
Since the class of all RRs in a zone must be the same, only the first RR
in a zone need specify the class ...
... Since the class of all RRs in a zone must be the same, only the first RR
in a zone need specify the class. When a name server ...
... loads a zone, it
forces the TTL of all authoritative RRs to be at least the MINIMUM field
of the SOA, here 86400 seconds, or one day. The NS RRs ...
... RRs to be at least the MINIMUM field
of the SOA, here 86400 seconds, or one day. The NS RRs marking
delegation of the MIL and EDU domains, together with the glue ...
... marking
delegation of the MIL and EDU domains, together with the glue RRs for
the servers host addresses ...
... RRs which list the name servers for the root. The
data in the SOA RR describes the management of the zone. The zone data
is maintained on host ...
...
The NS RRs for the MIL and EDU domains mark the boundary between the
root zone and the MIL and EDU zones. Note that in this example, the
...
... Note the use of relative names here. The owner name for the ISI.EDU. is
stated using a relative name, as are two of the name server RR contents.
Relative and absolute domain names may be freely intermixed in a master
...
... bit is set
indicating that the address RRs in the answer section are from
authoritative data. The question section of the response matches the
question section of the query ...
... TTL here is due to aging of the
data in a cache. The difference in ordering of the RRs in the answer
section is not significant.
...
...
This response contains the MX RR in the answer section of the response.
The additional section contains the address RRs ...
... RR in the answer section of the response.
The additional section contains the address RRs because the name server
at C.ISI.EDU guesses that the requester will need the addresses ...
... header. The interpretation of this response is
that the server is authoritative for the name, and the name exists, but
no RRs of type NS are present there.
...
... Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
server doesn't attempt to look up anything for C.ISI.EDU. (Except
...
...
Suppose the first request to the resolver comes from the local mailer,
which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
RRs for the domain name ISI.EDU.
...
...
The resolver would look in its cache for MX RRs at ISI.EDU, but the
empty cache wouldn't be helpful. The resolver would recognize that it
...
...
The resolver would translate this into a request for PTR RRs for
65.0.6.26.IN-ADDR.ARPA. This information is not in the cache ...
... The resolver would not find any cached data for this name, but would
find the NS RRs in the cache for ISI.EDU when it looks for foreign
servers to ask. Using this data, it would construct a SLIST of the
...