The #1 complaint I hear most from people about the BIND 9 name server (other than a ridiculous “it sucks”, which it certainly doesn’t) is how horrible it’s configuration file is. I’ve never understood that. Agreed, the named.conf file has lots of braces, and each statement has to be terminated with a semicolon, but so what? Perl programs and JavaScript or C are similar. Once you get used to that, there’s pretty much nothing which BIND 9 will not do. Anyway, for all administrators who dislike braces and semicolons, I have some good news: BIND’s configuration is changing.

A lot is changing.

After several years of development, the beta release 1.0.0 of BIND 10 has been announced, and I can tell you one thing: everything changes. Let me tell you a bit about the very little I’ve learned so far.

First off: the process model. While BIND 9 was a single process (named), BIND 10 has been split up into a number of processes, coordinated by a so-called “boss” which speaks to its components via a UNIX domain socket. (If you’re more used to mail servers, I’d compare this to the difference between Exim and Postfix: the former does all in a single binary, the latter uses different binaries to perform individual tasks.) This model was chosen to increase reliability as well as to be able to replace individual components without breakage. The individual processes (copied from the guide) are:

• b10-auth — Authoritative DNS server. This process serves DNS requests.
• b10-cfgmgr — Configuration manager. This process maintains all of the configuration for BIND 10.
• b10-cmdctl — Command and control service. This process allows external control of the BIND 10 system.
• b10-ddns — Dynamic DNS update service. This process is used to handle incoming DNS update requests to allow granted clients to update zones for which BIND 10 is serving as a primary server.
• b10-msgq — Message bus daemon. This process coordinates communication between all of the other BIND 10 processes.
• b10-resolver — Recursive name server. This process handles incoming DNS queries and provides answers from its cache or by recursively doing remote lookups.
• b10-sockcreator — Socket creator daemon. This process creates sockets used by network-listening BIND 10 processes.
• b10-stats — Statistics collection daemon. This process collects and reports statistics data.
• b10-stats-httpd — HTTP server for statistics reporting. This process reports statistics data in XML format over HTTP.
• b10-xfrin — Incoming zone transfer service. This process is used to transfer a new copy of a zone into BIND 10, when acting as a secondary server.
• b10-xfrout — Outgoing zone transfer service. This process is used to handle transfer requests to send a local zone to a remote secondary server.
• b10-zonemgr — Secondary zone manager. This process keeps track of timers and other necessary information for BIND 10 to act as a slave server.

Next up, zone file storage. BIND 9 uses zone master files (i.e. files on disk, which some people generate from a provisioning system), and BIND 10 uses an SQL database. The current implementation is atop SQLite, with others supposedly to come. (This confuses me a bit, because the DHCPv6 component of BIND 10 utilizes MySQL.) Utilities exist to load zones from zone master files into the storage back-end, and individual processes are responsible for incoming and outgoing zone transfers (XFR).

BIND 10’s configuration may (or may not) appeal to BIND 9-haters: named.conf has gone. It’s been replaced by a so-called “configuration manager”. It’s task is to store configuration and provide it to the other parts of the system. We “talk” to the configuration manager via a control interface over a RESTful API, and the configuration is stored as JSON, but we probably shouldn’t touch that file – our interface to the configuration is called bindctl. (Don’t ever tell me you don’t like braces and semicolons…!)

{
   "Boss" : {
      "components" : {
         "b10-resolver" : {
            "priority" : 10,
            "special" : "resolver",
            "kind" : "needed"
         },
         "b10-auth" : {
            "special" : "auth",
            "kind" : "needed"
         },
         "b10-xfrin" : {
            "kind" : "dispensable",
            "address" : "Xfrin"
         },
         "b10-stats" : {
            "kind" : "dispensable",
            "address" : "Stats"
         },
         "b10-cmdctl" : {
            "special" : "cmdctl",
            "kind" : "needed"
         }
      }
   },
   "version" : 2,
   "Resolver" : {
      "listen_on" : [
         {
            "address" : "::1",
            "port" : 5353
         },
         {
            "address" : "127.0.0.1",
            "port" : 5353
         }
      ]
   },
   "Xfrin" : {
      "zones" : [
         {
            "master_addr" : "192.168.1.20",
            "name" : "ww.mens.de"
         }
      ]
   }
}

