Useful Articles by UpCloud

BIND - NAME SERVER

https://www.isc.org/downloads/bind/

Sample Configurations

A Caching-only Name Server

The following sample configuration is appropriate for a caching-only name server for use by clients internal to a corporation. All queries from outside clients are refused using the allow-query option. Alternatively, the same effect could be achieved using suitable firewall rules.

// Two corporate subnets we wish to allow queries from.
acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
options {
     // Working directory
     directory "/etc/namedb";

     allow-query { corpnets; };
};
// Provide a reverse mapping for the loopback
// address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
     type master;
     file "localhost.rev";
     notify no;
};

An Authoritative-only Name Server

This sample configuration is for an authoritative-only server that is the master server for "example.com" and a slave for the subdomain "eng.example.com".

options {
     // Working directory
     directory "/etc/namedb";
     // Do not allow access to cache
     allow-query-cache { none; };
     // This is the default
     allow-query { any; };
     // Do not provide recursive service
     recursion no;
};

// Provide a reverse mapping for the loopback
// address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
     type master;
     file "localhost.rev";
     notify no;
};
// We are the master server for example.com
zone "example.com" {
     type master;
     file "example.com.db";
     // IP addresses of slave servers allowed to
     // transfer example.com
     allow-transfer {
          192.168.4.14;
          192.168.5.53;
     };
};
// We are a slave server for eng.example.com
zone "eng.example.com" {
     type slave;
     file "eng.example.com.bk";
     // IP address of eng.example.com master server
     masters { 192.168.4.12; };
};

named — Internet domain name server

Common Problems

It's not working; how can I figure out what's wrong?

The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand. The log files provide a source of hints and information that can be used to figure out what went wrong and how to fix the problem.

EDNS compliance issues

EDNS (Extended DNS) is a standard that was first specified in 1999. It is required for DNSSEC validation, DNS COOKIE options, and other features. There are broken and outdated DNS servers and firewalls still in use which misbehave when queried with EDNS; for example, they may drop EDNS queries rather than replying with FORMERR. BIND and other recursive name servers have traditionally employed workarounds in this situation, retrying queries in different ways and eventually falling back to plain DNS queries without EDNS.

Such workarounds cause unnecessary resolution delays, increase code complexity, and prevent deployment of new DNS features. As of February 2019, all major DNS software vendors have agreed to remove these workarounds; see https://dnsflagday.net for further details. This change was implemented in BIND as of release 9.14.0.

As a result, some domains may be non-resolvable without manual intervention. In these cases, resolution can be restored by adding server clauses for the offending servers, specifying edns no or send-cookie no, depending on the specific noncompliance.

To determine which server clause to use, run the following commands to send queries to the authoritative servers for the broken domain:


            dig soa <zone> @<server> +dnssec
            dig soa <zone> @<server> +dnssec +nocookie
            dig soa <zone> @<server> +noedns
  

If the first command fails but the second succeeds, the server most likely needs send-cookie no. If the first two fail but the third succeeds, then the server needs EDNS to be fully disabled with edns no.

Please contact the administrators of noncompliant domains and encourage them to upgrade their broken DNS servers.

Incrementing and Changing the Serial Number

Zone serial numbers are just numbers — they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. Occasionally they will make a mistake and set them to a "date in the future" then try to correct them by setting them to the "current date". This causes problems because serial numbers are used to indicate that a zone has been updated. If the serial number on the slave server is lower than the serial number on the master, the slave server will attempt to update its copy of the zone.

Setting the serial number to a lower number on the master server than the slave server means that the slave will not perform updates to its copy of the zone.

The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all slaves have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.

Where Can I Get Help?

The Internet Systems Consortium (ISC) offers a wide range of support and service agreements for BIND and DHCP servers. Four levels of premium support are available and each level includes support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in BIND and DHCP.

To discuss arrangements for support, contact info@isc.org or visit the ISC web page at http://www.isc.org/services/support/ to read more.

BIND 9 Administrator Reference Manual

BIND Version 9.13.7


Table of Contents

