HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

6.5.3.8 The TRUSTED-KEYS Statement

The trusted-keys statement defines DNSSEC security roots. (DNSSEC is described in Section 6.2.6.)

A security root is defined when the public key for a nonauthoritative zone is known but cannot be securely obtained through DNS, either because it is the DNS root zone or because its parent zone is unsigned. Once a key has been configured as a trusted key, it is treated as if it had been validated and proven secure. The resolver attempts DNSSEC validation on all DNS data in subdomains of a security root.

The trusted-keys statement can contain multiple key entries. The trusted-keys statement has the following syntax:


trusted-keys {
    string number number number string ;
    [ string number number number string ; [...]]
};

Each statement contains the key's domain name, flags, protocol, algorithm, and base-64 representation of the key data.

The base-64 representation of the key data must be enclosed in quotation marks.

6.5.3.9 The VIEW Statement

The view statement allows a name server to answer a DNS query differently, depending on who is asking. It is particularly useful for implementing split DNS setups without having to run multiple servers.

The view statement has the following syntax:


view view_name [class] {
      match-clients { address_match_list } ;
      match-destinations { address_match_list } ;
      match-recursive-only yes_or_no ;
      [ view_option; ...]
      [ zone-statistics yes_or_no ; ]
      [ zone_statement; ...]
};

The parameters to the view statement are:

  • view-name, which specifies the name of this view.
  • class, which specifies the class for this view. If no class is given, class IN is assumed.

    Note

    All non-IN views must contain a hint zone. Only the IN class has compiled-in default hints.

Table 6-18 describes the clauses you can include in the view statement.

Table 6-18 View Statement Clauses
Clause Description
match-clients
match-destinations
Each view statement defines a view of the DNS name space that is seen by a subset of clients. A client matches a view if its source IP address matches the address match list of the view's match-clients clause and its destination IP address matches the address match list of the view's match-destinations clause. If they are not specified, both match-clients and match-destinations default to matching all addresses.
match-recursive-only Only recursive requests from matching clients match that view.
view-options Many of the options given in the options statement can also be used in a view statement, and then apply only when resolving queries with that view. When no view statement value is given, the value in the options statement is used as the default.
zone-statistics Specifies whether or not to generate the zone statistics file. See Section 6.5.3.6.14 for more information.
zone-statement Specifies the zone information for this view. See Section 6.5.3.10 for more information.

The order of the view statements is significant. A client request is resolved in the context of the first view that it matches. Zones defined within a view statement are accessible only to clients that match the view.

By defining a zone of the same name in multiple views, different zone data can be given to different clients; for example, internal and external clients in a split DNS setup. Also, zone statement options can have default values specified in the view statement; these view-specific defaults take precedence over those in the options statement.

If there are no view statements in the configuration file, a default view that matches any client is automatically created in class IN, and any zone statements specified on the top level of the configuration file are considered to be part of this default view.

Note

If any explicit view statements are present, all zone statements must occur inside view statements.

The following example shows a typical split DNS setup implemented using view statements:


view "internal" {
               // This should match our internal networks.
      match-clients { 10.0.0.0/8; };
               // Provide recursive service to internal clients only.
      recursion yes;
               // Provide a complete view of the example.com zone
               // including addresses of internal hosts.
      zone "example.com" {
            type master;
            file "example-internal.db";
      };
};
view "external" {
      match-clients { any; };
               // Refuse recursive service to external clients.
      recursion no;
               // Provide a restricted view of the example.com zone
               // containing only publicly accessible hosts.
      zone "example.com" {
            type master;
            file "example-external.db";
      };
};

6.5.3.10 The ZONE Statement

The zone statement specifies options for a specific zone. Note that if view statements are included in the configuration file, the zone statements must be included in view statements.

The zone statement has the following syntax:


