Hi
I have never done this and also don't have any practical experience with it, but I could imagine that it could work something like this.
1) In the Internet there is a DynDNS server which keeps a record of the present IP address assigned to a URL (eg.
www.mywebsite.org). The server 'knows' that the IP address is 232.212.334.23 (for example). It known that because the owner of the URL has registered the URL and so the DynDNS server acts as a DNS in the Internet to inform where to send connectiosn to when the URL is to be conntacted.
2) Users of DynDNS don't have fixed IP addresses (otherwise standard DNS will work). Therefore the user must inform the DynDNS server each time its IP address changes so that it can again inform correctly where the URL is. The IP address may be changing because the address is assigned by DHCP and changes sometimes after its lease times out. Or the system could be physically changing locations.
3) A DynDNS client must therefore know how to contact the DynDNS server (I don't know what protocol is used but I assume that it is TCP based and it needs to be able to establish a connection to the DDNS server via its URL or fixed IP address). It must also know how to inform the DDNS server of new details - presumably this is also standardised in the protocol.
4) When the client updates details may be more system specific. It may receive the lease IP address directly and so will be able to trigger the update when the details change. However the client controlling this may be beind a gateway and so doesn't receive any information directly about such changes. This may then require the client to do extra work - eg. poll the details of the gateway (may be quite specific for the gateway used).
5) In the case of gateways being used it also seems more logical that the gateway included the DDNS client. I wonder whether such operation is standard in many gateways?
Regards
Mark