BIND 10’s other features include

• a C++ library for DNS with Python wrappers
• DHCPv4 and DHCPv6 servers
• statistics collectors

The BIND 10 Guide tells us how to get started, and I suggest you read that carefully.

I got at a bit of a surprise when I looked at the process list:

28871 pts/1    S+     0:00 /usr/bin/python3.1 /opt/bind10/sbin/bind10
28874 pts/1    S      0:00 /usr/bin/python3.1 /opt/bind10/libexec/bind10-devel/b10-msgq
28875 pts/1    S      0:00 /usr/bin/python3.1 /opt/bind10/libexec/bind10-devel/b10-cfgmgr
28876 pts/1    Sl     0:00 /usr/bin/python3.1 /opt/bind10/libexec/bind10-devel/b10-cmdctl
28878 pts/1    S      0:00 /usr/bin/python3.1 /opt/bind10/libexec/bind10-devel/b10-stats

I was aware that bits and pieces where in Python, but I wasn’t expecting most of it to be.

$ netstat -anp|grep 53
tcp   0  0 0.0.0.0:53     0.0.0.0:*    LISTEN      28871/python3.1 
tcp6  0  0 :::53          :::*         LISTEN      28871/python3.1 
udp   0  0 0.0.0.0:53     0.0.0.0:*                28871/python3.1 
udp6  0  0 :::53          :::*                     28871/python3.1 

After launching the authoritative components, I loaded a zone or two. Zone data is immediately available to be served by the authoritative portion of the name server.

$ b10-loadzone a.aa 
Using SQLite3 database file /opt/bind10/var/bind10-devel/zone.sqlite3
Zone name is a.aa.
Loading file "a.aa"
50 RR(s) loaded in 0.04 second(s) (100.00% of a.aa)                             
Done.

I mentioned zone data is in an SQLite database, so let me look at that:

SELECT * FROM zones;
1|e.org.|IN|0
2|a.aa.|IN|0

SELECT id, name, ttl, rdtype, rdata FROM records WHERE zone_id = 2 LIMIT 5;
5|a.aa.|60|SOA|localhost.a.aa. root.localhost. 81 28800 14400 3600000 86400
6|a.aa.|60|NS|localhost.a.aa.
7|a.aa.|300|A|1.1.1.1
8|a.aa.|300|A|1.1.1.2
9|a.aa.|300|A|127.0.0.1

Let me test incoming zone transfers. First I have to enable the process:

$ bindctl 
[TEMP MESSAGE]: username :root  password :bind10
Username:root
Password: ["login success "]

> config add Boss/components b10-xfrin
> config set Boss/components/b10-xfrin/address Xfrin
> config set Boss/components/b10-xfrin/kind dispensable                                                
> config commit

at which time the log shows:

INFO  [b10-boss.boss] BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
INFO  [b10-boss.boss] BIND10_COMPONENT_START component b10-xfrin is starting
INFO  [b10-boss.boss] BIND10_STARTING_PROCESS starting process b10-xfrin

Now I can configure BIND 10 to load a zone from a master:

> config add Xfrin/zones
> config set Xfrin/zones[0]/name "ww.mens.de"
> config set Xfrin/zones[0]/master_addr "192.168.1.20"
> config commit

Nothing happened until I triggered a manual zone transfer, but I haven’t looked into why that is.

> Xfrin retransfer zone_name = "ww.mens.de"
"zone xfrin is started"

Recursion

BIND 10 includes a recursive server, but if you’ve glanced at the JSON snippet above, you’ll have noticed that, because it’s a separate process, the authoritative and recursive bits of BIND 10 cannot listen on the same address/port pair. With BIND 9 people (sometimes unfortunately) enabled authoritative and recursive serving on the same box; that is no longer possible which means (for some) a re-design of their DNS infrastructure.

I’ve only touched the very top of the tip of the iceberg, but I can tell you one thing already: I have a lot to learn.