1. Introduction
Scope of Document
Organization of This Document
Conventions Used in This Document
The Domain Name System (DNS)
DNS Fundamentals
Domains and Domain Names
Zones
Authoritative Name Servers
Caching Name Servers
Name Servers in Multiple Roles
2. BIND Resource Requirements
Hardware requirements
CPU Requirements
Memory Requirements
Name Server Intensive Environment Issues
Supported Operating Systems
3. Name Server Configuration
Sample Configurations
A Caching-only Name Server
An Authoritative-only Name Server
Load Balancing
Name Server Operations
Tools for Use With the Name Server Daemon
Signals
Plugins
Configuring Plugins
Developing Plugins
4. Advanced DNS Features
Notify
Dynamic Update
The journal file
Incremental Zone Transfers (IXFR)
Split DNS
Example split DNS setup
TSIG
Generating a Shared Key
Loading A New Key
Instructing the Server to Use a Key
TSIG-Based Access Control
Errors
TKEY
SIG(0)
DNSSEC
Generating Keys
Signing the Zone
Configuring Servers for DNSSEC
DNSSEC, Dynamic Zones, and Automatic Signing
Converting from insecure to secure
Dynamic DNS update method
Fully automatic zone signing
Private-type records
DNSKEY rollovers
Dynamic DNS update method
Automatic key rollovers
NSEC3PARAM rollovers via UPDATE
Converting from NSEC to NSEC3
Converting from NSEC3 to NSEC
Converting from secure to insecure
Periodic re-signing
NSEC3 and OPTOUT
Dynamic Trust Anchor Management
Validating Resolver
Authoritative Server
PKCS#11 (Cryptoki) support
Prerequisites
Native PKCS#11
OpenSSL-based PKCS#11
PKCS#11 Tools
Using the HSM
Specifying the engine on the command line
Running named with automatic zone re-signing
DLZ (Dynamically Loadable Zones)
Configuring DLZ
Sample DLZ Driver
DynDB (Dynamic Database)
Configuring DynDB
Sample DynDB Module
Catalog Zones
Principle of Operation
Configuring Catalog Zones
Catalog Zone format
IPv6 Support in BIND 9
Address Lookups Using AAAA Records
Address to Name Lookups Using Nibble Format
5. BIND 9 Configuration Reference
Configuration File Elements
Address Match Lists
Comment Syntax
Configuration File Grammar
acl Statement Grammar
acl Statement Definition and Usage
controls Statement Grammar
controls Statement Definition and Usage
include Statement Grammar
include Statement Definition and Usage
key Statement Grammar
key Statement Definition and Usage
logging Statement Grammar
logging Statement Definition and Usage
masters Statement Grammar
masters Statement Definition and Usage
options Statement Grammar
options Statement Definition and Usage
server Statement Grammar
server Statement Definition and Usage
statistics-channels Statement Grammar
statistics-channels Statement Definition and Usage
trusted-keys Statement Grammar
trusted-keys Statement Definition and Usage
managed-keys Statement Grammar
managed-keys Statement Definition and Usage
view Statement Grammar
view Statement Definition and Usage
zone Statement Grammar
zone Statement Definition and Usage
Zone File
Types of Resource Records and When to Use Them
Discussion of MX Records
Setting TTLs
Inverse Mapping in IPv4
Other Zone File Directives
BIND Master File Extension: the $GENERATE Directive
Additional File Formats
BIND9 Statistics
The Statistics File
Statistics Counters
6. BIND 9 Security Considerations
Access Control Lists
Chroot and Setuid
The chroot Environment
Using the setuid Function
Dynamic Update Security
7. Troubleshooting
Common Problems
It's not working; how can I figure out what's wrong?
EDNS compliance issues
Incrementing and Changing the Serial Number
Where Can I Get Help?
A. Release Notes
Release Notes for BIND Version 9.13.7
Introduction
Note on Version Numbering
Supported Platforms
Download
Security Fixes
New Features
Removed Features
Feature Changes
Bug Fixes
License
End of Life
Thank You
B. A Brief History of the DNS and BIND
C. General DNS Reference Information
IPv6 addresses (AAAA)
Bibliography (and Suggested Reading)
Request for Comments (RFCs)
Internet Drafts
Other Documents About BIND
D. BIND 9 DNS Library Support
BIND 9 DNS Library Support
Installation
Known Defects/Restrictions
The dns.conf File
Sample Applications
Library References
I. Manual pages
arpaname — translate IP addresses to the corresponding ARPA names
ddns-confgen — ddns key generation tool
delv — DNS lookup and validation utility
dig — DNS lookup utility
dnssec-cds — change DS records for a child zone based on CDS/CDNSKEY
dnssec-checkds — DNSSEC delegation consistency checking tool
dnssec-coverage — checks future DNSKEY coverage for a zone
dnssec-dsfromkey — DNSSEC DS RR generation tool
dnssec-importkey — import DNSKEY records from external systems so they can be managed
dnssec-keyfromlabel — DNSSEC key generation tool
dnssec-keygen — DNSSEC key generation tool
dnssec-keymgr — Ensures correct DNSKEY coverage for a zone based on a defined policy
dnssec-revoke — set the REVOKED bit on a DNSSEC key
dnssec-settime — set the key timing metadata for a DNSSEC key
dnssec-signzone — DNSSEC zone signing tool
dnssec-verify — DNSSEC zone verification tool
dnstap-read — print dnstap data in human-readable form
filter-aaaa.so — filter AAAA in DNS responses when A is present
host — DNS lookup utility
mdig — DNS pipelined lookup utility
named-checkconf — named configuration file syntax checking tool
named-checkzone — zone file validity checking or converting tool
named-journalprint — print zone journal in human-readable form
named-nzd2nzf — Convert an NZD database to NZF text format
named-rrchecker — syntax checker for individual DNS resource records
named.conf — configuration file for named
named — Internet domain name server
nsec3hash — generate NSEC3 hash
nslookup — query Internet name servers interactively
nsupdate — Dynamic DNS update utility
pkcs11-destroy — destroy PKCS#11 objects
pkcs11-keygen — generate keys on a PKCS#11 device
pkcs11-list — list PKCS#11 objects
pkcs11-tokens — list PKCS#11 available tokens
rndc-confgen — rndc key generation tool
rndc.conf — rndc configuration file
rndc — name server control utility

