gss-tsig updates where realm != zone
davidm at davidmonro.net
Wed May 30 15:55:47 UTC 2012
OK, I've built myself a bind 9.8.3 setup so I can use the 'external'
update-policy. It seems there are a few details not fully described in
the 9.8.3 ARM :) I did have a bit of a look at the list archives but I
couldn't find anything which immediately answered my questions...
* If the external daemon blocks (eg reads the data from bind, but never
writes anything back to the pipe), I think it causes bind itself to
block? (certainly it didn't seem to answer queries any more). Is there a
timeout where it considers the daemon dead and gives up on it? Is that
* The signer string seems to have '\' characters before (at least) '$'
and '@' characters. Is this expected? What other characters get escaped?
* At least on my build, the TCP source address field always seems to be
empty. Is that expected or did I screw something up?
* The example perl script sends back a '2' in the event that it doesn't
like the request from bind. This isn't documented as being valid.
* As far as I can see the daemon gets handed the name and rdata type of
the record the client is trying to modify, but doesn't get told what
type of operation the client is attempting (create, delete, whatever),
or the data the client is attempting to insert into the record. The
latter would potentially be useful - for example preventing clients
registering A records with addresses outside my network (I've seen
machines attempt to register an A record where the IP address was
attached to a 3G dongle which happened to be plugged into the machine at
the time). Would this be a worthwhile enhancement? (assuming it is
* Do the 'name' and 'type' field of the update-policy get ignored for
the extern nametype? I understand that the name field doesn't
necessarily make sense (although I guess it might be useful to just send
it to the daemon as another string), but I was a bit surprised to be
able to update AAAA records when I only had A in the type field.
Oh, and finally - my Vista test box appears to try and register AAAA
records first, and if I deny the AAAA types, it never actually bothers
trying to register A records. Is this behaviour other people have seen
On 29/05/12 23:38, Mark Andrews wrote:
> 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 mail.gmail.com>
> , 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?
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>> bind-users mailing list
>> bind-users at lists.isc.org
More information about the bind-users