When using GSS-TSIG, nsupdate (with the -g flag) always forms the SPN from the master server specified in the SOA record, rather than the server specified with the server command. Is that really correct behaviour, or should I report this as a bug? I've been scouring the Internet, but couldn't find any prior discussion about this particular situation.
The issue arises when employing a hidden primary, and the server in the SOA record is actually a secondary, which I though was a rather common setup. In this situation, the real primary has to be specified with the server command, and I thought the SPN should represent the service and server being communicated with. I can work around the problem by adding an SPN matching the SOA primary to Kerberos, but AFAIU, BIND can only be configured (tkey-gssapi-credential) to use a single SPN to look up keys in the keytab, so all the SPNs involved have to be aliases of each other, it seems. -- Magnus Holmgren MILLNET AB -- Vid e-postkontakt med Millnet är det normalt att åtminstone vissa personuppgifter sparas om dig. Du kan läsa mer om vilka uppgifter som sparas och hur vi hanterar dem på https://www.millnet.se/integritetspolicy/ <https://www.millnet.se/integritetspolicy/>. _______________________________________________ Please 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