BIND Best Practices - Authoritative

1) Run BIND on a server dedicated to DNS only.

Reasons include:

  • Minimized risk of impact to DNS services as a result of other applications consuming server resources (perhaps due to an attack on those services, or due to application error).

  • Conversely, minimized risk to other applications as a result of BIND consuming all system or network resources.

  • Reduced likelihood of unauthorized access to the DNS server (e.g. via a code defect and root access exploit made possible via another application).

  • Improved ability to monitor DNS server performance (since the server is dedicated to one service).

  • Improved ability to troubleshoot problems.

2) Run separate authoritative and recursive DNS servers

  • Do not combine authoritative and recursive nameserver functions -- have each function performed by separate server sets. This advice primarily concerns separation of public-facing authoritative services from internal client-facing recursive services - administrators may, for convenience, choose to serve some internal-only zones authoritatively from their recursive servers, having determined that the benefit outweighs any risks associated with this policy.

    If you share recursive and authoritative functions in the one server, then if there is a problem that impacts authoritative servers only - for example, that causes all of your authoritative servers to fail - it will break your recursive service too.

  • Run multiple, distributed authoritative servers, avoiding single points of failure in critical resource paths. A variety of strategies are available (including anycast and load-balancing) to ensure robust geographic and network diversity in your deployment.

3) Choose appropriate software and hardware

  • Run currently-supported version(s) of BIND in your environment.

  • Subscribe to bind-announce@lists.isc.org to get notified of BIND 9 software updates and security issues.

  • Run currently-supported version(s) of your chosen operating system.

  • Ensure that system outbound network buffers are large enough to handle your rates of outbound query traffic. Some OS implementations (linux particularly some versions) by default assume low rates of outbound network traffic - but an authoritative server will often be responding with significantly larger packets than the queries it received, particularly for signed zones.

  • Run a multi-threaded BIND build and launch named with an appropriate number of task threads tuned for the hardware and CPU architecture.

  • Ensure (and confirm through testing) that your infrastructure supports EDNS0 and large UDP packet sizes.

4) Prevent external access to internal data by design

Originally, DNS was designed to be the same data provided to all clients from all servers. Then, the concept of a split namespace was introduced and included in BIND as the concept of “views”. The use of views is often used to separate internal devices from external devices. lab01printer.example.com might be visible from inside, and possibly via a VPN connection, is probably something that you would want to have visible from the outside.

Problems usually occur in two places with views:

  1. an accidental “leak” of data that is internal-only
  2. external clients, expecting internal views get external views

Number 1 is usually caused by an incorrect access control list (ACL) that allows the internal zone to be transferred to one or more external facing servers. This failure may not be obvious, and without specific testing, for example, creation of a canary entry that only resolves in one configuration and then testing for it from locations that should NOT be able to resolve them.

Number 2 is caused when a VPN fails to connect or when connected, is still seen by the DNS server as “outside” the list of internal networks. Both of these boil down to network infrastructure issues.

While internal vs. external DNS names using views are nearly ubiquitous these days, splitting your DNS into internal and external zones solves the problem in a very obvious and safe way. Internal names, for example, living only in int.example.com and sub-zones of int. External name servers would be configured without any knowledge of the int zone.

