Re: DHCP - DynDNS Interaction

[Shawn Mamros <[e-mail]>]

>One of the issues raised during my presentation on the interaction
>between DHCP and DynDNS Updates was the ability to expire individual
>RRs.  As was observed, at the present momement DynDNS has no mechanisms
>by which an entity that originates a DNS update could convey to a DNS
>server the expiration time for the RRs that are updated.
[...]
>So, the only open issue is how to deal with a situation where a DHCP
>client is responsible for updating its A RRs. Moreover, the problem
>would occur only if the client would not be able to update (delete) its
>A RR when the lease expires (this could happen if the client is turned
>off at this moment). In this case it could be possible that the
>client's FQDN would be associated with an IP address of some other
>host. Observe that this would matter only when some other host
>would try to contact the client (e.g., the client has some server
>application).

It's actually a little bit worse than that.  Even if the client is
up and running when its lease expires (and it hasn't been able to
renew its lease one way or another), specifically when should it delete
its A RR?  It can't do it after the expiration time, because at that
point it can no longer safely use its IP address, and without that
you can't actually do the DynDNS exchange.  That means you'd have to
delete the A RR before lease expiration time, but how much time should
one allow beforehand?  There isn't really any one "right" value...

>I'd like to get an input from the DHC WG members whether the WG would
>insist on requiring DynDNS Updates to provide a mechanism to convey the
>expiration time (DynDNS doesn't have such a mechanism at the present
>moment), or whether the WG would agree that I would document in the
>DHCP-DynDNS Internet Draft the (potential) limitations imposed by the 
>absence of such a mechanism in DynDNS, and we'll live with the limitations.

I'd prefer the latter (document the limitations).  That may seem like
a contradiction of what I stated above - arguably, having the RR expire
on its own would potentially solve that problem - but I have a few reasons
to prefer not to do so.

First, I'm starting to believe that the case where the client will "own"
the A RR, while useful in some cases, will not be all that common in
practice.  In the case of a "roving laptop" (my favorite one :-), I'm
beginning to feel that it would probably be better to use Mobile IP (with
DHCP being used only to obtain an address on the foreign net), and thus
there won't be a need to update the A RR "back home" - that will stay
at the home address.

Second, if RRs did have expiration times, that means the client or server
would have to update that expiration time every time the lease is renewed.
In my experience, lease renewals happen far more frequently than do lease
expirations, and I'd prefer minimizing the number of times I have to do
DynDNS.

Lastly, and perhaps most important, I'd like to see DynDNS move forward
ASAP, and it's my impression that trying to add per-RR expiration at this
late date is only going to delay things.

-Shawn Mamros
E-mail to: [e-mail]