Re: nsupdate -g always uses master from SOA to form SPN

[Chris Buxton]

Use of a hidden primary makes some sense for external (public) DNS, but IMO not 
for situations where you would want to use GSS-TSIG. So while I would consider 
this a bug, I don’t think it will be tripped often.

BIND does support multiple SPNs on a single server, but you have to change how 
you configure it.

Regards,
Chris Buxton

> On Aug 26, 2021, at 7:32 AM, Magnus Holmgren  
> wrote:
> 
> 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/
> .
> ___
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
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

nsupdate -g always uses master from SOA to form SPN

[Magnus Holmgren]

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/ 
.
___
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