5) Take basic security measures

  • Run BIND as an unprivileged user. To open low-numbered UDP and TCP ports BIND must be launched as root, but an alternate uid can be specified using the -u command line argument; after opening needed resources named will change its runtime uid to an unprivileged account.

  • If following the preceding advice (running BIND as an unprivileged user on a dedicated server) chrooting is "de-emphasized." Our operations experts feel that chrooting does not substantially improve security under those conditions and do not affirmatively recommend it, but they do not explicitly discourage it.

  • Make use of BIND access control mechanisms such as address match lists to restrict recursive query service to known and authorized clients. Ideally your Internet-facing authoritative servers should not perform recursion for any clients at all.

  • Consider DNSSEC-signing your public authoritative zones. (Recursive servers will then be able to use DNSSEC-validation to authenticate your records). DNSSEC signing does imply additional on-going maintenance. However, if you operate a service where there is an increased risk of impersonation - such as a financial service, or any public service where the user needs to be sure the resource is really your resource - the effort of signing may be well worth it.

6) Prepare for abuse of any external-facing servers

There are a number of tuning parameters for RRL, but for the most part, the default settings are good.

RRL works by dropping responses into different buckets. Each bucket is the IP address (or a collection of addresses) to which the response is being sent. When a given number of identical responses are seen within a certain length of time in a single bucket, the responses hosts in that bucket are limited. The tunable parameters include the number of identical response before limiting is triggered, the length of time a response stays in the bucket, and the size of the network that each bucket contains.

It is impractical to create one bucket per IP address. The default bucket size is a /24 network (256 IP addresses) for IPv4 and a /56 network (256 networks of 18,446,744,073,709,551,616 addresses each) for IPv6. These bucket sizes represent common subnet sizes for each of the address families.

There are some circumstances under which these bucket sizes may be too small, most revolving around the use of NAT on IPv4 networks. If you discover that you are rate limiting hosts that are innocent because they live with a large number of other hosts behind a single NAT’d IP address, you can either change the bucket size or “white-list” the network(s) by adding them to the exempt-clients list…

rate-limit {
  slip 2; // Every other response truncated
  window 15; // Seconds to bucket
  responses-per-second 5;// # of good responses per prefix-length/sec
  referrals-per-second 5; // referral responses
  nodata-per-second 5; // nodata responses
  nxdomains-per-second 5; // nxdomain responses
  errors-per-second 5; // error responses
  all-per-second 20; // When we drop all
  log-only no; // Debugging mode
  pps-scale 250; // x / 1000 * per-second
 // = new drop limit
  exempt-clients { 127.0.0.1; 192.153.154.0/24; 192.160.238.0/24 };
  ipv4-prefix-length 24; // Define the IPv4 block size
  ipv6-prefix-length 56; // Define the IPv6 block size
  max-table-size 20000; // 40 bytes * this number = max memory
  min-table-size 500; // pre-allocate to speed startup
};
Shell

The example above provides all of the tunable parameters, but as noted, the most useful for initial tuning are the “responses-per-second”, “ipv4-prefix-length” and “exempt-clients”.

There is the “log-only” option that can be set to “yes” to test configurations without actually changing the network performance.

  • A newer feature, worth considering for mitigating amplification attacks is 'minimal-any'. Unlike RRL, this feature is not enabled by default.

  • Provision sufficient capacity to handle burst traffic up to 20x normal level. This overcapacity will help your system to withstand spikes in both legitimate and abuse traffic.

Excess capacity must take into account not only server CPU and memory resources but also send and receive capacity along the entire network path.

  • Consider the length of the TTLs on the delegation records that you manage within your zones, as well as those that are provided by the parent zones that delegate authority to your nameservers. Longer TTLs protect the visibility of a zone, but shorter ones allow for a faster change of nameservers. Long TTLs can also help protect the visibility of a zone when the parent zone's nameservers are under attack. See https://www.dns-oarc.net/wiki/mitigating-dns-denial-of-service-attacks for more information.

  • In most instances we would not recommend the use of inbound packet filtering for authoritative nameservers, Response Rate Limiting is the recommended solution. However, there are some circumstances where filtering at very high inbound packet rates can be helpful - please contact ISC if you think you might benefit from our operational experience in this area.

7) Monitor the service

  • Put in place monitoring scripts to continually check health of servers and alert if conditions change substantially.

    Conditions to monitor include:

    • process presence
    • CPU utilization
    • memory usage
    • network throughput and buffering (inbound/outbound)
    • filesystem utilization (on the log filesystem and also the filesystem containing the named working directory)
  • Logs should be examined periodically for error and warning messages which may provide a tip-off for incipient problems before they become critical.

  • Review the logging configuration to ensure it meets your requirements. BIND's logging defaults are generally sane (passing most of the work to syslog), but may not line up with organizational policy and/or desired data collection/retention standards.

  • When using size-limited files for logging, plan the size of the files and number to retain so that an increased level of logging due to a problem is unlikely to cause the logs from the start of the problem to become unavailable. The exact settings will depend on how quickly problems can be detected and the details of the baseline retention policy.

  • Query logging adds substantial overhead (on the order of 10x) and so should not be turned on without careful consideration.

