DNS BIND Query Statements

This chapter describes all the statements available in BIND 9.3.x relating to or controlling queries. Full list of statements.

additional-from-auth, additional-from-cache

  additional-from-auth yes | no ;
  additional-from-cache yes | no ;

additional-from-auth and additional-from-cache control the behaviour when zones have additional (out-of-zone) data or when following CNAME or DNAME records. These options are for used for configuring authoritative-only (non-caching) servers and are only effective if recursion no is specified in a global options clause or in a view clause. The default in both cases is yes. These statements may be used in a global options or in a view clause. The behaviour is defined by the table below:

auth cache BIND Behaviour
yes yes BIND will follow out of zone records e.g. it will follow the MX record specifying mail.example.net for zone example.com for which it is authoritative (master or slave). Default behaviour.
no no Cache disabled. BIND will NOT follow out-of-zone records even if it is in the cache e.g. it will NOT follow the MX record specifying mail.example.net for zone example.com for which it is authoritative (master or slave). It will return REFUSED for the out-of-zone record.
yes no Cache disabled. BIND will follow out-of-zone records but since this requires the cache (which is disabled) the net result is the same - BIND will return REFUSED for the out-of-zone record.
no yes BIND will NOT follow out-of-zone records but if it is the cache it will be returned. If not in the cache BIND will return REFUSED for the out-of-zone record.

allow-query

  allow-query { address_match_list };

allow-query defines a match list e.g. IP address(es) which are allowed to issue queries to the server. If not specified all hosts are allowed to make queries. This statement may be used in a zone, view or a global options clause.

allow-recursion

 allow-recursion { address_match_list };

allow-recursion defines a match list e.g. IP address(es) which are allowed to issue recursive queries to the server. If the answer to the query already exists in the cache it will be returned irrespective of this statement. If not specified all hosts are allowed to make recursive queries. This statement may be used in a view or a global options clause.

auth-nxdomain

 [auth-nxdomain yes | no;]

If auth-nxdomain is 'yes' allows the server to answer authoritatively (the AA bit is set) on returning NXDOMAIN (domain does not exist) answers, if 'no' (the default) the server will not answer authoritatively. NOTE: This changes the previous BIND 8 default setting. This statement may be used in a view or a global options clause.

blackhole

 blackhole { address_match_list };

blackhole defines a address_match_list of hosts that the server will not respond to, or answer queries for. The default is 'none' (all hosts are responded to). This statement may only be used in a global options clause.

delegation-only

 delegation-only yes | no ;
 delegation no;

delegation-only applies to hint and stub zones only and defines whether the zone will also only respond with delegations (or referrals). See type for more information. The default is no. This statement may only be used in a global zone clause.

forward

 forward ( only | first );

forward is only relevant in conjunction with a valid forwarders option. If set to 'only' the server will only forward queries, if set to 'first' (default) it will send the queries to the forwarder and if not answered will attempt to find an answer. This statement may be used in a zone, view or a global options clause.

forwarders

 forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] };
 forwarders { 10.2.3.4; 192.168.2.5; };

forwarders defines a list of IP address(es) (and optional port numbers) to which queries will be forwarded. Only relevant when used with the related forward statement. This statement may be used in a zone, view or a global options clause.

minimal-responses

 minimal-responses yes | no ;
 minimal-responses yes ;

If yes the server will only add records to the authority and additional data sections when they are required e.g. delegations, negative responses. This may improve the performance of the server. The BIND default is no. This statement may be used in a view or a global options clause.

query-source[-v6]

 query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ];
 query-source address 192.168.2.3 ;
 query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ];
 query-source-v6 address  * port 1188;

Defines the IP address (IPv4 or IPv6) and optional port to be used as the source for outgoing queries from the server. The BIND default is any server interface IP address and a random unprivileged port. The optional port is only used to control UDP operations. avoid-v4-udp-ports and avoid-v6-udp-ports can be used to prevent selection of certain ports. This statement may be used in a view or a global options clause.

recursion

 recursion yes | no;

If recursion is set to 'yes' (the default) the server will always provide recursive query behaviour if requested by the client (resolver). If set to 'no' the server will only provide iterative query behaviour. If the answer to the query already exists in the cache it will be returned irrespective of the value of this statement. This statement essentially controls caching behaviour in the server. The allow-recursion statement and the view clauses provide fine-grained control. This statement may be used in a view or a global options clause.

recursive-clients

 recursive-clients number;
 recursive-clients 25;

Defines the number of simultaneous recursive lookups the server will perform on behalf of its clients. BIND 9 default is 1000 i.e. it will support 1000 simultaneous recursive lookup requests - should be enough! This statement may only be used in a global options clause.

