GSS-TSIG requires a TKEY exchange to generate a TSIG key which is used to sign
the UPDATE message.
Forwarding does not generally make sense with GSS-TSIG because to complete the
TKEY exchange
the master and the client need to be able to communicate directly. In theory
you could send
a UPDATE to a slave and forward that *after* establishing the TSIG with the
master directly.
named supports forwarding of TSIG and SIG(0) signed update messages. The later
requires this
fix on the forwarding server.
3961. [bug] Forwarding of SIG(0) signed UPDATE messages failed with
BADSIG. [RT #37216]
The fix preserves the transaction ID when forwarding the SIG(0) signed message.
Mark
> On 4 Feb 2020, at 15:47, Matthew Davis <[email protected]> wrote:
>
> Greetings.
>
> Please excuse this re-posting. My initial messages was inadvertently
> marked as SPAM by my MTA.
> I need some guidance on how configure dynamic dns updates forwarding when
> using tsig-gss (kerberos) authentication. I have successfully setup tsig-gss
> authentication when updating the master directly. I have the need to have
> the client send the update to a slave that then forwards the update to the
> master.
>
> The design is the master, slaves, and clients are all part of the same
> kerberos realm. The master has a service keytab of DNS/<master.fqdn>@REALM
> defined for bind. Each client has the host keytab of
> host/<client.fqdn>@REALM. On the slave I have tried 3 different service
> keytab combinations in for bind configuration.
>
> • DNS/<slave.fqdn>@REALM only
> • DNS/<slave.fqdn>@REALM and DNS/<master.fqdn>@REALM
> • DNS/<master.fqdn@REALM> only
> The clients can update their own records successfully when connecting
> directly with the master. With slave bind keytab only contain the its own
> service keytab, the client and slave will not exchange information. When I
> added the master keytab entry on the slave, the slave attempts to forward the
> request to the master. However the update fails. The logs on the slave
> indicate the following:
> named[15934]: client <client.ip.address>#45780/key
> host/client.my.zone\@REALM: signer "host/client.my.zone\@REALM" approved
> named[15934]: client <client.ip.address>#45780/key
> host/client.my.zone\@REALM: forwarding update for zone 'my.zone/IN'
> named[15934]: zone my.zone/IN: forwarding dynamic update: unexpected
> response: master <master.ip.address>#53 returned: NOTAUTH
>
> The master logs the following:
> named[17809]: client <slave.ip.addres>#48733: request has invalid signature:
> TSIG 1114672902.sig-<master.fqdn>: tsig verify failure (BADKEY)
>
>
> The update policy for the zone on the master is:
>
> update-policy {
> grant REALM krb5-self * SSHFP;
> };
> I suspect I simply do not have the correct keytab combinations. I am unclear
> what the correct combination would be.
> --
> Matthew Davis
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> [email protected]
> 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: [email protected]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
