gss-tsig updates where realm != zone

Mark Andrews marka at
Tue May 29 14:08:54 UTC 2012

If you need a different mapping then use "external" to do a customised
mapping from kerberos identity to the dns identity.  ms-* and krb5-*
assume a standard mapping.

>From ARM:
This rule allows named to defer the decision of whether to allow a given update to an external daemon.

The method of communicating with the daemon is specified in the identity field, the format of which is "local:path", where path is the location of a UNIX-domain socket. (Currently, "local" is the only supported mechanism.)

Requests to the external daemon are sent over the UNIX-domain socket as datagrams with the following format:

   Protocol version number (4 bytes, network byte order, currently 1)
   Request length (4 bytes, network byte order)
   Signer (null-terminated string)
   Name (null-terminated string)
   TCP source address (null-terminated string)
   Rdata type (null-terminated string)
   Key (null-terminated string)
   TKEY token length (4 bytes, network byte order)
   TKEY token (remainder of packet)
The daemon replies with a four-byte value in network byte order, containing either 0 or 1; 0 indicates that the specified update is not permitted, and 1 indicates that it is.


In message <CAOZCCZjjWRTLvmVkZDhA+Mo+=P-oDD+0PNmCeLZq=vdNDGJrTg at>
, David Monro writes:
> Disclaimer: I'm new to trying gss-tsig as an update method, so it is
> entirely possible I'm doing something completely stupid.
> I'm using bind 9.7.3 (because it ships with RedHat 6), with an Active
> Directory as the kerberos infrastructure.
> If I use the following update-policy:
> grant * subdomain my.dns.domain ANY;
> then it works (both for nsupdate -g and with a windows client using
> windows native methods); however this means anyone with a kerberos
> ticket (including a user ticket!) can register anything they like into
> the domain.
> I've tried all sorts of tests with the ms-self, ms-subdomain,
> krb5-self and krb5-subdomain nametypes, and they all seem to fail. I
> suspect this is because  my.dns.domain is not the same as my kerberos
> realm (and I can't make it the same, as I really can't go messing with
> the zone which does match the realm). They all fail with REFUSED (not
> BADKEY, the checking of credentials all seems to work fine).
> The documentation for these nametypes does seem to be rather sparse,
> so I'm not really sure what the syntax should be. What I was hoping
> for is a way of having MACHINE$@KRB5.REALM able to update
> machine.dns.domain, and preferably also
> host/machine.krb5.realm at KRB5.REALM able to update machine.dns.domain,
> although the latter isn't vital. (I'm assuming
> host/machine.dns.domain at KRB5.REALM would work, but I'm not sure that
> is actually useful, and certainly won't work for the windows clients).
> Is this possible?
> Cheers
> David
> _______________________________________________
> Please visit to unsubscribe
>  from this list
> bind-users mailing list
> bind-users at
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at

More information about the bind-users mailing list