Hi Michal, glad to read You!
On Tue, Aug 26, 2025 at 08:50:51AM +0200, Michał Kępień wrote: ! 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. That didn't work with -u. But then there is not much there. From startup: [40225] 1756199989.073195: Retrieving DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success [40225] 1756199989.073196: Retrieving DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success From nsupdate: [40225] 1756200019.785565: Retrieving DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23 from FILE:/etc/krb5.keytab (vno 1, enctype aes256-cts) with result: 0/Success [40225] 1756200019.785566: Decrypted AP-REQ with specified server principal DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23: aes256-cts/1E28 [40225] 1756200019.785567: AP-REQ ticket: ppp@OUTRA.PHASE23 -> DNS/conr-e.intra.daemon.contact@OUTRA.PHASE23, session key aes256-cts/775D Curious: what would be the next thing it reports when it happens to work successfully? ! > 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? With a TGT from kinit, or from kinit -S # KRB5_CONFIG=/usr/local/etc/krb5.conf /usr/local/bin/kinit -F -t ./krb5.keytab -c /tmp/krb5cc_nsupdate ppp keytab specified, forcing -k # KRB5_CONFIG=/usr/local/etc/krb5.conf KRB5CCNAME=/tmp/krb5cc_nsupdate nsupdate -g -d -D setup_system() reset_system() user_interaction() > prereq nxrrset outbound.dyn.daemon.contact IN A do_next_command() evaluate_prereq() make_prereq() > update add outbound.dyn.daemon.contact 150 IN A 92.1.1.1 do_next_command() evaluate_update() update_addordelete() > send do_next_command() start_update() recvsoa() About to create rcvmsg show_message() Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50874 ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;outbound.dyn.daemon.contact. IN SOA ;; AUTHORITY SECTION: dyn.daemon.contact. 3600 IN SOA conr-e.intra.daemon.contact. admin.admn.intra.daemon.contact. 20208572 3600 900 3600000 3600 Found zone name: dyn.daemon.contact The primary is: conr-e.intra.daemon.contact start_gssrequest Found realm from ticket: OUTRA.PHASE23 send_gssrequest show_message() Outgoing update query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41256 ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;546671530.sig-conr-e.intra.daemon.contact. ANY TKEY ;; ADDITIONAL SECTION: 546671530.sig-conr-e.intra.daemon.contact. 0 ANY TKEY gss-tsig. 1756200640 1756200640 3 NOERROR 872 YIIDZAYGKwYBBQUCoIIDWDCCA1SgDTALBgkqhkiG9xIBAgKiggNBBIID PWCCAzkGCSqGSIb3EgECAgEAboIDKDCCAySgAwIBBaEDAgEOogcDBQAg AAAAo4ICPGGCAjgwggI0oAMCAQWhDxsNT1VUUkEuUEhBU0UyM6ItMCug AwIBAaEkMCIbA0ROUxsbY29uci1lLmludHJhLmRhZW1vbi5jb250YWN0 o4IB6zCCAeegAwIBEqEDAgEBooIB2QSCAdVkq7oSRPcSy2yWdGv7MEcX xS0TSWbepPRir5PjNlwwOBiKFaZ4ydA9APvUyK/3A/Rw/AXG7K371Hq5 5YjRUj9JiDCBTNuVA8Xhs1W/lZf1E6J3BAcHHNBfi4yzk5p2zRHrOO2O QyGp6NVUzQHA1zITtHcHZ8TRkgCK0L4ze1udEarWg9nRd+EkmGp7NDvC MQkOxWTkc4MovZ1t+aPXQ0iWmb2LbFwUXzubuBQl+Yx/PIKVcECuWivA inyUJJ86aaMVitjaVVBBG3d6w5AoK9EDzfdLRG9R/Wsw+1jkWw2uHYNl tLTTAv+rjxD/kOt1A0MjoBfU5fo/SWd7Cfpav7pLSuTra6i7XYa7z3SU KSSgZ+hGivpCqDLK65Cksh0+pdOxGaO/C1OiQv+8CHRlASn+JltJmdat niKkwnLTOrju59YwZzmyhRuMf1FM5N6Nsy97ygHXgRuyagFtsDTfIs4E 16QcsfreMOxNIKy0c3wrB5gQUfhoYfcIZ0fGzTjTxKKb0JPb1+mw4oVS kCaX4nfyouPIMK+EWvQAdWdN4GcPvVGQp6vaN8Ueg/SJe+Dxdc4NXDOd lYKFaaj1WHyKcfzgC00c+3QaGP/dz6HxhjlgzQI+8H/jpIHOMIHLoAMC ARKigcMEgcAUNcc60MKrmU1KQqvl+i8tuspOw3lri0wFbqLcVbuqcoby t3hJpPkdlqS/7Hado7MMgGpIl3yqblVbwrKztJfJtwpfk2AVcE3Ao77A Mcf1/7E7m6t3WJdlh/REZVEhV3OyGieBJ8W8Z8KBD3sLUKqI65aSROnI LU4mnIXgIIO1ZGEKMeFTNv8B8ld5MzD078Pgs6InrtfOZTzX2h95NwWZ 6eq47j8BDTEp5uTBEpGh13Yr5sunoYRQZQSw9VkK264= 0 Out of recvsoa recvgss() recvgss creating rcvmsg show_message() recvmsg reply from GSS-TSIG query ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41256 ;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;546671530.sig-conr-e.intra.daemon.contact. ANY TKEY ;; ANSWER SECTION: 546671530.sig-conr-e.intra.daemon.contact. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0 0 dns_tkey_gssnegotiate: TKEY is unacceptable ----------------------------- ! > 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. Well then an empty file might be normal - didn't know that. It did complain at first that it cannot write it - /var/tmp didn't exist in the chroot. Then I was wondering about the empty file. ! > 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. It certainly provides a couple of additional red herrings... ! So far, I have not spotted anything wrong with BIND 9 per se based on Me neither. What I've seen done wrong with other krb5 interfaces is pointer dereference mistakes - and they can go undetected, because it may work the first time, may work a dozen times, and then it starts to behave weird - and one rarely runs the same context a dozen times. But this here looks a bit different. ! 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. It certainly isn't. Most likely the blame will be on me for doing things a litte more crazy than others. And tests can only check for crazyness we have somehow seen before... I'm fond of your work on issue 4436, btw, and it happend to warn me to not just push 14.3 out onto my public servers rightaway. Thank You! best regards, Peter -- 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