root-delegation-only

 root-delegation-only [ exclude { "domain_name"; ... } ];
 root-delegation-only exclude { "com"; "net" };

If present indicates that all responses will be referrals or delegations. The optional exclude list consist of one or more domain_name (a quoted string) parameters. This statement is intended to be used for root domains (the gTLDs and ccTLDs) but the delegation-only statement may be to create the same effect for specific zones. This statement may be used in a view or a global options clause.

rrset-order

 rrset-order { order_spec ; [ order_spec ; ... ]

rrset-order defines the order in which multiple records of the same type are returned. This works for any record type in which the records are similar. RRSET-ORDER IS FULLY IMPLEMENTED IN BIND > 9.2.3. The default is defined to be a random-cyclic order (the starting address is randomly chosen and thereafter round-robin order). Note: Experimentation showed the default to be pure cyclic.

The full specification of rrset-order is shown below. An 'order_spec' is defined as:

 class class_name ][ type type_name ][ name "domain_name"] order ordering;

Where 'class_name' is the record class, for example, IN (default is 'any'), type is the Resource Record type (if none specified defaults to 'any'), domain_name limits the statement to a specific domain suffix and defaults to root (all domains), order is a key word and ordering may take one of the following values:

  • fixed - records are returned in the order they are defined in the zone file
  • random - records are returned in a random order
  • cyclic - records are returned in a round-robin fashion

Examples

Defines that all equal records for all domains will be returned in random order.

rrset-order {order random;};

Defines that all equal MX records for example.com will be returned in random order all others in cyclic order.

rrset-order {type MX name "example.com" order random; order cyclic};

This statement may be used in a view or a global options clause.

sortlist

 sortlist { address_match_list; ... };
 sortlist { {10.2/16; };};

The sortlist statement is used to order RRsets (groups of equal RRs) for use by a resolver (a client). It is the client side of the rrset-order statement and can work against the rrset-order statement when being used as part of a load-balancing configuration in that rrset-order carefully delivers equal RRs in its order of preference to a remote server that may then proceed to re-order them with a sortlist statement. The sortlist statement attempts to order returned records based on the IP address of the client that initiated the request. This statement may only be used in a global options or a view clause.

The address_match_list is used very differently from its use in all other statements and assumes that each element of the address_match_list is itself an address_match_list, it becomes a nested address_match_list and is enclosed in braces (curly brackets). Processing depends on whether there is one or more than one element in the nested address_match_list. In the simple case of one element as in the above example if the client's IP address matches 10.2/16 i.e. lies in range 10.2.0.0 to 10.2.255.255) and there are any IP addresses in the response in the same range they will be the first records supplied in the response. Any remaining records will be sorted according to the rrset-order (default is cyclic). If no match is found the records are returned in the order defined by the rrset-order or its default value (cyclic). If two elements are provided in the address match list then the second element is assumed to be an ordered list of preferences. This is best illustrated by an example. Assume the zone example.com has a zone file with multiple A RRs for lots.example.com:

// zone file example.com
$ORIGIN example.com.
lots     IN  A  192.168.3.6
         IN  A  192.168.4.5
         IN  A  192.168.5.5
         IN  A  10.2.4.5
         IN  A  172.17.4.5

The client side server has a sortlist statement as shown below:

options {
    ....
    sortlist {
    {// 1st preference block start
     192.168.4/24;  // 1st client IP selection matches any of these
     {10.2/16;   // return any of these response IPs as 1st preference
      172.17.4/24;  // 2nd preference
     };
    }; // end first block
    { // second preference block
     192.168.5/24;  // 1st client IP selection matches any of these
     {192.168.4/24;   // return any of these response IPs as 1st preference
      172.17.4/24;  // 2nd preference
      10.2/16;  // 3rd preference
     };
    }; // end second block
   }; // end sortlist
};

If the client, say a resolver, with an IP address of 192.168.5.33 issues an A query for lots.example.com then the RRs will be returned in the following order:

192.168.4.5
10.2.4.5
192.168.3.6
192.168.5.5
172.17.4.5

The top level of the address_match_list is searched against the client IP (192.168.5.33) address and matches the "2nd client IP selection", the nested address_match_list is then treated as an ordered list for the A query result IPs (not the client IPs). The "1st preference" matches so 192.168.4.5 becomes first in returned list, the "2nd preference" does not match the returned IPs, the "3rd preference" matches so 10.2.4.5 becomes second in the returned list and the remaining 3 RRs do not match so are returned according to the rrset-order statement or its default (cyclic) if not defined. The sortlist statement may be used in a view or a global options clause.


Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 dns records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfc's
change log