Internal DNS server. Failure, when a client a) registers an IP b) deletes that IP c) registers again

[steve]

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 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?

Cheers,
Steve