Hi Peter, > This is the error: > --------------------------------------------- > recvmsg reply from GSS-TSIG query > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4885 > ;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;3478577972.sig-conr-e.intra.daemon.contact. ANY TKEY > > ;; ANSWER SECTION: > 3478577972.sig-conr-e.intra.daemon.contact. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY > 0 0 > > dns_tkey_gssnegotiate: TKEY is unacceptable > --------------------------------------------- > With debugging the server reports this: > > client @0x1fd41731b090 fd00::4202#19192 > (3656045201.sig-conr-e.intra.daemon.contact): view intra: query: > 3656045201.sig-conr-e.intra.daemon.contact ANY TKEY -T (fd00::4202) > failed gss_inquire_cred: GSSAPI error: Major = No credentials were > supplied, or the credentials were unavailable or inaccessible, > Minor = No Kerberos credentials available (default cache: > FILE:/tmp/krb5cc_53). > failed gss_accept_sec_context: GSSAPI error: Major = Unspecified GSS > failure. Minor code may provide more information, Minor = > Cryptosystem internal error. > process_gsstkey(): dns_tsigerror_badkey
So it looks like krb5 is unable to process the initial GSS-API token sent by nsupdate - something inside krb5 returns the KRB5_CRYPTO_INTERNAL error code. Could you perhaps start named with the KRB5_TRACE environment variable set to a file path of your choosing and then paste the contents of that file after a failed nsupdate run? It might shed some light on what krb5 is trying to do and/or what specifically fails. > I have removed the "tkey-gssapi-credential" option due to another > recommendation, so the only relevant configuration is now > tkey-gssapi-keytab "/etc/krb5-named.keytab"; > > And that one contain the correct cred, both in root and chroot: > ktutil: rkt /var/named/etc/krb5-named.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 1 DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 > > When nsupdate is invoked, it obtains that same cred. How? Could you please paste (or link to) a full debug log of a failed nsupdate invocation? > Inside the server I did follow the proceedings via > process_gsstkey() -> dst_gssapi_acceptctx() -> > gss_accept_sec_context() > which returns GSS_S_FAILURE > > For strange reasons the krb5 tries to create an rcache (but it does > not try to connect the kerberos server): > root@conr:/var/named/etc # ls -l /var/named/var/tmp/ > total 1 > -rw------- 1 bind wheel 0 Aug 25 20:51 krb5_53.rcache2 > > Somehow this looks like the krb5 believes to be a (forwarding?) > client, not a server. rcache is a replay cache, not a credential cache. This does not strike me as weird. > When I reinsert the deprecated "tkey-gssapi-credential" option, the > behaviour is significantly different: the empty krb5_53.rcache2 file > is not created, the "No Kerberos credentials available" error does not > appear. Instead I see this during startup: > > acquiring credentials for DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 > acquired accept credentials for DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 > gss cred: "DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23", > GSS_C_ACCEPT, 4294967295 > > However, the "Cryptosystem internal error." does appear all the same. Right, I would not expect "tkey-gssapi-credential" to affect the outcome, but good call checking it anyway. So far, I have not spotted anything wrong with BIND 9 per se based on the output above. We continuously test GSS-TSIG on FreeBSD 14.3 using krb5 [1] (the relevant system tests are "nsupdate" and "tsiggss"), so it cannot be completely broken. [1] see e.g. https://gitlab.isc.org/isc-projects/bind9/-/jobs/6073942 -- Best regards, Michał Kępień -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
