In the fall and winter of 2009, several meetings were held to discuss the possible BIND 10 user interface design with operators. Members of the BIND 10 team moderated these sessions and presented versions of the attached slide deck:

The following is a summary of the operators feedback:

At RIPE, in Lisbon, Portugal:

2 sessions:

First session

There were 8 participants from 7 organizations (moderator: Shane Kerr, ISC)

Moderator explained the basic idea of operating more like a router than a standard Unix daemon with a config file holding the configuration.

The immediate reaction was that nobody likes the way configuration works in Cisco routers, and we should not try to duplicate them. Cisco routerss allow you to have a running configuration which does not match the configuration file, for example.

REQUIREMENT: Use the same configuration on multiple servers. (This is easy with file-based configuration.)

Participant: Need to be able to dump, check into RCS, and so on. Need to be able to attach reasoning/notes to configurations. ITIL needs change management, configuration management, and so on.

REQUIREMENT: Must work with configuration/change management software & systems.

Participant: Need to be able to export configuration. Need to be able to send snippets to bind-users for example.

REQUIREMENT: Must be able to export configuration.

Participant: We never touch configuration files - everything is in an SQL database.

Participant: Granularity of the configuration is important. Versioning, transactions, etc. all very nice.

Participant: Should be something that fits into cfengine (for example).

Participant: Yes, needs to work with other software.

Participant: Zone management and configuration management are different things.

Participant: Changes to zones must not impact the server.

Participant: Need to appeal to non-experts!

Participant: Much of this stuff, like version control, is *more* important for non-experts.

Moderator: In pre-BIND 10 there was some confusion about what configuration is and what program data is. So, zones configuration is really different from server configuration.

Participant: This separation also includes views, TSIG keys, and more.

REQUIREMENT: Need a way of the name server dumping what it thinks the current configuration is.

Participant: How does Apache solve this with 1000s of domains? What about Postfix?

REQUIREMENT: All representations of configuration must be in sync.

Participant: Do we need interaction? Maybe we just need fast reload?

Participant: JunOS is very good. Change, commit, rollback, XML API. Maybe look at Juniper tutorials.

Participant: Firefox about:config is a good start.

Second session (moderated by Larissa Shapiro and Shane Kerr of ISC)

10 participants from 5 organizations came up with the following feedback (moderated by Shane Kerr, ISC):

Participant – he likes juniper because he likes to be able to test and to rollback config. Its easy to solve outdated config issues by having a tool that writes out the current config at frequent intervals with date stamps

Participant – its clear that BIND 9 isn't optimal, however as much as he likes the command channel and it does make sense he doubts that this would be his primary interface. He has a provisioning system a nd generates all the config variants and then ships them all at once. The consequence of this from his point of view is that we must remember that there is no fit everyone solution. Keep this in mind. That said he can already see ways to leverage this new command channel interface to batch changes through the command channel. Somewhere we must accommodate the very large scale users. (and whatr about enterprise users?)

Participant: – what is config? Right now zone files are data and every thing else is config but this is not the truth,

On the subject of command line vs web gui vs....

concern from a participant: re: custom tools – in all honesty he will not only have BIND 10 name servers he has a mix. So what he is really looking for is a generic control interface with vendor specific plugins/hooks/extensions. He realizes BIND 10 is aiming for lots of components and he will select a subset but his concern is that the core part he would like to see as an open protocol which could be used across platforms and everything vendor specific in a specific corner. The open protocol would not change over different versions.

On the subject of versioning

need to serialize – store configs in a database an d somehow get in and out

A participant noted his TLD has moved away from versioning because in the whole picture the actual version loses relevance. They chop their config into sections (provisioning, keys, customer, infrastriucture, etc)

Could a BIND10 sql database do that?

Participant: our registry does something similar – they have bits they stitch together as necessary and each is versioned separately

Participant – we're doing two things atr once – good to separate bind10 and this command and control management stuff into two products.

Another participant agrees. Would need to be really clear that the command and control interface might be separate and might also support other DNS implementations.

At NANOG, in Detroit, USA

6 participants from 5 organizations came up with the following feedback (moderated by Larissa Shapiro of ISC)

General high enthusiasm for the runtime config idea.

There was considerable support for the "atomic transaction" idea - specific request from one participant (from a large ISP) for "a way to feed BIND a new config over the whole network at once"

While no one there was concerned about/interested in Web based GUIs, we agreed that this group was not in any way reflective of the full user base. Two of the participants noted their companies do have existing config management systems based on flat files that they would have to integrate with.

One participant noted: Not many places use heterogenous code (more than one DNS impelementation)

Another participant responded: actually, we do, I think many large networks do

Participant: there are really 2 things we want to feed into an interface like this. Either 1) a set of instructions (delta) or a complete new configuration file

Participant: For us it always goes through a human, human-->process-->machine. We keep infinite rollback, we always do buddy checks before updating config, and its all kept in text files.

Participant: if there was a database generated config snapshot, could it then be used as a named.conf in a BIND 9 server?

The idea of a DNS management RFC based on these ideas came up again....

We then still had a little time so there was some "what else would be neat in BIND 10" discussion whuich brought up:

Participant: would be good to have the recursive resolver be able to use an ACL to resolve TSIG

Participant: PHP backend... we would like to be able to track zone metadata in there.

A participant also asked about MultiMaster?.

Participan: would be great to have a utility that could fetch a zone off the network and make it a master

Someone asked about mapping to scripts that manage IP addresses instead of the IP addresses themselves

There were multiple requests to make the documentation easier and more thorough.

At OARC, in Beijing China

Han Feng and his colleages from CNNIC (Feng is also a BIND 10 developer) held a session and had the following key findings:

1 Cluster configuration; BIND10 will support cluster, so command control should be very convenient to control several servers. 2 User management; command control should support multi-user, and different user has different privilege, so they can execute different command 3 GUI client; It will be useful if we have windows and Web GUI client

Last modified 10 years ago Last modified on Feb 20, 2010, 1:03:59 AM