mydomain.org resolves to 5.6.7.8 # correct, but misleading, see next lineunsupported is not current, Should be 1.2.3.4 # but unsupported IS 1.2.3.4, and IS current

The status report suggests that the host (which it names as unsupported) does not resolve to the correct IP, but actually the hostname does (eg, ping myhost.mydomain.org resolves to the correct external IP). Oddly, when clicking on DynDNS stat, the log shows a resolution request for the external IP server, but NO resolution request for myhost.mydomain.org, so the DynDNS stat command does not seem to check the DNS A record for myhost.mydomain.org. (Though ping does so.)

I wondered why DynDNS stat listed the domain name mydomain.org in the status report, instead of myhost.mydomain.org? (Ah, I think I may understand a possible reason; maybe because in the original Dyn days, and the like, the hostname and the domain name were very often the same, so it didn't matter whether the A record for domain or host was listed. The strangeness in the status report arises if - for whatever reason - FREESCO is updating the address for a specific host within a domain.)

A third issue with the applet is the behaviour when clicking on 'Update now' in the control panel. In the circumstance when the DNS A record differs from the assigned IP address (I'd set the DNS A rec to 127.0.0.1 again, for testing), update now 'only' checks the IP address (dns resolutions are only shown for resolution of the remote IP service, not for myhost.mydomain.org), and so no update takes place because the external IP does NOT differ from the stored IP. Neither DynDNS stat, nor Update now, seem to be checking the DNS record for myhost.mydomain,org, and allowing an update to proceed whenever the A record differs from the assigned IP. This worries me somewhat because if, for whatever reason, the DNS record and the IP address get out of sync, the DNS record will stay out of sync for as long as the current assigned IP remains current - which could be quite a long time in the absence of ISP or carrier faults or restarts.

Force update did update the A record, but I was definitely worried doing that because I feared it might think it had to change mydomain.org because it had listed that just before declaring unsupported to be incorrect, and so I wasn't completely confident which A record it might try to change.

Do DynDNS stat, and Update now, invoke the dyndns script, but with another parameter to provide the required answers?

Hmmm, a slight over site on my part. Lets try this again because your provider asked for the host name and the domain separately I had to add another variable to the configuration and I then forgot about the system needing to test that URL at a later time. So I have added a second variable to accommodate the domain and put the standard variable back to what it should be. This is all documented in the configuration file. But you will need to download the new scripting and install it.

Executed the instructions, but the 'status' enquiry at the end of the sequence still seems problematic. Additionally, the new cfg file seems to have three entries for domains and hosts. Here are the trial conditions, and the results.

So, I think the status response is still as it was. Recall, though, that the Dyndns client is still 'disabled' and is it possible that 'status' is using unreliable information if 'disabled'?Further, the 'recent log' shows that the dyndns status command did not make any resolution request for myhost.mydomain.org (though the ping request did).

I mentioned that the new cfg file had three entries for domains and hosts, which I filled in as below:

During the time taken to write this message, the revised A record has now propagated. The dyndns status command replies with exactly the same information as posted above, while the ping request is receiving 127.0.0.2 for myhost.mydomain.org. This confirms that the dyndns status command is not checking the DNS record. Nevertheless, when I enable the dyndns client, it should have a real update to do, to set the DNS record to 1.2.3.4. But I'd like to wait to see what we think these results tell us (if anything) before 'enabling' the client to do a real update, so we can be sure we know what the client thinks it ought to be doing.

As an aside, how easy would it be to change the status reply to provide more actual naming for 'unsupported', eg

This would definitely help to confirm 'what' the client was actually checking. Something like this would also help more generally in the 'info log' where the log records only 'unsupported last updated ... ', instead of giving the name into the log. Perhaps something to consider if the in-built client is ever re-released, or the use of 'unsupported' becomes widespread.

That's it. Correcting the DNCNT entry brought it all into life. The status report makes sense.

Final check will be when the ISP changes the IP for some or other reason; since the reticulated power here is so unreliable, I don't think it wil be long.

This approach can be a 'general' solution to the problem of resolving URLs to dynamic IPs, 'IF' someone also has a domain name anyway, and 'IF' that domain name can be managed on DNS systems that accept a machine-based update request. I think that, where this is available, the trend will - increasingly - be towards requiring SSL for the update transactions, so I hope this topic proves useful to other FREESCO users.

I am glad we finally figured it out. I will be working on a variant of the scripting that can be implemented into the system for SHTP secure protocols. It will still need to be customized by the user, but it should be fairly simple.

If you are afraid that you might make a mistake. The chances are high that you will never learn anything.