8) Consider a nanny

  • By design, and for security purposes, the most common mode of failure for BIND is intentional process termination when it encounters an inconsistent state. An automated minder process capable of restarting BIND intelligently is recommended if you do not have 24-hour operations support (and possibly even if you do.) It is especially helpful if any such script can checkpoint and archive the logs when this happens.

9) Prepare for troubleshooting

  • Prior to any trouble, ensure that a strategy is in place for collecting post-mortem information if a server does encounter a problem. This includes:

    • Building named with debug symbols enabled
    • Enabling the BIND XML statistics channel for easy data collection.
    • Designing an appropriate logging strategy and reserving sufficient space on the log filesystem for information to be collected for a significant context period before an event (several hours at least, 24 hours+ preferred.)
    • Ensuring that the uid under which named is running has write permission sufficient to write a core image to its working directory if it segmentation faults and to write named.dump or named.run files if requested by operator.

    See What to do with a misbehaving BIND server and What to do if your BIND or DHCP server has crashed for guidance on troubleshooting problems and the type of information that is useful to collect in those circumstances.

  • Observe query loads periodically to establish baseline expectations. This will enable you to monitor for anything unusual - as defined by the range of 'normal' for your specific operational environment.

  • You should have a strategy that includes both a planned upgrade path to ensure that you can take advantage of improved features and functionality, as well well as how you will respond if there is a security advisory released that has the potential to impact your servers and services. See Which version of BIND do I want to download and install? for more information.

10) Additional measures for high availability

Our general advice for security practices is included in the list above. However many large production environments with mission-critical DNS needs may opt to run servers on multiple hardware and/or OS platforms to increase the "eco-diversity" of their DNS infrastructure. This also includes running different versions of BIND for resilience to potential defects that may not impact all currently supported versions.

  • Many service providers offer 'DNS secondary service' in which they also publish your zones. In this situation, you continue to manage your own zones, but you keep copies updated at the service provider. This option is worth considering for added resilience and extra capacity.
  • We don't recommend anycasting except in very large deployments or if you already have experience with anycasting

The concept of anycast is easy to grasp: A netblock is announced on your network in such a way that it appears at more than one location - someone trying to reach an address in that netblock is routed to the service at the closest (network topology wise) location to them.

This is very useful in complex networks where there may be tens, hundreds or even thousands of networks, each with their own name server - put your name servers into the anycast network, configure your network correctly, provide your clients with the single anycast nameserver address and magically all of your name servers become a single network address and all of your clients use the closest one!

The initial configuration of the anycast DNS instances must take into account a number of additional issues. These issues include the ability to quickly withdraw the anycast route from your network in the case of a DNS server malfunction, the ability to correctly transfer zone data between anycast server instances, and the ability of your support team to debug issues that stem from different clients using different servers.

If a DNS server malfunctions - hung, crashed, unable to provide correct data - the route advertisement to that specific DNS server must be quickly (and automatically) removed. Clients attempting to resolve DNS names using the affected server should be routed to other instances

Debugging a client DNS issue in an anycast network is much more complex and involves many more hands and eyes than does debugging an issue on a traditional network. The most vital concern: When debugging in an anycast environment, be absolutely sure that you and the client with the issue are looking at the same server.

Advanced DNS Features

Name

named.conf — configuration file for named

Synopsis

named.conf

DESCRIPTION

named.conf is the configuration file for named. Statements are enclosed in braces and terminated with a semi-colon. Clauses in the statements are also semi-colon terminated. The usual comment styles are supported:

C style: /* */

C++ style: // to end of line

Unix style: # to end of line

ACL


acl string { address_match_element; ... };
 

KEY


key domain_name {
algorithm string;
secret string;
};

MASTERS


masters string [ port integer ] {
masters | ipv4_address [port integer] |
ipv6_address [port integer] ) [ key string ]; ...
};

SERVER


server ( ipv4_address[/prefixlen] | ipv6_address[/prefixlen] ) {
bogus boolean;
edns boolean;
edns-udp-size integer;
max-udp-size integer;
provide-ixfr boolean;
request-ixfr boolean;
keys server_key;
transfers integer;
transfer-format ( many-answers | one-answer );
transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];

support-ixfr boolean; // obsolete
};

TRUSTED-KEYS


trusted-keys {
domain_name flags protocol algorithm key; ...
};

MANAGED-KEYS


managed-keys {
domain_name initial-key flags protocol algorithm key; ...
};

CONTROLS


controls {
inet ( ipv4_address | ipv6_address | * )
[ port ( integer | * ) ]
allow { address_match_element; ... }
[ keys { string; ... } ];
unix unsupported; // not implemented
};

