Posted: Fri Sep 26, 2014 20:37 Post subject: dynamic dns (dnsexit) not working/updating
So when dyndns moved to a paid-only service, I looked around and settled on dnsexit as a replacement solution. I used the wiki entry to set it all up, but I could only get it to actually work by going to the dnsexit site and entering in my IP. My IP got renewed again recently, so I had to go over all that again after having lost access to my home LAN via the dynamic dns I'd been using. The log starts off ok with
Code:
Fri Sep 26 15:21:40 2014: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
But then it gets filled up with entries like the following:
(every half hour). I've checked and re-checked all the entries I put into the relevant fields of my WRT54G, and even copied and pasted straight from the wiki. I've entered my user name and password multiple times to try and ensure that they're correct. But I still get errors and the update seems to fail. Can anyone offer suggestions on how I might get this to finally work? I never had a problem when I was using dyndns.
PS This is Firmware: DD-WRT v24-sp2 (07/27/09) voip, btw.
Ok, let me add a stupid question since I really don't understand terribly well how dd-wrt handles this. The wiki tells me that the line that I am to enter into the URL section of the dd-wrt configuration page is
What should replace your_username and your_password is clear to me, but what, if anything, should come after host= ? I don't quite get that part. So maybe I've made some mistake here.
Incidentally, I don't serve up web pages or anything via dynamic DNS. The only thing I use it for is to access my LAN, mostly via ssh, from remote locations.
DDNS Service: Custom
DYNDNS Server: update.dnsexit.com
Username: xxx
Password: yyy
Hostname: zzz.com
URL: /RemoteUpdate.sv?login=xxx&password=yyy&host=
Additional DDNS Options: --verbose 5 --update_period_sec 43200 --ip_server_name checkip.ns.zerigo.com /
Do not use external ip check: Yes
Force Update Interval: 7
xxx, yyy, zzz.com and nnn.nnn.nnn.nn are of course replacements for my real username, password, hostname and IP.
It checks every 12 hours (--update_period_sec 43200). It forces an update once a week.
Here's the status when it updates:
Fri Sep 26 11:30:18 2014: I:INADYN: IP address for alias 'zzz.com' needs update to 'nnn.nnn.nnn.nn'
Fri Sep 26 11:30:19 2014: DYNDNS my Request:
GET /RemoteUpdate.sv?login=xxx&password=yyy&host=zzz.com HTTP/1.0
Authorization: Basic YWdpbXVsb2dpYzsfX0RO90V4aXRfC0FyZWE3MV9f
Host: update.dnsexit.com
User-Agent: inadyn advanced/1.96-ADV software@stevehorbachuk.com
Fri Sep 26 11:30:19 2014: I:INADYN: Alias 'zzz.com' to IP 'nnn.nnn.nnn.nn' updated successfully.
Fri Sep 26 11:30:19 2014: W:INADYN: DYNDNS Server response:
HTTP/1.1 200 OK
Date: Fri, 26 Sep 2014 18:30:26 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
Content-Type: text/plain; charset=UTF-8
Content-Language: sv
HTTP/1.1 200 OK
1=IP is the same as the IP on the system
I had expected the username and password would be automatically replaced in the URL command. Perhaps there is some keywords that would be replaced automatically, but I couldn't find them. So, entering them in the Username and Password fields seems useless.
It does append the contents of the Hostname field onto the end of the GET parameters. So I didn't need that on the URL.
I added the extra options to show me more messaging, set the update period, and use a different service to check the IP (don't remember why I used that).
This has all been working for some time. I am currently running build 23919 on a D-Link DIR632a.
Thanks for your reply, ZzyzxTek. I had a line something like your -verbose 5 --update_period_sec 43200 --ip_server_name in the additional options field as well. I removed that line in some expierimentation I was doing yesterday and it seemed to resolve something: I got in the log
Code:
Fri Sep 26 18:33:46 2014: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
Fri Sep 26 18:33:56 2014: I:INADYN: IP address for alias 'myuname.linkpc.net' needs update to 'xx.xx.xx.xxx' Fri Sep 26 18:33:56 2014: I:INADYN: Alias 'myuname.linkpc.net' to IP 'xx.xx.xx.xxx' updated successfully.
But when I checked the log again this morning I see
Code:
Fri Sep 26 23:51:21 2014: W: DYNDNS: Error 'RC_IP_CONNECT_FAILED' (0x13) when talking to IP server
Fri Sep 26 23:51:21 2014: W:'RC_IP_CONNECT_FAILED' (0x13) updating the IPs. (it 31)
so something is apparently still not right. I'll go ahead and try your additional DNS options line to see what the results will be. I have the force-update field set, while I'm doing testing, to 1 day, by the way.
Other than that, it looks like my settings are almost the same as yours. The only possible exception might be what you have in the Hostname field: I have in that field myuname.linkpc.net. Is that what should be there?
Other than that, it looks like my settings are almost the same as yours. The only possible exception might be what you have in the Hostname field: I have in that field myuname.linkpc.net. Is that what should be there?
What I have in the Hostname field is the domain name that is set up in DNSExit.
When I log into DNSExit, and I get my Account Overview page, in the Domain List it's the name of the domain listed there.
So, for example, if I have DNSExit providing DNS for mydomain.com that's exactly what I put in the Hostname field in DD-WRT - mydomain.com. In my case, I'm hosting a domain (not with a subdomain), so it's just mydomain.com.
Since you have a subdomain hosted with DNSExit (myuname), I think it's correct to put myuname.linkpc.net in the Hostname field. Sorry, I'm not that much of an expert to know the details there, but I don't think that's what's causing your error (see my next posting).
Last edited by ZzyzxTek on Sat Sep 27, 2014 17:44; edited 1 time in total
But when I checked the log again this morning I see
Code:
Fri Sep 26 23:51:21 2014: W: DYNDNS: Error 'RC_IP_CONNECT_FAILED' (0x13) when talking to IP server
Fri Sep 26 23:51:21 2014: W:'RC_IP_CONNECT_FAILED' (0x13) updating the IPs. (it 31)
so something is apparently still not right.
I didn't exactly recall why I had used --ip_server_name checkip.ns.zerigo.com instead of leaving the IP check alone, but your question tickles a couple of brain cells that are telling me I had to do that to get the IP check to work. I don't think the default IP server check worked, so I used an alternate service at zerigo.com.
When my router does the IP check, I get...
Code:
Fri Sep 26 23:37:34 2014: .Fri Sep 26 23:37:34 2014: W: DYNDNS: My IP address: nnn.nnn.nnn.nn
...whereas you seem to be getting the error message RC_IP_CONNECT_FAILED. If I'm interpreting it all correctly. Try using --ip_server_name checkip.ns.zerigo.com for the IP check and see if that helps.
Thanks again for your input, ZzyzxTek. I've tried your line --verbose 5 --update_period_sec 43200 --ip_server_name checkip.ns.zerigo.com / in Additional DDNS options and all seems to be working well so far: no further error messages in the logs. And I do, like you, get
Code:
Fri Sep 26 23:37:34 2014: .Fri Sep 26 23:37:34 2014: W: DYNDNS: My IP address: nnn.nnn.nnn.nn
in the logs.
Just to clarify, what's happening with that is that the router is confirming, using the URL provided, whether its IP has changed, right? And I suppose if it's different than on the previous check, it triggers an update with dnsexit? Or am I supposed to be checking those logs to determine whether my IP has been changed, manually doing the update with dnsexit?
Just to clarify, what's happening with that is that the router is confirming, using the URL provided, whether its IP has changed, right? And I suppose if it's different than on the previous check, it triggers an update with dnsexit? Or am I supposed to be checking those logs to determine whether my IP has been changed, manually doing the update with dnsexit?
Glad you got it working!
It's all automated - you shouldn't need to check anything or intervene. Mine's been working fine for quite some time and I don't even look at it much any more, unless I update the router firmware or make some other config change just to make sure I didn't break it.
The router calls the service at checkip.ns.zerigo.com and gets back the IP Zerigo detects it was called from. The return looks like (you can put that URL in your browser to see it):
Code:
<ipv4>999.999.999.99</ipv4>
If the router sees the same IP it stored from the last check, it does nothing. If it's different, it calls update.dnsexit.com with the URL Params and new IP to change it.
I'm on Time Warner internet and my IP has never changed since I set all this up, so I've actually never seen an update to a new IP. I just see the updates when I reboot the router or change the DDNS parameters.
I don't recall why I used Zerigo for the IP check - I think I just read a forum posting or DDNS tutorial somewhere where someone mentioned it as an IP check source, so I used it, and it worked so it's stayed there for me.
I'm on Time Warner internet and my IP has never changed since I set all this up, so I've actually never seen an update to a new IP. I just see the updates when I reboot the router or change the DDNS parameters.
Interesting. I have TWC internet as well. My IP used to change only after there had been some kind of service outage in the area. But since the merger with Comcast has begun to move forward, I've had the IP change on me at least twice.
I'm on Time Warner internet and my IP has never changed since I set all this up, so I've actually never seen an update to a new IP. I just see the updates when I reboot the router or change the DDNS parameters.
Interesting. I have TWC internet as well. My IP used to change only after there had been some kind of service outage in the area. But since the merger with Comcast has begun to move forward, I've had the IP change on me at least twice.
That's why I set my check interval to 12 hours (43200 seconds), since my IP seemed really stable and it didn't seem necessary to ping Zerigo too often. I originally had it every hour, but that seemed overkill.
But if your IP seems more volatile, you might want to check more often, especially if you rely on being able to access your router externally via your DNSExit domain name all the time.
