DynDns Update module?

vining

Does anyone have this working still? I haven't used this in a long time since the routers I supply usually handles this but now on one job the owner changed my router to one that doesn't provide the dyndns update so now I putting the module in but it doesn't seem to be working. I'm not getting anything back but it does trigger the string event handler. I tried switching from port 80 to 8245 the secondary port for the HTTP socket that dyndns uses but the exact same thing. I connect, send my get header but nothing is returned or shows in my buffer but the string event triggers.

nickm

I've moved to Namecheap DDNS and update from an (unencrypted) HTTP GET request. Not the most secure, but works.

vining

I'd rather not migrate to another provider unless necessary and quite frankly this isn't that necessary. Currently I have a block of 30 dyndns accounts so I'd prefer not switching and for this one customer who sabotaged their own system I would just leave it as they got what they deserved but be that as it may I'd still like to know why this code isn't working and before I invest more time it's always nice to know that it can work as it once did and dyndns hasn't changed their API. The API I get now from them is basically the same and it clearly implies that both HTTP and HTTPS are still supported.

It could be I'm blocked now since I did read that frequent requests will result in blockage since they don't want see frequent updates where the IP is the same. I would hope if the blocked the client IP they would respond with a blocked notice.

ericmedley

vining wrote: »

I'd rather not migrate to another provider unless necessary and quite frankly this isn't that necessary. Currently I have a block of 30 dyndns accounts so I'd prefer not switching and for this one customer who sabotaged their own system I would just leave it as they got what they deserved but be that as it may I'd still like to know why this code isn't working and before I invest more time it's always nice to know that it can work as it once did and dyndns hasn't changed their API. The API I get now from them is basically the same and it clearly implies that both HTTP and HTTPS are still supported.

It could be I'm blocked now since I did read that frequent requests will result in blockage since they don't want see frequent updates where the IP is the same. I would hope if the blocked the client IP they would respond with a blocked notice.

Vining; another thing you might want to check is your HTML header information. I don't know if you're like me - but I don't update that hardly at all. but, I've had to do so in recent projects where RSS feeds end up blocking chatty things with seeming older browser identifications. When I updated the GET message to something I just scraped off my current IE or Chrome browser all seems well again. Just a thought you might look at.
E

vining

ericmedley wrote: »

Vining; another thing you might want to check is your HTML header information. I don't know if you're like me - but I don't update that hardly at all. but, I've had to do so in recent projects where RSS feeds end up blocking chatty things with seeming older browser identifications. When I updated the GET message to something I just scraped off my current IE or Chrome browser all seems well again. Just a thought you might look at.
E

I got a completely different URL command syntax from DYN that I'm working with now but I'm hoping they come back with a RAW http version like they had. Using the new syntax I put it in my browser and watch with wireshark and updated my header to what my browser used and now I get a HTTP 200 OK header returned but no payload like I get in the web browser. That send a "good" and the IP address used to update ddns. I'm close and maybe just missing a negotion exchange in my wire shark intercepts. Hopefully Dyn will fet back to me tomorrow with a new API cuz what they gave me today doesn't match what they have published online.

ericmedley

vining wrote: »

I got a completely different URL command syntax from DYN that I'm working with now but I'm hoping they come back with a RAW http version like they had. Using the new syntax I put it in my browser and watch with wireshark and updated my header to what my browser used and now I get a HTTP 200 OK header returned but no payload like I get in the web browser. That send a "good" and the IP address used to update ddns. I'm close and maybe just missing a negotion exchange in my wire shark intercepts. Hopefully Dyn will fet back to me tomorrow with a new API cuz what they gave me today doesn't match what they have published online.

Oh! Imagine that! The API doesn't match reality. It'll never happen.

vining

Well DYN wasn't very helpful but I did get this resolved.

First they sent me this URL command method which is different form their online URL method.

[URL]http://username:password@members.dyndns.org/v3/update?hostname=example.example.com&myip=x.x.x.x[/URL]

Not what I wanted but it gave me something to work with and eventually used this to modify the RAW command format. A bit of a pain since sometimes servers are blocking and sometimes they're not and if you send them garbage a couple of times they'll block you and you have no way of knowing that's the problem and not you code syntax. So using wireshark I was able to use the GET format for the above URL command that send user:pass in the URL to the RAW format that uses the basic encrypted base 64 in the header and eventually it works.

I really didn't need to bother with this but I haven't played with code in a while and it is a tease that junkies find irresistible.

This is what I sent to DYN and hopefully they'll update their web page, yeah right, but the last version in the quote section below seems to work properly at present.

This is what your current online API gives for a RAW http connection:

GET /nic/update?hostname=yourhostname&myip=ipaddress&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG HTTP/1.0
Host: members.dyndns.org
Authorization: Basic base-64-authorization
User-Agent: Company - Device - Version Number

Which is slightly different from what it used to be when my code was originally written.

GET /nic/update?service=username&hostname=yourhostname&myip=ipaddress HTTP/1.0
Host: members.dyndns.org
Authorization: Basic base-64-authorization
User-Agent: Company - Device - Version Number

This is what works now:

GET /v3/update?hostname=yourhostname &myip=ipaddress HTTP/1.1
Host: members.dyndns.org
Authorization: Basic base-64-authorization
User-Agent: Company - Device - Version Number

It doesn't help that sometimes it seems the server blocks you even when using the test accounts. So the changes in the GET request syntax and using HTTP/1.1 while connecting to a server that wasn't blocking I was able to get proper responses.

Might want to consider updating this DYN web page.

https://help.dyn.com/remote-access-api/perform-update/

vining

I also learned something else in this process. If you go to your account setting at DYN there's a client updater key that you can use instead of your account password for updates which means you can use this key in your code in place of your password. Why? Because this key only works for updating clients where as the password also allows you access to your web account so if you putting this in code that others may have access to, maybe by people who someday take over your systems, these people won't be able to log into your account and screw things up for other accounts.