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

tridge at tridge at
Sat Dec 4 03:43:28 UTC 2010

Hi Michael,

 > >>  4) I'd like to be able to set all these options on a per-zone
 > ...
 > I believe this has been decided as a "too hard right now" thing?

yes. The problem is that the initial TKEY query doesn't have a good
way to get the zone from the packet. You could make a pretty good
guess at the zone, but not 100% reliably. As you pointed out on IRC
the rfc2930 introduction says:

  "Note that TKEY established keying material and TSIGs that use it are
   associated with DNS servers or resolvers.  They are not associated
   with zones."

So I've given up on zone based config for now.

One of the reasons I wanted to do zone based config was that I wanted
to have a single named.conf include line pointing at a generated
named.conf snippet for administrators to add to their bind config, to
minimise the chance of administrator mistakes. We could also achieve
this by allowing a include file to add to an existing options{}
section. So I started looking at how hard it would be to allow
multiple options{} statements in named.conf, with each building on the
previous one. I haven't managed to get that to work yet (in fact, I'm
still trying to work out how the bind9 config parsing system really

I think it would be even better if bind supported syntax like this:

  include-directory "/etc/bind/conf.d";

where it would load all config files ending in .conf in that
directory. That is a pretty common pattern with daemons these days. If
it supported that then Samba (and anything else that needs special
bind config) could just add a file like
/etc/bind/conf.d/samba.conf. If that file could include both options{}
statements and zone statements then we'd be all set.

That would make it possible for distro upgrade to sanely change bind
options for Samba without administrator intervention.

 > >>  5) finally, I'd like to support calling out to an external helper for
 > >>  making dynamic update decisions.
 > ...
 > This has not yet been implemented either?  We can always insert it later.

right. As we discussed today, I'm now thinking of something like this

update-policy {
	grant external "local:/var/samba/bind-auth.sock" A AAAA CNAME;

so bind9 would apply all its current checks, including the gssapi
checks it does against the keytab specified in tkey-gssapi-keytab, but
with the above it would then send the request to the specified unix
domain socket, along with a 64 bit identifier. It would expect a reply
giving the identifier and a ISC result code.

I'll see if I can get that implemented over the weekend. To make
things easy I'll probably initially do the socket calls
synchronously, which means the thread will block while this is being
checked. A future patch could make that async.

Samba would then create and listen on /var/samba/bind-auth.sock and
would extract the PAC from the krb5 ticket then apply all the needed
NT ACL checks.

Cheers, Tridge

More information about the bind-workers mailing list