HP-UX Reference (11i v3 07/02) - 4 File Formats (vol 8)
n
named.conf(4) named.conf(4)
(BIND 9.3)
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 Inter-
net performance suggest 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 following three types of TTL are currently used in a zone file.
SOA The minimum field in an
SOA RR is the negative-caching TTL. This controls how long
other servers will cache
no-such-domain
(NXDOMAIN) responses from you. The max-
imum time for negative caching is 3 hours (
3h).
Note: This use of the minimum field was implemented in RFC 2308, largely superseding
the usage specified in RFC 1034 (but see the default calculation for the ttl field below).
$TTL A $TTL directive at the top of the zone file (before the
SOA) provides a default TTL for sub-
sequent RRs.
Note: The
$TTL directive, defined in RFC 2308, supersedes the original use of the
SOA
minimum field specified in RFC 1034.
ttl The ttl field in an RR specifies the TTL for the record. If it is omitted, the value specified
by the previous $TTL directive is used. If there is no previous $TTL directive, the
minimum field in the SOA resource record is used.
Time Specification
All the TTLs and and the SOA time fields are specified in seconds, as a 32-bit integer value in the range 0 to
2147483647(2ˆ31-1).
Here’s a table of convenient values:
Seconds in an Integer Value
minimum 0 seconds
1 minute 60 seconds
1 hour 3600 seconds
1 day 86400 seconds
7 days 604800 seconds
30 days 2592000 seconds
24855 days 2147472000seconds
maximum 2147483647seconds
For convenience, some units can be explicitly specified; you can use h for hours,
m for minutes, and s for
seconds. For example,
1h30m.
Inverse Mapping in IPv4
Reverse name resolution (that is, translation from an IP address to a domain name) is achieved with the
in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-
most significant order, reading left to right. This is the reverse of the way IP addresses are usually writ-
ten. Thus, a machine with an IP address of 10.1.2.3 would have a corresponding
in-addr.arpa name of
3.2.1.10.in-addr.arpa. This name should have a PTR resource record whose data field is the
domain name of the machine. If the machine has more than one name. it will need multiple
PTR records.
For example, for IP address 10.1.2.3, corresponding to host name fred.example.com
in the
example.com domain:
$ORIGIN 2.1.10.in-addr.arpa
3 IN PTR fred.example.com.
Example
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
The MX RRs have an rrdata section that 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.
HP-UX 11i Version 3: February 2007 − 35 − Hewlett-Packard Company 267