HP-UX Reference (11i v2 03/08) - 4 File Formats (vol 8)

n
named.conf(4) named.conf(4)
NS a fully qualified domain name.
PTR a fully qualified domain name.
SOA several fields.
The owner name is often implicit, rather than forming an integral part of the RR. For example, many
nameservers internally form tree or hash structures for the name space, and chain RRs off nodes. The
remaining RR parts are the fixed header (type, 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 zones; it is also timed out, but by the refreshing policies for the zone.
The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can
be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance sug-
gest that these times should be on the order of days for the typical host. If a change can be anticipated,
the TTL can be reduced prior to the change to minimize inconsistency during the change, and then
increased back to its former value following the change.
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names.
The domain names are frequently used as "pointers" to other data in the DNS.
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 nameserver or resolver. In the examples provided in RFC 1034, a
style similar to that used in master files was employed in order to show the contents of RRs. In this for-
mat, 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. 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
defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type
and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class
and TTL values are often omitted from examples in the interests of clarity.
The resource data or RDATA section of the RR are given using knowledge of the typical representation for
the data.
For example, RRs carried in a message can be shown as:
ISI.EDU.MX10 VENERA.ISI.EDU.
MX10 VAXA.ISI.EDU
VENERA.ISI.EDUA128.9.0.32
A10.1.0.52
VAXA.ISI.EDUA10.2.0.27
A128.9.0.33
The MX RRs have an RDATA section which consists of a 16 bit number followed by a domain name. The
address RRs use a standard IP address format to contain a 32 bit internet address.
This example shows six RRs, with two RRs at each of three domain names. Similarly RRs may also be
shown as:
XX.LCS.MIT.EDU. INA10.0.0.44
CHAMIT.EDU. 2420
This example shows two addresses for XX.LCS.MIT.EDU, each of a different class.
MX Records
As described above, domain servers store information as a series of resource records, each of which con-
tains a particular piece of information about a given domain name (which is usually, but not always, a
host). The simplest way to think of a RR is as a typed pair of datum, a domain name matched with
relevant data, and stored with some additional type information to help systems determine when the RR
is relevant.
MX records are used to control delivery of e-mail. The data specified in the record is a priority and a
domain name. The priority controls the order in which email delivery is attempted, with the lowest
number first. If two priorities are the same, a server is chosen randomly. If no servers at a given priority
are responding, the mail transport agent will fall back to the next largest priority. Priority numbers do
not have any absolute meaning - they are relevant only respective to other MX records for that domain
HP-UX 11i Version 2: August 2003 − 24 − Hewlett-Packard Company Section 4−−199