patches to make bind9 with TKEY/GSS updates easier to configure

[tridge at samba.org]

Hi All,

In the Samba project we recommend using bind9 to support dynamic DNS
updates from Windows hosts, using TKEY/GSSAPI. Unfortunately we've
found that configuring bind9 correctly for updates has been the most
problematic part of the whole process of setting up Samba4.

To fix this, I'm working on some patches to bind that will make it
harder to get the config wrong. I'd like some guidance on what
approaches would be acceptable for inclusion in a future version of
bind. In particular I'd like to know what approaches to backwards
compatibility with the current configuration of TKEY/GSSAPI are
preferred, and what approach to external update helpers is preferred.

The basic problems with the current configuration are:

 1) The tkey-gssapi-credential option should not be needed as the
 first argument to dst_gssapi_acceptctx() can be NULL, in which case
 GSSPI will match against any key in the keytab. I'd like to allow
 this instead:

	tkey-gssapi-credential "automatic";

 We could also support statements like this:

	tkey-gssapi-credential "DNS/*";

 where we would still pass NULL to dst_gssapi_acceptctx() but we'd
 check which principal matched and then do a wildcard match against
 the tkey-gssapi-credential to see if the match is acceptable.

 2) bind should not be doing tests on the krb5 config at startup,
 which it currently does in tkeyconf.c. It relies on the KDC being up
 and properly configured, with creates a problem with startup order
 for daemons and also makes it more difficult when provisioning Samba
 as the kerberos configuration changes. The simplest change is to just
 skip all the krb5 tests in tkeyconf.c if tctx->gss_automatic is
 ISC_TRUE, which would be set if tkey-gssapi-credential is "automatic"

 3) I think we need to be able to set the kerberos keytab in the bind
 config, instead of relying on the KEYTAB_FILE and/or KRB5_KTNAME
 environment variables in the underlying kerberos libs. We can do this
 using gsskrb5_register_acceptor_identity(). Apart from the fact that
 relying on an environment variable for a key part of the
 configuration (excuse the pun!) is a bad idea, I've also found that
 when people are debugging they often restart named manually, either
 under GDB or just at a root shell. They commonly forget to set the
 right krb5 environment variable for the keytab, which leads to a lot
 of frustration with debugging. Unfortunately bind does not provide
 very useful error messages when this happens.

 So I'd propose we have a tkey-gssapi-keytab option, which if set
 causes gsskrb5_register_acceptor_identity() to be used on each
 TKEY/GSSAPI check.

 4) I'd like to be able to set all these options on a per-zone
 basis. This is really where some guidance on the approach to patching
 is needed. If I move all the tkey-gssapi-* options to be per-zone,
 then should we deprecate the global ones? Or set the defaults for the
 per-zone ones based on the global ones? 

 The reason for making it per-zone is that it is quite reasonable to
 have dynamic updates setup for more than one zone, and the admin will
 probably want separate keytabs and principal names for each zone.

 5) finally, I'd like to support calling out to an external helper for
 making dynamic update decisions. The bind daemon just doesn't have
 enough information to decide if a TKEY/GSSAPI update should be
 allowed. The correct calculation for Samba involves quite complex
 ACLs, which requires examining the complete NT token in the kerberos
 ticket. We work around this for now by dynamically generating a list
 of bind9 ACLs for domain controllers and then using rndc from Samba
 to tell bind9 to reload whenever this changes.

 I would far prefer a mechanism that passed the ticket and the
 requested DNS change to an optional external program, which we would
 provide as part of Samba (it would probably be a small python
 script). Alternatively we could have a unix domain socket, and a
 defined protocol for asking a daemon listening on the socket if an
 update should be allowed.

 Which approach would the bind developers prefer for this?

I'm quite happy to develop and submit patches for all of these things
myself, I'd just like some guidance on the approach that is most
likely to be accepted into future releases.

Cheers, Tridge