Internal DNS server. Failure, when a client a) registers an IP b) deletes that IP c) registers again
Günter Kukkukk
linux at kukkukk.com
Fri May 31 18:57:15 MDT 2013
Am Freitag, 31. Mai 2013, 14:04:44 schrieb steve:
> On Fri, 2013-05-31 at 09:16 +0200, steve wrote:
> > On Fri, 2013-05-31 at 05:04 +0200, Günter Kukkukk wrote:
> > > I've just started again to work on a DNS failure, which
> > > i called myself "the zombie (Records=0, Children=0)" issue.
> > >
> > > This bug is probably related to bugzilla 9559 and many other
> > > user reports to the samba mailing lists.
> > >
> > > Testcase: Recent git tree
> > > Assuming a valid kinit has been done already.
> > > ------
> > > nsupdate -g
> > >
> > > > update add mytest.intranet01.hom 3600 A 192.168.200.233
> > > > send
> > > > update delete mytest.intranet01.hom A 192.168.200.233
> > > > send
> > > > update add mytest.intranet01.hom 3600 A 192.168.200.233
> > > > send
> > >
> > > ; TSIG error with server: tsig verify failure
> > > update failed: SERVFAIL
> > > ------
> > > The TSIG error should be _ignored_ here atm, it is a different issue.
> > > Many other clients programs will run the same sequence
> > > when updating a record.
> > >
> > > When we now run
> > > samba-tool dns query linux300 intranet01.hom mytest ALL
> > >
> > > Name=, Records=0, Children=0
> > >
> > > This zombie entry _cannot_ be removed by both samba-tool
> > > and any dns requests!
> > > (But samba-tool can be used to a) assign a new IP record again,
> > > and then b) delete it completely)
> > > I've talked to some users which see lots of those zombie records!
> > > Care must been taken cause e.g.
> > >
> > > Name=_msdcs, Records=0, Children=0
> > >
> > > also contains those zero records.
> > > ---------
> > >
> > > I've have prepared a very first patch (see attachment), which
> > > addresses this issue.
> > > Please comment whether this is the right approach.
> > > Sure, the DEBUG() statements - beside one - should be removed.
> > >
> > > With the patch applied all works as expected.
> > >
> > > Comments welcome. :-)
> > >
> > > Cheers, Günter
> >
> > Hi
> > BRILLIANT! I applied the patch. It works but the output from nsupdate is
> >
> > confusing. It still says that there are tsig errors:
> > nsupdate -g
> >
> > > update delete catral.hh3.site 3600 A 192.168.1.21
> > > send
> >
> > ; TSIG error with server: tsig verify failure
> >
> > > update add catral.hh3.site 3600 A 192.168.1.22
> > > send
> >
> > ; TSIG error with server: tsig verify failure
The TSIG error is a different issue we are working on.
The client sends a secured dns update request and the server
handles it correctly internally and _does_ the update, but
then the server is sending a wrong secured response packet
back to client.
This wrong response packet leads to the TSIG error you see.
So atm just ignore it.
Locally I'm already using a (not finished) patch for this
TSIG error problem, so in my above nsupdate sequence the first
two commands run without error.
BUT as you can see in the 3rd failing command:
; TSIG error with server: tsig verify failure
update failed: SERVFAIL
my local patch is not working correctly!
Working on that, too.
> >
> >
> > The DC responds:
> > Tkey handshake completed
> > Terminating connection - 'dns_tcp_call_loop:
> > tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
> > single_terminate: reason[dns_tcp_call_loop: tstream_read_pdu_blob_recv()
> > - NT_STATUS_CONNECTION_DISCONNECTED]
> > Got a dns update request.
> > update count is 1
> >
> > Looking at record:
> > discard_const(update): struct dns_res_rec
> >
> > name : 'catral.hh3.site'
> > rr_type : DNS_QTYPE_A (0x1)
> > rr_class : DNS_QCLASS_NONE (0xFE)
> > ttl : 0x00000000 (0)
> > length : 0x0004 (4)
> > rdata : union dns_rdata(case 0x1)
> > ipv4_record : 192.168.1.21
> > unexpected : DATA_BLOB length=0
> >
> > dns_replace_records: el->num_values == 0 Need to delete!
> > dns_replace_records: DELETE SUCCESS!
> > Terminating connection - 'dns_tcp_call_loop:
> > tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
> > single_terminate: reason[dns_tcp_call_loop: tstream_read_pdu_blob_recv()
> > - NT_STATUS_CONNECTION_DISCONNECTED]
> > Tkey handshake completed
> > Terminating connection - 'dns_tcp_call_loop:
> > tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
> > single_terminate: reason[dns_tcp_call_loop: tstream_read_pdu_blob_recv()
> > - NT_STATUS_CONNECTION_DISCONNECTED]
> > Got a dns update request.
> > update count is 1
> >
> > Looking at record:
> > discard_const(update): struct dns_res_rec
> >
> > name : 'catral.hh3.site'
> > rr_type : DNS_QTYPE_A (0x1)
> > rr_class : DNS_QCLASS_IN (0x1)
> > ttl : 0x00000e10 (3600)
> > length : 0x0004 (4)
> > rdata : union dns_rdata(case 0x1)
> > ipv4_record : 192.168.1.22
> > unexpected : DATA_BLOB length=0
> >
> > And we can see catral.hh3.site
> > ping catral
> > PING catral.hh3.site (192.168.1.22) 56(84) bytes of data.
> > 64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=2.53 ms
> >
> > Question. It only works is there is a root ticket cache on both client
> > and DC. Is that correct?
Can't comment on that atm, sorry.
Here root and user tickets are working - but atm i'm running client and
server on the same machine.
> >
> > Cheers,
> > Steve
>
> I spoke too soon. We can't delete or therefore update any records:
>
That sounds odd. :-(
Are you sure, that this is related to my patch?
Please keep me informed about any new findings.
> samba-tool dns delete hh16 hh3.site oliva A 192.168.1.64
> ERROR(runtime): uncaught exception - (1383, 'WERR_INTERNAL_DB_ERROR')
> File
> "/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/__init__.py",
> line 175, in _run return self.run(*args, **kwargs)
> File
> "/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/dns.py",
> line 1169, in run
> del_rec_buf)
>
> Also it's broken the file server:
> smbclient //oliva/users -Usteve2Enter steve2's password:
> session setup failed: NT_STATUS_NO_TRUST_SAM_ACCOUNT
>
> No one can access the shares. Do I have to reprovision?
> Thanks,
> Steve
Cheers, Günter
More information about the samba-technical
mailing list