LOGGING


logging {
channel string {
file log_file;
syslog optional_facility;
null;
stderr;
severity log_severity;
print-time boolean;
print-severity boolean;
print-category boolean;
};
category string { string; ... };
};

LWRES


lwres {
listen-on [ port integer ] {
ipv4_address | ipv6_address ) [ port integer ]; ...
};
view string optional_class;
search { string; ... };
ndots integer;
};

OPTIONS


options {
avoid-v4-udp-ports { port; ... };
avoid-v6-udp-ports { port; ... };
blackhole { address_match_element; ... };
coresize size;
datasize size;
directory quoted_string;
dump-file quoted_string;
files size;
heartbeat-interval integer;
host-statistics boolean; // not implemented
host-statistics-max number; // not implemented
hostname ( quoted_string | none );
interface-interval integer;
listen-on [ port integer ] { address_match_element; ... };
listen-on-v6 [ port integer ] { address_match_element; ... };
match-mapped-addresses boolean;
memstatistics-file quoted_string;
pid-file ( quoted_string | none );
port integer;
querylog boolean;
recursing-file quoted_string;
reserved-sockets integer;
random-device quoted_string;
recursive-clients integer;
serial-query-rate integer;
server-id ( quoted_string | hostname | none );
stacksize size;
statistics-file quoted_string;
statistics-interval integer; // not yet implemented
tcp-clients integer;
tcp-listen-queue integer;
tkey-dhkey quoted_string integer;
tkey-gssapi-credential quoted_string;
tkey-gssapi-keytab quoted_string;
tkey-domain quoted_string;
transfers-per-ns integer;
transfers-in integer;
transfers-out integer;
version ( quoted_string | none );
allow-recursion { address_match_element; ... };
allow-recursion-on { address_match_element; ... };
sortlist { address_match_element; ... };
topology { address_match_element; ... }; // not implemented
auth-nxdomain boolean; // default changed
minimal-responses boolean;
recursion boolean;
rrset-order {
[ class string ] [ type string ]
[ name quoted_string string string; ...
};
provide-ixfr boolean;
request-ixfr boolean;
rfc2308-type1 boolean; // not yet implemented
additional-from-auth boolean;
additional-from-cache boolean;
query-source ( ( ipv4_address | * ) | [ address ( ipv4_address | * ) ] ) [ port ( integer | * ) ];
query-source-v6 ( ( ipv6_address | * ) | [ address ( ipv6_address | * ) ] ) [ port ( integer | * ) ];
use-queryport-pool boolean;
queryport-pool-ports integer;
queryport-pool-updateinterval integer;
cleaning-interval integer;
resolver-query-timeout integer;
min-roots integer; // not implemented
lame-ttl integer;
max-ncache-ttl integer;
max-cache-ttl integer;
transfer-format ( many-answers | one-answer );
max-cache-size size;
max-acache-size size;
clients-per-query number;
max-clients-per-query number;
check-names ( master | slave | response )
( fail | warn | ignore );
check-mx ( fail | warn | ignore );
check-integrity boolean;
check-mx-cname ( fail | warn | ignore );
check-srv-cname ( fail | warn | ignore );
cache-file quoted_string; // test option
suppress-initial-notify boolean; // not yet implemented
preferred-glue string;
dual-stack-servers [ port integer ] {
quoted_string [port integer] |
ipv4_address [port integer] |
ipv6_address [port integer] ); ...
};
edns-udp-size integer;
max-udp-size integer;
root-delegation-only [ exclude { quoted_string; ... } ];
disable-algorithms string { string; ... };
dnssec-enable boolean;
dnssec-validation boolean;
dnssec-lookaside ( auto | no | domain trust-anchor domain );
dnssec-must-be-secure string boolean;
dnssec-accept-expired boolean;

dns64-server string;
dns64-contact string;
dns64 prefix {
clients { <replacable>acl</replacable>; };
exclude { <replacable>acl</replacable>; };
mapped { <replacable>acl</replacable>; };
break-dnssec boolean;
recursive-only boolean;
suffix ipv6_address;
};

empty-server string;
empty-contact string;
empty-zones-enable boolean;
disable-empty-zone string;

dialup dialuptype;
ixfr-from-differences ixfrdiff;

allow-query { address_match_element; ... };
allow-query-on { address_match_element; ... };
allow-query-cache { address_match_element; ... };
allow-query-cache-on { address_match_element; ... };
allow-transfer { address_match_element; ... };
allow-update { address_match_element; ... };
allow-update-forwarding { address_match_element; ... };
update-check-ksk boolean;
dnssec-dnskey-kskonly boolean;

masterfile-format ( text | raw );
notify notifytype;
notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
notify-delay seconds;
notify-to-soa boolean;
also-notify [ port integer ] { ( ipv4_address | ipv6_address )
[ port integer ]; ...
[ key keyname ] ... };
allow-notify { address_match_element; ... };

forward ( first | only );
forwarders [ port integer ] {
ipv4_address | ipv6_address ) [ port integer ]; ...
};

