.IL. IN MX 0 RELAY.CS.NET.
Only use $ORIGIN to change domains within a particular zone. For example, you might change domains to a subdomain within the current zone. For example:
$ORIGIN mynet.COM [assorted domain data...] $ORIGIN sub.mynet.COM [more domain data...]
$INCLUDE /usr/named/data/mailboxesThe line is interpreted as a request to load the file /usr/named/data/mailboxes.
Additionally, you may append a temporary $ORIGIN to use while the file is read. For example:
$INCLUDE /usr/named/data/mail-exchangers $ORIGIN mynet.COMThe inclusion of the new origin will not cause data to branch into another zone. Only the boot file can introduce or redefine zone boundaries.
;{name} {ttl} addr-class A address
volga IN A 172.16.118.1
IN A 172.16.246.1
;{name} {ttl} addr-class NS Name servers name
@ IN NS volga.mynet.COM.
The ``@'' character specifies the current origin.
The address class is IN (Internet addresses),
and the record type is name server (NS).
The record uses the default time-to-live (ttl) value.
Here, the record-specific data is the identity of the name server.
Here is an example of an SOA record:
;name {ttl} addr-class SOA Origin Person in charge
@ IN SOA volga.mynet.COM. dave.mynet.COM (
1993041403 ; Serial number
3600 ; Refresh time
300 ; Retry time
3600000 ; Expiry time
259200 ) ; Minimum time-to-live
The minimum time-to-live assigned to records and to the zone is
very important. A high value leads to low network traffic and fast
response time, while lower values generate additional traffic but allow
faster propagation of changes.
A general guideline is to set the minimum time-to-live
to three days (259200 seconds).
If your zone is very stable, consider setting the value even higher.
If you need to propagate changes more quickly, reduce the minimum time-to-live value several days before making the changes, then restore its previous value after making the changes.
Only changes and deletions are affected by the minimum time-to-live; additions are governed by the refresh time.
Here is an example AFSDB record:
name {ttl} addr-class AFSDB subtype mail exchanger
mynet.COM. IN AFSDB 1 missouri.mynet.COM.
mynet.COM. IN AFSDB 1 yukon.mynet.COM.
mynet.COM. IN AFSDB 2 nile.mynet.COM.
In the example above, missouri.mynet.COM and
yukon.mynet.COM are declared to be AFS database
servers for the mynet.COM AFS cell, so that AFS clients
wishing service from nile.COM
are directed to those two hosts
for further information. The third record declares that
nile.mynet.COM houses a directory server for the
root of the DCE cell mynet.COM, so that DCE
clients that wish to refer to DCE services should consult with
the host nile.mynet.COM for further information. The
DCE subtype of record is usually accompanied by
a TXT record for other information specifying other
details to be used in accessing the
DCE cell. RFC 1183 contains more detailed
information on the use of this record type.
The AFSDB record is still experimental; not all name servers implement or recognize it.
This resource record is especially useful when changing machine names. In this instance, create a CNAME record with the old name until users are accustomed to using the new name.
Here is an example of a CNAME record:
;aliases {ttl} addr-class CNAME Canonical name
volga-cities IN CNAME volga
;{name} {ttl} addr-class HINFO Hardware OS
ANY HINFO Intel i486 UNIX
;name {ttl} addr-class MB Machine
carol IN MB yukon.mynet.COM.
;{mail group name} {ttl} addr-class MG member name
IN MG Bloom
An example for setting up a mailing list is as follows:
Bind IN MINFO Bind-Request dave.mynet.COM.
IN MG mark.mynet.COM.
IN MG vicki.mynet.COM.
IN MG naomi.mynet.COM.
IN MG carol.mynet.COM.
IN MG denis.mynet.COM.
;name {ttl} addr-class MINFO requests maintainer
Bind IN MINFO BIND-REQUEST dave.mynet.COM
;name {ttl} addr-class MR corresponding MB
Postmaster IN MR carol
In the following example, Seismo.CSS.GOV is a mail gateway that knows how to deliver mail to Munnari.OZ.AU. These two machines may have a private connection or use a different transport medium. The preference value is the order that a mailer should follow when there is more than one way to deliver mail to a single machine. Lower numbers indicate higher precedence, and mailers are supposed to randomize same-valued MX hosts so as to distribute the load evenly if the costs are equal. See RFC 974 for more detailed information.
Here is an example MX record:
;name {ttl} addr-class MX preference value mailer exchanger
Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV.
.IL. IN MX 0 RELAY.CS.NET.
In the second example, all mail to hosts in
the domain IL is routed through RELAY.CS.NET.
This is done by creating a wildcard resource record,
which states that .IL has an MX
of RELAY.CS.NET.
Wildcards are often not an optimal solution, because MX records must appear the same both inside and outside a given domain. Therefore, if you want to use mail exchangers within your domain, do not use a top-level wildcard. Instead, create specific MX records for each of the machines in your domain.
The following example of a PTR record is used in setting up reverse pointers for the localhost in the 0.0.127.IN-ADDR.ARPA domain:
;name {ttl} addr-class PTR real_name
1.0.0.127.in-addr.arpa. IN PTR localhost.
Note the trailing ''.''s which prevent the appending of the current
$ORIGIN.
This entry can be shortened by letting the current origin be appended:
;name {ttl} addr-class PTR real_name
1 IN PTR localhost.
The following example is for the 16.172.IN-ADDR.ARPA
domain:
;name {ttl} addr-class PTR real_name
3.118 IN PTR thames.mynet.COM.
In this record, the name field is the network
number of the host in reverse order. You only need to specify enough
octets to make the name unique within a zone.
For example, if all hosts in a zone are on network
172.16.118, then only the last octet needs to be specified.
If hosts can be on either the 172.16.118 or 172.16.246 networks
within a zone, then the last two octets need to be specified.
The following PX record maps X.400 to RFC 822 (``table 1 rules'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.ADMD-garr.X42D.it IN PX 50 it. ADMD-garr.C-it
The following PX record maps RFC 822 to X.400
(``table 2 rules'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.nfn.it IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it
The following PX record encodes RFC 822 as X.400
(``gate table'' in RFC 1327):
;name {ttl} addr-class PX prefer 822-dom X.400-dom
.it IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it
It is recommended to use ``name'' values that contain wildcards
to maintain compatibility with existing
services that use static RFC 1327 tables.
The preference field (``prefer'') works in a similar way to
that in MX records; a value of 50 is recommended.
``822-dom'' provides the mapping rule for RFC 822.
``X.400-dom'' provides the mapping rule for X.400 in
DNS format.
To specify mapping rules from X.400 to RFC 822 syntax, an appropriate X.400 domain tree must be created in DNS including specific SOA and NS records for the domain itself. The mapping rules from RFC 822 to X.400 can be embedded directly into the ``name'' tree. See RFC 1664 for details of the organization of this structure and of how to use PX records. Take care in coordinating DNS mapping information with the same information specified in RFC 1327 tables.
The PX record is still experimental; not all name servers implement or recognize it.
;owner {ttl} addr-class RP mbox-domain-name TXT-domain-name
dave IN RP dave.mynet.COM sysadmins.mynet.COM
The mbox-domain-name field contains the mailbox address for the
responsible person. The address is specified following the standard
DNS convention, with the mailbox name prepended to the domain name. A
period (.) indicates that no mailbox is available.
The TXT-domain-name field indicates a domain in which TXT records exist. Subsequent searches can retrieve the records from the TXT domain. In the example, sysadmins.mynet.COM is the name of a TXT record that might contain the names and phone numbers of system administrators.
The RP record is class-insensitive, and multiple records for a single name may appear in the database. If multiple records exist, they should have identical time-to-live values.
Not all name servers implement or recognize the RP record at this time.
;name {ttl} addr-class TXT string
yukon.mynet.COM IN TXT "free-form text"
This functionality is not widely used on the Internet.
Because the WKS record is not widely used throughout the Internet, applications should not rely on the existence of this record to determine the presence or absence of a service. Instead, the application should simply attempt to use the service.
Here is an example of a WKS record:
;{name} {ttl} addr-class WKS address protocol list of services
IN WKS 172.16.118.1 UDP echo tftp time
IN WKS 172.16.118.1 TCP (telnet discard
sunrpc sftp
uucp-path systat
netstat qotd nntp
link chargen ftp
auth whois mtp
pop rje finger smtp
supdup hostnames
domain
name server)
addr-class is either IN (Internet) or HS (Hesiod). net_address[:netmask] allows queries from the specified network address. The default network mask for the address will be used if netmask is omitted. host_address:H allows queries from a specified host IP address.
Multiple secure_zone TXT records may be specified for a zone.
In this example, the zone will only answer Internet requests from the local loopback interface 127.0.0.1, from the class B network 148.151.0.0, from the class C subnetted class B network 148.152.7.0, and from host 148.152.1.1:
secure_zone IN TXT 127.0.0.1:H secure_zone IN TXT 148.151.0.0 secure_zone IN TXT 148.152.7.0:255.255.255.0 secure_zone IN TXT 148.152.1.1:HThe loopback interface is included so that a local client can resolve names.
Secure zones can be used to restrict access to Hesiod password maps, or to separate internal and external internet address resolution on a firewall machine without the need to run a separate named process for internal and external address resolution.
Standard Resource Record Format in RFC 1035