Problems (possibly bug) with dlz for bind 9.9 in 4.0.0beta3-GIT-763f9e8

Trever L. Adams trever.adams at
Mon Jun 25 00:32:39 MDT 2012

Hello Everyone,

This is a clean domain, provisioned post beta1 (I think beta2). I have not been able to get Windows PCs to do DNS updates. A bit about my network. Every machine has at least one private IPv4 address, one private IPv6 address (fdXX below), and one publicly route-able IPv6 address. When I first mentioned this problem in another bug there was a screw up in my delegation of reverse zones and a few other left overs from some other setups. These are completely cleared out. There are no strange forwards or messed up delegations now and everything is showing up as coming from the client machine (such as the one below, a full log would show this repeated exactly with a 2001 address as it seems to be trying to update from both). 

The only log that seems to have anything to do with this is from (on a Fedora 17 box). This is with -d 9 or -d 10 on the command line starting Samba 4. If there is something I can do to get DLZ debug info out of Samba or more info out of bind, I am willing to try.

samba_dlz: starting transaction on zone
client fdXX:XXXX#59870: updating zone
'': prerequisites are OK
client fdXX:XXXX#59870: update
'' denied
client fdXX:XXXX#59870: updating zone
'': rolling back
samba_dlz: cancelling transaction on zone
client fdXX:XXXX#59870: send
client fdXX:XXXX#59870: sendto
client fdXX:XXXX#59870: senddone
client fdXX:XXXX#59870: next
client fdXX:XXXX#59870: ns_client_detach: ref = 0
client fdXX:XXXX#59870: endrequest
client @0x7f37441118b0: udprecv
client fdXX:XXXX#61302: new TCP connection
client fdXX:XXXX#61302: replace
clientmgr @0x7f3744105b40: get client
clientmgr @0x7f3744105b40: recycle
client fdXX:XXXX#61302: read
client fdXX:XXXX#61302: TCP request
client fdXX:XXXX#61302: using view '_default'
client fdXX:XXXX#61302: request is not signed
client fdXX:XXXX#61302: recursion available
client fdXX:XXXX#61302: query
failed gss_inquire_cred: GSSAPI error: Major = Unspecified GSS failure. 
Minor code may provide more information, Minor = Success.
gss-api source name (accept) is somepc$@EXAMPLE.ORG
process_gsstkey(): dns_tsigerror_noerror
client fdXX:XXXX#61302
(1320-ms-7.5-12a5b1.0c80fb65-bc02-11e1-15b4-0018f34ced22): send
client fdXX:XXXX#61302
(1320-ms-7.5-12a5b1.0c80fb65-bc02-11e1-15b4-0018f34ced22): sendto
client fdXX:XXXX#61302
(1320-ms-7.5-12a5b1.0c80fb65-bc02-11e1-15b4-0018f34ced22): senddone
client fdXX:XXXX#61302
(1320-ms-7.5-12a5b1.0c80fb65-bc02-11e1-15b4-0018f34ced22): next
client fdXX:XXXX#61302
(1320-ms-7.5-12a5b1.0c80fb65-bc02-11e1-15b4-0018f34ced22): endrequest
client fdXX:XXXX#61302: read
client @0x7f374411fc30: accept
client fdXX:XXXX#61302: next
client fdXX:XXXX#61302: request failed: end
of file
client fdXX:XXXX#61302: endrequest
client fdXX:XXXX#61302: closetcp

The only other log that is showing anything shows up even on the Samba4 DC doing its self updates for DNS (which work) is the following (which souldn't matter as I have selinux set to permissive, so it shouldn't affect anything):
Shouldn't matter as set to permissive but:
Jun 21 18:54:28  PC kernel: [35072.923310] type=1400 audit(1340326468.958:54): avc:  denied  { getattr } for  pid=5989 comm="named" path="/usr/local/samba/private/dns/sam.ldb" dev="dm-0" ino=534632 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file

Why is it showing a failed GSSAPI when it was actually successful (and the Samba log seems to say it was as well)?

Any help in resolving this would be greatly appreciated. It is one of what seems to be two problems that keep me from using S4 for several setups.

Thank you,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list