gss-tsig updates where realm != zone

[David Monro]

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.k...@KRB5.REALM able to update machine.dns.domain,
although the latter isn't vital. (I'm assuming
host/machine.d...@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

[Mark Andrews]

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=vdND...@mail.gmail.com>

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[David Monro]

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