max-journal-size size_no_default;
max-transfer-time-in integer;
max-transfer-time-out integer;
max-transfer-idle-in integer;
max-transfer-idle-out integer;
max-retry-time integer;
min-retry-time integer;
max-refresh-time integer;
min-refresh-time integer;
multi-master boolean;

sig-validity-interval integer;
sig-re-signing-interval integer;
sig-signing-nodes integer;
sig-signing-signatures integer;
sig-signing-type integer;

transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];

alt-transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
alt-transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];
use-alt-transfer-source boolean;

zone-statistics boolean;
key-directory quoted_string;
managed-keys-directory quoted_string;
auto-dnssec allow|maintain|off;
try-tcp-refresh boolean;
zero-no-soa-ttl boolean;
zero-no-soa-ttl-cache boolean;
dnssec-secure-to-insecure boolean;
deny-answer-addresses {
address_match_list
} [ except-from { namelist } ];
deny-answer-aliases {
namelist
} [ except-from { namelist } ];

nsec3-test-zone boolean;  // testing only

allow-v6-synthesis { address_match_element; ... }; // obsolete
deallocate-on-exit boolean; // obsolete
fake-iquery boolean; // obsolete
fetch-glue boolean; // obsolete
has-old-clients boolean; // obsolete
maintain-ixfr-base boolean; // obsolete
max-ixfr-log-size size; // obsolete
multiple-cnames boolean; // obsolete
named-xfer quoted_string; // obsolete
serial-queries integer; // obsolete
treat-cr-as-space boolean; // obsolete
use-id-pool boolean; // obsolete
use-ixfr boolean; // obsolete
};

VIEW


view string optional_class {
match-clients { address_match_element; ... };
match-destinations { address_match_element; ... };
match-recursive-only boolean;

key string {
algorithm string;
secret string;
};

zone string optional_class {
...
};

server ( ipv4_address[/prefixlen] | ipv6_address[/prefixlen] ) {
...
};

trusted-keys {
string integer integer integer quoted_string;
[...]
};

allow-recursion { address_match_element; ... };
allow-recursion-on { address_match_element; ... };
sortlist { address_match_element; ... };
topology { address_match_element; ... }; // not implemented
auth-nxdomain boolean; // default changed
minimal-responses boolean;
recursion boolean;
rrset-order {
[ class string ] [ type string ]
[ name quoted_string string string; ...
};
provide-ixfr boolean;
request-ixfr boolean;
rfc2308-type1 boolean; // not yet implemented
additional-from-auth boolean;
additional-from-cache boolean;
query-source ( ( ipv4_address | * ) | [ address ( ipv4_address | * ) ] ) [ port ( integer | * ) ];
query-source-v6 ( ( ipv6_address | * ) | [ address ( ipv6_address | * ) ] ) [ port ( integer | * ) ];
use-queryport-pool boolean;
queryport-pool-ports integer;
queryport-pool-updateinterval integer;
cleaning-interval integer;
resolver-query-timeout integer;
min-roots integer; // not implemented
lame-ttl integer;
max-ncache-ttl integer;
max-cache-ttl integer;
transfer-format ( many-answers | one-answer );
max-cache-size size;
max-acache-size size;
clients-per-query number;
max-clients-per-query number;
check-names ( master | slave | response )
( fail | warn | ignore );
check-mx ( fail | warn | ignore );
check-integrity boolean;
check-mx-cname ( fail | warn | ignore );
check-srv-cname ( fail | warn | ignore );
cache-file quoted_string; // test option
suppress-initial-notify boolean; // not yet implemented
preferred-glue string;
dual-stack-servers [ port integer ] {
quoted_string [port integer] |
ipv4_address [port integer] |
ipv6_address [port integer] ); ...
};
edns-udp-size integer;
max-udp-size integer;
root-delegation-only [ exclude { quoted_string; ... } ];
disable-algorithms string { string; ... };
dnssec-enable boolean;
dnssec-validation boolean;
dnssec-lookaside ( auto | no | domain trust-anchor domain );
dnssec-must-be-secure string boolean;
dnssec-accept-expired boolean;

dns64-server string;
dns64-contact string;
dns64 prefix {
clients { <replacable>acl</replacable>; };
exclude { <replacable>acl</replacable>; };
mapped { <replacable>acl</replacable>; };
break-dnssec boolean;
recursive-only boolean;
suffix ipv6_address;
};

empty-server string;
empty-contact string;
empty-zones-enable boolean;
disable-empty-zone string;

dialup dialuptype;
ixfr-from-differences ixfrdiff;

allow-query { address_match_element; ... };
allow-query-on { address_match_element; ... };
allow-query-cache { address_match_element; ... };
allow-query-cache-on { address_match_element; ... };
allow-transfer { address_match_element; ... };
allow-update { address_match_element; ... };
allow-update-forwarding { address_match_element; ... };
update-check-ksk boolean;
dnssec-dnskey-kskonly boolean;

masterfile-format ( text | raw );
notify notifytype;
notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
notify-delay seconds;
notify-to-soa boolean;
also-notify [ port integer ] { ( ipv4_address | ipv6_address )
[ port integer ]; ...
[ key keyname ] ... };
allow-notify { address_match_element; ... };

forward ( first | only );
forwarders [ port integer ] {
ipv4_address | ipv6_address ) [ port integer ]; ...
};

