"Scavenging" DDNS records

[W.J.M. Nelis]

Will Lists wrote:
> (I am going to post this individually to both the BIND and DHCP lists 
> as this crosses both, but not going to cross-post).
>
>
> DHCPD 4.1-ESV-R3 & BIND 9.7.4
>
> We've got about 20 /20 networks and another few /24 networks (all 
> within the 10/8 block) that are setup for approximately 50% of their 
> total ranges to be DHCP.  There is single forward lookup zone involved.
>
> The network is fairly busy, but not as busy say as a college or 
> someplace where thousands or tens of thousands of people are coming 
> and each day and getting DHCP.  All leases are set for 8 days and the 
> standard options for update forwarding, update allow, etc. are set. 
>  Clients are not allowed to perform updates directly.
>
> The issue that I am seeing is that about 2-3% of the time, when a DHCP 
> lease expires, some or all of the DNS records are not removed. 
>  Sometimes it's just the A records, sometimes it's the A & TXT record, 
> sometimes it is all of them (A, TXT & PTR).  If I am slacking on 
> checking and cleaning this up, the stale records might be there 2-3 
> months later still.
>
> We migrated some time back from Windows DNS & DHCP, so we got used to 
> having the Windows implementation where it would scavenge old records 
> that were still in existence, but past their maximum lifetime without 
> having been updated (i.e. lease expired + X days).  There doesn't 
> appear an equivalent functionality in the ISC codebase, so I was 
> considering writing my own script to try and tackle this as it's a 
> rather annoying issue to be continually cleaning up old records using 
> nsupdate as root.
>
> A few questions:
>
> - Does anyone have any suggestions on what to look at or try to figure 
> out what is going wrong this 2-3% of the time?
>
> - Does anyone know how to actually perform the DHCID hash function? 
>  I've read all the RFCs and looked at the DHCPD source code and I'm 
> not seeing it.  I'd need to be able to determine the hash value for a 
> record to see if it actually belongs to the "expired" host or not.  (I 
> think I need to perform this).
>
>  - Does anyone know of any sort of effort/project already out there 
> that is looking towards this scavenging?
>
> My thoughts on what the process might look like (still rough and 
> obviously untested):
>
> 1.  Find an expired lease in the dhcpd.leases file.
> 2.  Get the IP address.
> 3.  Perform a reverse lookup on the IP to get the PTR record (this may 
> be problematic though since the PTR is not always there).
> 4.  Do a forward lookup to the get A and TXT records.
> 5.  Do a hash calculation.
> 6.  Compare to the TXT record to be sure this is the right record we 
> are about to delete.
> 7.  If a match, use nsupdate to delete all applicable "expired" 
> records.  If not a match then don't do anything.
Perhaps you should not focus about what should be removed from DNS but 
what should be in DNS. If you have authoritative sources of [Name,IP] 
pairs outside DNS, you can make DNS to contain only that information. 
Over here, there are two sources for [Name,IP] pairs: the configuration 
database and the ISC DHCP leases files. Periodically  a script is run to 
make sure that this information is available in DNS. At the same time, 
it will remove all other information from DNS.

  Wim Nelis.




******************************************************************************************************************

The NLR disclaimer is valid for NLR e-mail messages.

This message is only meant for providing information. Nothing in this e-mail message amounts to a contractual
or legal commitment on the part of the sender.
This message may contain information that is not intended for you. If you are not the addressee or if this
message was sent to you by mistake, you are requested to inform the sender and delete the message.
Sender accepts no liability for damage of any kind resulting from the risks inherent in the electronic
transmission of messages.
 
******************************************************************************************************************