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

Michael Graff mgraff at
Mon Nov 29 23:22:51 UTC 2010

Hash: SHA1

On 2010-11-22 8:50 PM, tridge at wrote:

>  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.

I'm all for easier configuration, especially where GSSAPI and BIND 9 meet.

I think you're saying that the client's credentials that are presented
will be matched to the appropriate key in the keytab?  It won't just
fail if the first entry doesn't match?

>  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"

So long as we handle other failures later gracefully, I'm fine with this.

>  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.

Seems sane.

>  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.

In general, options trickle up:  if the zone doesn't set one, the view
is checked.  If the view doesn't set one, the global option is checked.
 If that is not set, then some default is used, or it is an error.

Is there actually a case where people are wanting this, or is this
intuition that it's likely it would be needed?

>  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?

In general, calling out would mean a fork() of some sort?  If so, the
Unix domain socket (or the Windows equivalent) over calling an external

> 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.

In general, there are things that will get code contributed more easily.
 We are using a test-driven style now, and so tests for new and changed
code is a requirement for us to release it to the world.  Since BIND 9
doesn't have stellar test coverage, this often means writing tests for
existing functionality to ensure it works first as a safety net.

We would also prefer more frequent code drops rather than one big pile
at the end.  If we could stage out the features so that they don't all
appear at once, it may benefit people faster, and we should get more
frequent feedback from users.  AKA "agile."

Perhaps we two should discuss this offline too.  It seems that working
closely with Samba is a good thing for both teams, and good for those
wanting an open source solution.

- --Michael
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the bind-workers mailing list