max-journal-size size_no_default;
max-transfer-time-in integer;
max-transfer-time-out integer;
max-transfer-idle-in integer;
max-transfer-idle-out integer;
max-retry-time integer;
min-retry-time integer;
max-refresh-time integer;
min-refresh-time integer;
multi-master boolean;
sig-validity-interval integer;

transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];

alt-transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
alt-transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];
use-alt-transfer-source boolean;

zone-statistics boolean;
try-tcp-refresh boolean;
key-directory quoted_string;
zero-no-soa-ttl boolean;
zero-no-soa-ttl-cache boolean;
dnssec-secure-to-insecure boolean;

allow-v6-synthesis { address_match_element; ... }; // obsolete
fetch-glue boolean; // obsolete
maintain-ixfr-base boolean; // obsolete
max-ixfr-log-size size; // obsolete
};

ZONE


zone string optional_class {
type ( master | slave | stub | hint | redirect |
forward | delegation-only );
file quoted_string;

masters [ port integer ] {
masters |
ipv4_address [port integer] |
ipv6_address [ port integer ] ) [ key string ]; ...
};

database string;
delegation-only boolean;
check-names ( fail | warn | ignore );
check-mx ( fail | warn | ignore );
check-integrity boolean;
check-mx-cname ( fail | warn | ignore );
check-srv-cname ( fail | warn | ignore );
dialup dialuptype;
ixfr-from-differences boolean;
journal quoted_string;
zero-no-soa-ttl boolean;
dnssec-secure-to-insecure boolean;

allow-query { address_match_element; ... };
allow-query-on { address_match_element; ... };
allow-transfer { address_match_element; ... };
allow-update { address_match_element; ... };
allow-update-forwarding { address_match_element; ... };
update-policy local |  {
( grant | deny ) string
( name | subdomain | wildcard | self | selfsub | selfwild |
                  krb5-self | ms-self | krb5-subdomain | ms-subdomain |
  tcp-self | zonesub | 6to4-self ) string
rrtypelist;
[...]
}
;
update-check-ksk boolean;
dnssec-dnskey-kskonly boolean;

masterfile-format ( text | raw );
notify notifytype;
notify-source ( ipv4_address | * ) [ port ( integer | * ) ];
notify-source-v6 ( ipv6_address | * ) [ port ( integer | * ) ];
notify-delay seconds;
notify-to-soa boolean;
also-notify [ port integer ] { ( ipv4_address | ipv6_address )
[ port integer ]; ...
[ key keyname ] ... };
allow-notify { address_match_element; ... };

forward ( first | only );
forwarders [ port integer ] {
ipv4_address | ipv6_address ) [ port integer ]; ...
};

max-journal-size size_no_default;
max-transfer-time-in integer;
max-transfer-time-out integer;
max-transfer-idle-in integer;
max-transfer-idle-out integer;
max-retry-time integer;
min-retry-time integer;
max-refresh-time integer;
min-refresh-time integer;
multi-master boolean;
request-ixfr boolean;
sig-validity-interval integer;

transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];

alt-transfer-source ( ipv4_address | * )
[ port ( integer | * ) ];
alt-transfer-source-v6 ( ipv6_address | * )
[ port ( integer | * ) ];
use-alt-transfer-source boolean;

zone-statistics boolean;
try-tcp-refresh boolean;
key-directory quoted_string;

nsec3-test-zone boolean;  // testing only

ixfr-base quoted_string; // obsolete
ixfr-tmp-file quoted_string; // obsolete
maintain-ixfr-base boolean; // obsolete
max-ixfr-log-size size; // obsolete
pubkey integer integer integer quoted_string; // obsolete
};

FILES

/etc/named.conf