zone zone_name [class] [{
    type ( master | slave | hint | stub | forward ) ;
    [ allow-notify { address_match_list } ; ]
    [ allow-query { address_match_list } ; ]
    [ allow-transfer { address_match_list } ; ]
    [ allow-update { address_match_list } ; ]
    [ update-policy { update_policy_rule [...] } ; ]
    [ allow-update-forwarding { address_match_list } ; ]
    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ;  ... ] }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ dialup dialup_option ; ]
    [ file string ; ]
    [ forward (only|first) ; ]
    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ;  ... ] }; ]
    [ ixfr-base string ; ]
    [ ixfr-tmp-file string ; ]
    [ maintain-ixfr-base yes_or_no ; ]
    [ masters [port ip_port] { ip_addr [port ip_port] [key key]; [...] }  ; ]
    [ max-ixfr-log-size number ; ]
    [ max-transfer-idle-in number ; ]
    [ max-transfer-idle-out number ; ]
    [ max-transfer-time-in number ; ]
    [ max-transfer-time-out number ; ]
    [ notify yes_or_no | explicit ; ]
    [ pubkey number number number string ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
    [ notify-source (ip4_addr | *) [port ip_port] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
    [ zone-statistics yes_or_no ; ]
    [ sig-validity-interval number ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
}];

6.5.3.10.1 Type of Zone

Table 6-19 describes the types of zones that you can specify in the type clause.

Table 6-19 Zone Types
Type Description
master The server that has a master copy of the data for the zone and that can provide authoritative answers for it.
slave A replica of a master zone. The masters option specifies the IP addresses of one or more master servers that this slave can contact to update its copy of the zone information.
stub Similar to a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone. Stub zones are not a standard part of the DNS; they are a feature specific to the BIND implementation.

Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in TCPIP$BIND.CONF. This usage is not recommended for new configurations, and BIND Version 9 supports it only in a limited way. In BIND Version 4 and BIND Version 8, zone transfers of a parent zone included the NS records from stub children of that zone. This made it possible to configure child stubs only in the master server for the parent zone. BIND Version 9 never mixes together zone data from different zones in this way. Therefore, if a BIND Version 9 master serving a parent zone has child stub zones, all the slave servers for the parent zone also need to have the same child stub zones.

Stub zones can also be used as a way of forcing the resolution of a given domain to use a particular set of authoritative servers. For example, the caching name servers on a private network using RFC 2157 addressing can be configured with stub zones for 10.in-addr.arpa to use a set of internal name servers as the authoritative servers for that domain.

forward A forward zone allows you to configure forwarding on a per-domain basis. A zone statement of type forward can contain forward and forwarders statements, which applies to queries within the domain specified by the zone name. If no forwarders statement is present or if an empty list for forwarders is specified, then forwarding is not done for the domain, thereby canceling the effects of any forwarders in the options statement.

If you want to use this type of zone to change the behavior of the global forward option (using the first value to specify the zone to which to forward first, or the only value to specify forwarding to this zone only), and you want to use the same servers that are set globally, you need to respecify the global forwarders.

hint The initial set of root name servers is specified using a hint zone. When the server starts up, it uses the root hints to find a root name server and to get the most recent list of root name servers. If no hint zone is specified for class IN, the server uses a default set of root servers hints. Classes other than IN have no built-in defaults hints.

6.5.3.10.2 The Zone Class

The zone name can optionally be followed by a class. If the class is not specified, class IN (for Internet) is assumed. This is correct for the vast majority of cases.

The hesiod class is named for an information service from MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers, and so on. The keyword HS is a synonym for hesiod .

Another MIT development is CHAOSnet , a LAN protocol created in the mid-1970s. Zone data for CHAOSnet can be specified with the CH class.

6.5.3.10.3 Zone Options

Table 6-20 describes the options you can include in the zone statement.

Table 6-20 Zone Options
Option Description
allow-notify See the description of allow-notify in Section 6.5.3.6.3.
allow-query See the description of allow-query in Section 6.5.3.6.3.
allow-transfer See the description of allow-transfer in Section 6.5.3.6.3.
allow-update Specifies which hosts are allowed to submit dynamic DNS updates for master zones. The default is to deny updates from all hosts.
update-policy Specifies an update policy, as described in Section 6.5.7.2.
allow-update-forwarding Specifies which hosts are allowed to submit dynamic updates to slave zones to be forwarded to the master. The default is NONE, which means that update forwarding is not performed. To enable update forwarding, specify ANY. Do not specify any other value; the responsibility for update access control should rest with the master server, not with the slaves.

Enabling the update forwarding feature on a slave server can expose master servers relying on insecure IP-address based access control to attacks; see Section 6.2.2 for more details.

also-notify Meaningful only if notify is active for this zone. The set of machines that receives a NOTIFY message for this zone is made up of all the listed name servers (other than the primary master) for the zone, plus any IP addresses specified with the also-notify statement. A port can be specified with each also-notify address to send the notify messages to a port other than the default of 53. also-notify is not meaningful for stub zones. The default is the empty list.
check-names This option was used in BIND 8 to restrict the character set of domain names in master files and of DNS responses received from the network. BIND 9 does not restrict the character set of domain names and does not implement the check-names option.
database Specifies the type of database to be used for storing the zone data. The string following the database keyword is interpreted as a list of space-delimited words. The first word identifies the database type; any subsequent words are passed as arguments to the database to be interpreted in a way specific to the database type.

The default is rbt , the native database used by BIND 9. This database does not take arguments.

dialup See the description of the dialup option in Section 6.5.3.6.1.
forward Meaningful only if the zone has a forwarders list. The only keyword causes the lookup to fail after trying the forwarders and getting no answer. The first keyword allows attempts at normal lookups.
forwarders Overrides the list of global forwarders.

If the zone type is not forward , forwarding is not done for the zone, and the global options are not used.

ixfr-base This option was used in BIND 8 to specify the name of the transaction log (journal) file for dynamic update and IXFR. BIND 9 ignores this option and constructs the name of the journal file by appending _JNL to the name of the zone file.
ixfr-tmp-file An undocumented option in BIND 8. Ignored in BIND 9.
masters Specifies one or more IP addresses of master servers that the slave contacts to update its copy of the zone.

By default, transfers are made from port 53 on the servers; this can be changed for all servers by specifying a port number before the list of IP addresses, or on a per-server basis after the IP address. Authentication to the master can also be done with per-server TSIG keys. If a file is specified, then the replica is written to this file whenever the zone is changed and is reloaded from this file on a server restart. Use of a file is recommended because it often speeds server startup and eliminates a waste of bandwidth.

max-transfer-time-in See the description of max-transfer-time-in in Section 6.5.3.6.6.
max-transfer-idle-in See the description of max-transfer-idle-in in Section 6.5.3.6.6.
max-transfer-time-out See the description of max-transfer-time-out in Section 6.5.3.6.6.
max-transfer-idle-out See the description of max-transfer-idle-out in Section 6.5.3.6.6.
notify See the description of notify in Section 6.5.3.6.
pubkey In BIND Version 8, this option was used for specifying a public zone key for verification of signatures in DNSSEC-signed zones when they are loaded from disk. BIND Version 9 does not verify signatures on loading and ignores the option.
zone-statistics If YES, the server keeps statistical information for this zone, which can be dumped to the statistics file defined in the server options. See Section 6.5.3.6.
sig-validity-interval See the description of sig-validity-interval in Section 6.5.3.6.13.
transfer-source See the description of transfer-source in Section 6.5.3.6.6.
transfer-source-v6 See the description of transfer-source-v6 in Section 6.5.3.6.6.
notify-source See the description of notify-source in Section 6.5.3.6.6.
notify-source-v6 See the description of notify-source-v6 in Section 6.5.3.6.6.
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
See the descriptions of these options in Section 6.5.3.6.13.

6.5.4 IPv6 Support in BIND Version 9

BIND supports all forms of IPv6 name-to-address and address-to-name lookups. It also uses IPv6 addresses to make queries when running on an IPv6-capable system. For information about configuring the BIND server for IPv6, see the HP TCP/IP Services for OpenVMS Guide to IPv6.

The use of AAAA records is recommended because A6 records have been moved to experimental status. Like most stub resolvers, the resolver in TCP/IP Services supports only AAAA lookups because of the difficulty of following A6 chains.

For IPv6 lookups, use of the nibble format that is used in the ip6.arpa reverse mapping zone is recommended because the bitstring format used in the ip6.arpa reverse mapping zone has been moved to experimental status. Also, the ip6.int reverse mapping zone (defined in RFC 1886) has been deprecated. For more information about A6 and the bitstring format, refer to RFC 2874.


Previous Next Contents Index