Problem: DNS Update Malfunction
Final update: No, everything is normal. The DNS updating on the client side ISPs is just slower than is needed for the 60 second updates requested by the DynDNS update client. This appears true for both Rogers and Distributel, and likely many other client side ISPs as well. For instance, with Distributel there are two DNS servers listed. One appears to update instantaneously when my host updates DynDNS while the other appears to take longer and preserve the previous IP for untold amounts of time; the result is the need to flush locally cached DNS information from the Pewter (client testbed laptop) and hope that it talks to the faster updating server the next time it asks for “tin.blogdns.com”. This is consistent with the observations made thus far.
Thus, it makes sense to increase the period of host IP updating to four hours instead of sixty seconds. This has been remarked to enable client-side ISPs to cache the address (DynDNS TTL settings panel, it’s made pretty clear). The final robustness of this setup remains to be seen, but this entry is closed for now.
Update: As it turns out, DynDNS Mac OS X update client is misbehaving on Tin– before I condemn it forever and
shun it from my system, I should probably figure out what I can do about it.
Update: Things still aren’t solved — there are intermittent routing problems that I can’t seem to quell yet. I’ll just have to watch the network for clues.
Update: This is due to a combination of two items. First, the lookupd service running client side on Mac OS X is bad at forgetting former IP addresses even when dynamic DNS services are in play– a manual “lookupd -flushcache” followed by either a reboot or network reconnect is needed before this works again. Second, my router was incorrectly set to only “connect manually” rather than to “connect always”. Both items have been fixed but I’ll have to keep an eye on things.
New problem– something is making it difficult or impossible for Tin to serve up pages some of the time, and I’m not sure what that is. I would do a more comprehensive decomposition of this problem if I had the time, but I don’t– so it looks like I’ll just have to fiddle around with the port forwarding setting.
Ed's Big Plans