Exploring the new Bind 10 name server

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)

Listing 4

Enabling the Zone Transfer Component

01 config add Init/components b10-xfrout
02 config set Init/components/b10-xfrout/address Xfrout
03 config set Init/components/b10-xfrout/kind dispensable
04 config commit

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.

Listing 5

Bind 10 as a Secondary Name Server

01 config add /Init/components b10-xfrin
02 config set /Init/components/b10-xfrin/address Xfrin
03 config set /Init/components/b10-xfrin/kind dispensable
04 config add /Init/components b10-zonemgr
05 config set /Init/components/b10-zonemgr/address Zonemgr
06 config set /Init/components/b10-zonemgr/kind dispensable
07 config commit
08 config add Xfrin/zones
09 config set Xfrin/zones[0]/name "example.test"
10 config set Xfrin/zones[0]/master_addr "10.1.1.1"
11 config commit
12 config add Zonemgr/secondary_zones
13 config set Zonemgr/secondary_zones[0]/name "example.test"
14 config commit

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.

Listing 6

Setting up Dynamic DNS Updates

01 config add Init/components b10-ddns
02 config set Init/components/b10-ddns/address DDNS
03 config set Init/components/b10-ddns/kind dispensable
04 config commit
05 config add DDNS/zones
06 config set DDNS/zones[0]/origin 2.168.192.in-addr.arpa
07 config add DDNS/zones[0]/update_acl {"action":"ACCEPT","from":"192.168.1.1"}
09 config commit

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.

Listing 7

Recursive Name Server

01 config add Init/components b10-resolver
02 config set Init/components/b10-resolver/special resolver
03 config set Init/components/b10-resolver/kind needed
04 config set Init/components/b10-resolver/priority 10
05 config commit
06 config add Resolver/listen_on
07 config set Resolver/listen_on[2]/address "10.1.1.1"
08 config set Resolver/listen_on[2]/port 53
09 config add Resolver/query_acl
10 config set Resolver/query_acl[2] {"action":"ACCEPT","from":"10.1.0.0/16"}
11 config commit

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.

Listing 8

Logging to a File

01 config add Logging/loggers
02 config set Logging/loggers[0]/name *
03 config set Logging/loggers[0]/severity INFO
04 config add Logging/loggers[0]/output_options
05 config set Logging/loggers[0]/output_options[0]/destination file
06 config set Logging/loggers[0]/output_options[0]/output /var/log/dnslog
07 config set Logging/loggers[0]/output_options[0]/maxsize 204800
08 config set Logging/loggers[0]/output_options[0]/maxver 8
09 config commit

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • DoS Attack Exploit in BIND 9

    A specially crafted dynamic update message to a DNS zone for which the server is a master can raise havoc in BIND 9. An active remote exploit is already "in wide circulation."

  • DNSSEC

    Some Internet exploits target name resolution servers. DNSSEC uses cryptography to protect the name resolution service.

  • Charly's Column

    A partly overloaded DNS server can slow down all the workstations on the network. Dnsgraph is an early warning system that gives administrators a graph of critical values. Your Dnsgraph charts will help you keep your systems serving names.

  • DHCP and DNS on Rasp Pi

    The versatile Raspberry Pi can serve many roles on a home network. We'll show you how to set up the Pi to provide some important network services.

  • Security Lessons: DNS Security

    Kurt describes how to keep bad guys out of your network using a targeted filtering approach.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News