Hey all,
I was looking in my logs and found I was getting the following messages: Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.11#59009: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.11#40670: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#45311: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#57034: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#34192: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY)
It looks like perhaps my DNS keys are bas based on what I have read. However I have no idea how to go about fixing this. Most of what I can find online is for a standard BIND9 server rather than FreeIPA so I am unsure about the directions they give and thought I would put somethin out here for more FreeIPA-specific help.
Thanks in advance!
On ke, 12 kesä 2019, Kristian Petersen via FreeIPA-users wrote:
Hey all,
I was looking in my logs and found I was getting the following messages: Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.11#59009: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.11#40670: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#45311: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#57034: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY) Jun 11 11:55:34 ipa1 named-pkcs11[4370]: client 192.168.105.10#34192: request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure (BADKEY)
It looks like perhaps my DNS keys are bas based on what I have read. However I have no idea how to go about fixing this. Most of what I can find online is for a standard BIND9 server rather than FreeIPA so I am unsure about the directions they give and thought I would put somethin out here for more FreeIPA-specific help.
There is no difference with FreeIPA to what is done on BIND9. There are two separate actors at play:
- access control associated with a record or zone, where a particular authentication method could be mentioned to grant access
- authorization and analysis of the access control entry is performed by BIND9 after bind-dyndb-ldap delivers the record from LDAP to internal BIND9 database.
FreeIPA is transparent to what authentication method you'd specify in the access control. When you don't specify '--update-policy' in 'ipa dnszone-*' commands, they default to
grant ${realm} krb5-self * ${rrtype}
for forward zones and to
grant ${realm} krb5-subdomain ${zone} ${rrtype}
for reverse zones. These are defaults, if you specify '--update-policy' option, you can redefine them as you wish. GSSAPI-based match type is handy because you don't need to distribute keys across IPA masters that run DNS server, they are already there and would rely on KDC/client negotiating service tickets.
However, any other match type (except ms-self/ms-subdomain) can be used as well, given that you do handle key distribution yourself. ms-self/ms-subdomain are impractical for FreeIPA use case because we don't use NetBIOS name style canonical principal names for IPA hosts.
See http://www.zytrax.com/books/dns/ch7/xfer.html#update-policy for details on the whole rule and match types.
krb5-self: This rule takes a Kerberos machine principal (host/QDN@REALM) and allows it to update the DNS entry which corresponds to the QDN part of the Principal. The REALM to be matched must exactly match that specified in identity.
krb5-subdomain: This rule takes a Kerberos machine principal (host/QDN@REALM) and allows it to update the QDN part of the Principal. The REALM to be matched must match that specified in identity or any subdomain (labels to the left) of identity.
freeipa-users@lists.fedorahosted.org