Primary or Secondary?

Normally primary name servers have at least one secondary name server that copies the zones in what is known as a zone transfer process. To prevent any unauthorized person from obtaining a list of all hosts in a zone, Bind secures the zone transfer either at the IP level or  – and this is much safer – using a key or a combination of key and IP.

Bind 10 uses a key ring, which could contain multiple keys. Each entry consists of a group of three, with the name of the key, the key itself, and the actual algorithm. The administrator can omit the default algorithm, HMAC-MD5, from the name, but it is generally recommended to use other algorithms and then name them explicitly as well.

bindctl lets you create a new key:

config add tsig_keys/key "example.org.:Nvf5WLM1LA0E2VuhnkbE4Q=="

You can now reference the key in ACLs below example.org. For the secondary name server to be able to perform zone transfers, the admin must enable another component. Again, bindctl is needed for this (Listing 4)

In the default configuration, the name server allows zone transfers from anywhere, without restrictions. This is also shown in the implicitly generated ACL: config show Xfrout/transfer_acl. You can manage this behavior either per zone with separate ACLs, or globally.

ACLs can be written in JSON format and have the following form:

{"action":"ACCEPT|REJECT|DROP", "from":"<IP_range>","key":"<name_of_key>"}

The IP_range lets you define a single address or a range in the form of 192.168.1.0/24, as in older versions of Bind. This feature naturally applies to both IPv4 and IPv6 addresses and networks. from and key are optional and need not be present, but if they do exist in a rule, this is considered an AND operation. A ruleset consists of several rules in which commas separate the {...} blocks; square brackets group the whole enchilada. Because this is an array, you can add ACLs with a set command instead of the usual add commands:

config set Xfrout/transfer_acl [{<first block>}, {<second block>}, ...]

It is also possible to create more complicated mappings in the ACLs. Chapter 9 of the "Bind 10 Admin Guide" provides some examples [3]. In the test, however, we only managed to release zones that Bind stored in its SQLite database. The reason for this was probably that the database has more tables for incremental zone transfers, but this option is not intended for flat files.

If you want a Bind 10 name server to act as a secondary, you need to add and configure two components: Xfrin handles the actual zone transfers; Zonemgr checks the SOA records for changes and triggers Xfrin as needed. The Bindctl statements in Listing 5 show how to configure Bind 10 as a secondary and how to integrate a zone.

The logfile then contains entries that prove Bind does not run the zone transfer until after the final config commit at the end. You can also manually trigger a zone transfer with the following command:

Xfrin retransfer zone_name="example.test" master=10.1.1.1

Unfortunately it is not possible in the current release to set ACLs for notifies, so notifies can definitely be spoofed. The "Bind 10 Admin Guide" [3] only offers the following laconic entry: "Access control (such as allowing notifies) is not yet provided. The primary/secondary service is not yet complete."

Dynamic DNS

Bind 10 supports dynamic DNS updates that reach the computer from, say, another DHCP server. The built-in Bind 10 DHCP server is not capable of generating them.

That said: a separate component exists on the DNS server to integrate updates; you need to enable it using bindctl. Additionally, for each zone you want to receive updates, you need to enter an ACL that explicitly permits this. Listing 6 shows the configuration statements and an ACL for a zone.

Both recursive and primary and secondary name servers are separated into two components in Bind 10. If you follow the developer's advice, the two components should not run on the same host, if only because each of the components wants to accept connections to DNS on port 53; inevitably, they will get in each other's way. If you want to use them on a single host, you at least need to bind the resolver and primary to different IP addresses.

Listing 7 shows how bindctl initializes the recursive name server. Because the recursive server in the default configuration only accepts connections on localhost, and an ACL is set up by default to accept only recursive queries from localhost, you need to add 10.1.1.1 to the list of addresses on which Bind accepts requests and add an ACL that also allows recursive queries for the local 10.1.0.0/16 network.

Logging

In the default configuration, Bind 10 writes all log information to the console where it was started. For productive operation, however, you will want to pass the messages to either syslog or a separate file. The Logging keyword helps you manage the configuration hierarchy. You can set up individual instances of the loggers type below it. A logger can record the actions of one or more components. This setting is configurable via the name parameter, where * references all components.

Listing 8 shows how to send log entries to a file. In this case, Bind also takes care of log rotation and lets you limit the size of the logfiles. Using syslog as the destination lets you pass on the messages to the syslog server. The output parameter contains the syslog facility. The severity in the logger definition (line 3) is set automatically if you use syslog. The output_options are defined as an array; however, in our lab, they resulted in two entries below a logger, neither of which worked.