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 configurable? * 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 technically possible...) * 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 before? Cheers David 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: > external: > 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. > > Mark > > In message > <CAOZCCZjjWRTLvmVkZDhA+Mo+=P-oDD+0PNmCeLZq=vdndgj...@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@KRB5.REALM able to update machine.dns.domain, >> although the latter isn't vital. (I'm assuming >> host/machine.dns.domain@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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >> from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
