named.conf.4 (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

named.conf(4) named.conf(4)

(BIND 9.3)

characters. The available base values are d

(decimal), o (octal), x (lowercase hexade-

cimal), and

X (uppercase hexadecimal). The default modiﬁer is

${0,0,d}.

To get a

$ in the output, escape the

$ with a backslash (\); for example, \$. For compa-

tibility with earlier versions,

$$ is still recognized as indicating a literal

$ in the output.

ttl The TTL for the generated records. If it is omitted, the normal TTL inheritance rules

apply. See the Time to Live (TTL) and Time Speciﬁcation sections for more detail.

class The class of the generated records. This must match the zone class , if it is speciﬁed.

type At present, the only supported types are

A, AAAA, CNAME, DNAME, NS, and PTR.

rhs An expression that evaluates to the rrdata for each resource record that is created. At

present, this must be a domain name. It uses the same

$ processing as lhs.

Example

$GENERATE easily generates the sets of records required to support the sub

/24 reverse delegations

described in RFC 2317, "Classless IN-ADDR.ARPA delegation".

$ORIGIN 0.0.192.IN-ADDR.ARPA.

$GENERATE 1-2 0 NS SERVER$.EXAMPLE.

$GENERATE 1-127 $ CNAME $.0

is equivalent to:

0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.

0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.

1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.

2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.

...

127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.

Resource Records (RRs)

This section, based on RFC 1034, describes the concept of a resource record, known as an RR, and when

an RR is used. Since the publication of RFC 1034, several new RRs have been identiﬁed and imple-

mented in the DNS. These are also included.

A domain name identiﬁes a node. Each node has a set of resource information, which may be empty. The

set of resource information associated with a particular name is composed of separate RRs. The order of

RRs in a set is not signiﬁcant and need not be preserved by name servers, resolvers, or other parts of the

DNS. However, the sorting of multiple RRs is permitted for optimization purposes, for example, to

specify that a particular nearby server be tried ﬁrst.

Domain servers store information as a series of resource records, each of which contains 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 data, a domain name matched with relevant data, and stored

with some additional type information to help systems determine when the RR is relevant.

Note: 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 or resolver. The binary for-

mat is deﬁned in the RFCs that are listed with the RR type keywords in the following Syntax

section. 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 structures for the name space, and

chain RRs off nodes.

Syntax

owner_name [ ttl ][class ] type rrdata

(ttl and class may be entered in either order. The

IN class and ttl values are often omitted from

examples in the interests of clarity.)

owner_name

The domain name of the owner of the information in the RR. This can be one of:

. (period)

The domain name of the DNS root name server.

@ The current origin.

32 Hewlett-Packard Company − 32 − HP-UX 11i Version 3: September 2010