Leases on Dynamic Updates?

[Danny Mayer]

Chris Buxton wrote:
> On Jan 28, 2008, at 8:40 PM, Danny Mayer wrote:
>> Chris Buxton wrote:
>>> The proposal expired almost a year ago. Has it been updated, 
>>> replaced,  or ratified?
>>> It's a good idea, similar to Microsoft's aging and scavenging 
>>> routine.  Optimally, it would be nice if Microsoft and the proposed 
>>> standard  could be brought into line; since MS has been doing this 
>>> now for 8  years or so, I think any proposal should use Microsoft's 
>>> mechanism,  assuming it's not too broken.
>>> However, this is a discussion for a different forum. To answer your  
>>> question, no, BIND does not support the expiring of RR's from  
>>> authoritative data. (Unless I've missed something...)
>>
>> I disagree. The DHCP server owns the lease on the address. It knows 
>> when it expires and is not renewed. Let it perform the DNS cleanup.
> 
> 
> Leaving aside the discussion of non-DHCP dynamic environments (zeroconf 
> and some IPv6 configs) for the moment, yes, the DHCP server knows about 
> the lease. But what if it doesn't know what zone was updated?
> 

How can it not know about the zone? It provides the zone name as part of 
the DHCP service.

> A customer asked us about Microsoft's aging and scavenging system, 
> including having the DHCP server or the client machine performing the 
> updates to forward and reverse zones. After some discussion with them, 
> it became clear that, in their case, Microsoft's default behavior of 
> having the DHCP server handle the PTR record, but having the client 
> handle the A record, makes perfect sense in their case.
> 
> The organization has offices around the world, and each office has a 
> different domain name (e.g. na.parent, eu.parent, etc.), and there may 
> be further divisions below that (fin.na.parent, sales.na.parent, etc.). 
> When a laptop is taken from place to place, its A record must always 
> have the same name, but the reverse zone is site-specific. So rather 
> than have the DHCP server try to figure out which regional domain to 
> update, the client updates the A record.
> 

Are you telling me that the DHCP server does not provide the domain 
name? The one that resides in resolv.conf? In Windows it's in the 
registry under HKLM\SYSTEM\CurrentControlSet\Tcpip\Parameters. Either 
way, when the client unplugs their laptop (or just moves elsewhere in 
the case of wireless) the DHCP is left with a lease with information in 
it about the client. So how hard is it to remove the A or AAAA record?

> On the other hand, updating the PTR records from the DHCP server made 
> perfect sense - it's more reliable, since the DHCP server is unlikely to 
> be unplugged from the network without warning, and the DHCP server can 
> be told what reverse zone to update for leases from a particular "scope" 
> (what MS calls a subnet in DHCP management).
> 

There's no real difference here in removing a PTR record.

> So, to solve the problem of stale A records after a client machine has 
> been suddenly unplugged from the network, Microsoft created an optional 
> age value for dynamic records. I don't remember all the details offhand 
> (I'm more of a BIND tech than an AD tech), but there's an interface to 
> allow an administrator to set an age value for the AD-integrated zone, 
> and the client tells the DNS server to age the record, or something like 
> that. The mechanics from that point are similar to TTL's for cached 
> records (although, in our experience and as reported to us by Microsoft 
> themselves, far less reliable). Of course, every time the client renews 
> the DHCP lease, it also renews the age value of the A record.
> 

Don't be taken in by Microsoft's design. Look how difficult it was for 
them to get the SOA serial number to work correctly with their AD 
multimaster DNS.

Danny