Re: Minor change req for named.iner shirt

[Fred Morris]

I suggest changing it to "953".


Correction: 853.

--

FWM
___
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

Minor change req for named.iner shirt

[Fred Morris]

So I was in public today, and somebody came up to me and asked about the
shirt and we talked about it (properly masked, etc.). He asked "what
does '555' stand for" and I can't say I'd taken particular notice of the
amount showing on the cash register previously. I didn't have a clever
story.

I suggest changing it to "953".

--

Fred Morris

___
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

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