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
Tue Dec 10 22:12:47 MST 2013


Am 03.12.2013 02:20, schrieb Andrew Bartlett:
> On Tue, 2013-12-03 at 01:45 +0100, Günter Kukkukk wrote:
>> Am 01.12.2013 22:21, schrieb Andrew Bartlett:
>>> 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. :-)
>>>
>>> Just to loop back on this, it turns out not to be the right approach,
>>> nor does it match what Windows dos.  This patch creates 100s and 1000s
>>> of tombstone records in a busy Samba domain, because the records are now
>>> deleted and re-created regularly.
>>>
>>> It appears the correct approach includes using the dnsTombstoned
>>> attribute. 
>>>
>>> Andrew Bartlett
>>>
>>
>> Hi Andrew,
>>
>> sorry, due to other work, i wasn't able to look at samba code for some months - but
>> that might change now (a bit)...  :-)
>>
>> AFAIR - when looking at that code those days - i also had some comparative views
>> on how the DLZ code is doing similar stuff. Don't remember the details, so i might
>> be wrong here.
>>
>> Does the "dnsTombstoned" approach also apply to DLZ ?
> 
> No, it isn't used there.  It appears simply to leave the record with
> just zero entries, which is much the same.  Switching to that seems to
> be the only workaround for now. 
> 
> Andrew Bartlett
> 

Hi Andrew,

afaik about the dns stuff:
   1.) samba-tool dns ... and MS DNS tools use dce/rpc to manage DNS
   2.) ISC nsupdate (-g) and e.g. MS ipconfig /registerdns really _use_ DNS traffic,
       so completely different code paths are used

AFAIK
1.) is working as expected - at least the dns entry is (completely) deleted - no
    longer listed with samba-tool dns query .... @ ALL
2.) both DLZ and internal DNS leave/left a deleted entry as
        Name=, Records=0, Children=0
    (current DLZ still behaves this way)

My patch was just deleting the dns name when the "usage count" went to zero - similar
to 1.) dce/rpc
Probably that was/is not correct - but the internal DNS code was/is not able to modify
such a deleted entry at all - possibly that is buggy and should be corrected?

Anyway - i'm a bit wondering why the 1.) and 2.) codepaths (should) lead to different results,
as can be seen with DLZ today.. handling 1.) vs 2.) ?

I'm aware that an ADS entry isn't removed after it's deleted (tombstone handling).

Cheers, Günter



More information about the samba-technical mailing list