Namecheap dynamic dns Not Updating

Trel

@Trel:

(I'm not seeing an edit button to add this to my last post)

If your post is not "too old" there should be a "Modify" link on it.

It was too old then. I see a modify link on my newer one. I hate double posting >.>

loiphin

I also have this issue. So what I did as a workaround is SCP ddclient (http://sourceforge.net/apps/trac/ddclient/) onto my pfsense box. It is a perl script, so no need to have a specific version compiled for freebsd/x86. I then updated the config for namecheap, and it works great :)

Its a hack, but it works.

Trel

I cannot do that sadly. I need to use the built in function for this.

jimp

It may be due to how the update URL gets formed when using the "@" record.

Can you try this with an actual hostname under the domain rather than the @ record?

Trel

@jimp:

It may be due to how the update URL gets formed when using the "@" record.

Can you try this with an actual hostname under the domain rather than the @ record?

That's not possible with the domain in question. I could try adding one, but I can't until tonight.
(and ultimately it IS the @ record that needs to be updated, so even if this is the issue, I need it to work for the @ records.)

jimp

Yes, I understand that, I'm just trying to make sure it's not a problem with your account in general, but one specific to the @ record handling.

I don't have a free @ record handy that I can tinker with at the moment, but I can try to free one up. All my Namecheap dyndns entries are traditional host.domain.tld format, no @ records.

Trel

@jimp:

Yes, I understand that, I'm just trying to make sure it's not a problem with your account in general, but one specific to the @ record handling.

I don't have a free @ record handy that I can tinker with at the moment, but I can try to free one up. All my Namecheap dyndns entries are traditional host.domain.tld format, no @ records.

I'll see if I can make an additional one during my lunch.

jimp

I was able to free up an @ on one of my domains for testing, and it worked for me. No errors, and the @ record updated as expected.

I used the @.domain.tld format and it updated as expected using the dyndns access key for the domain.

Maybe try to re-enable DynDNS for your domain and then use the new auth token they generate when it resets.

jimp

Oh, and that was on a 2.1 snapshot from Thursday.

Trel

@jimp:

Oh, and that was on a 2.1 snapshot from Thursday.

I'm not on a snapshot. I'm using the latest stable.

jimp

I pulled up a 2.0.3 VM and tried it there, worked the same, no problems. I even edited the IP in Namecheap's control panel to something bogus, then removed the cached IP from the pfSense VM and made it update again, worked fine.

Trel

@jimp:

I pulled up a 2.0.3 VM and tried it there, worked the same, no problems. I even edited the IP in Namecheap's control panel to something bogus, then removed the cached IP from the pfSense VM and made it update again, worked fine.

Does it work if the domain is one deeper, @.sub.domain.com?
(Also, how can I force it to update for testing)
(And you're leaving the username blank, right?)

jimp

Username blank, yes.

You can force an update by removing the cache file from /conf and then saving on the page.

A subdomain is not considered an @ record in their DNS that I'm aware of. It would just be sub.domain.com where sub is just a hostname in that context.

IIRC their DNS does not split that into separate "true" zones that would contain an @ record.

Trel

@jimp:

Username blank, yes.

You can force an update by removing the cache file from /conf and then saving on the page.

A subdomain is not considered an @ record in their DNS that I'm aware of. It would just be sub.domain.com where sub is just a hostname in that context.

IIRC their DNS does not split that into separate "true" zones that would contain an @ record.

sub.domain.com is what is pointed to namecheap. domain.com is pointed elsewhere.
I need to update @.sub.domain.com for it to accept it.

(I know this setup works as I came from a WRT54GL with Tomato firmware that had no issue updating)

jimp

OK. It's possible that their dyndns API has a problem with that particular setup then. I don't have anything even close to that setup to test.

I'd need to see the exact update URL used by tomato to know what might fix it.

Trel

@jimp:

OK. It's possible that their dyndns API has a problem with that particular setup then. I don't have anything even close to that setup to test.

I'd need to see the exact update URL used by tomato to know what might fix it.


	// +opt +opt +opt
	sprintf(query, "/update?host=%s&domain=%s&password=%s",
		get_option_required("host"), get_option("user") ? : get_option_required("domain"), get_option_required("pass"));

	// +opt
	append_addr_option(query, "&ip=%s");

I took this from Tomato's source.
I'm not well versed in coding, but I'm pretty sure that's where it updates to.
so in my case, it would look like:

update?host=@&domain=sub.domain.com&password=somethingcomplicated

jimp

I think I see where the problem might be, in our code, it assumes for .com (and most others) that the domain part is only domain.tld, so it's probably splitting that into @.sub for the host and domain.com for the domain.

Not sure if there will be any easy way around that, I'll have to dig at it a little.

Trel

@jimp:

I think I see where the problem might be, in our code, it assumes for .com (and most others) that the domain part is only domain.tld, so it's probably splitting that into @.sub for the host and domain.com for the domain.

Not sure if there will be any easy way around that, I'll have to dig at it a little.

That implementation looks like it could cause problems with many country tlds such as ".co.uk" or similar as "@.sub.domain.com" has the same separations as "@.domain.co.uk"

jimp

No, there is code specifically to handle domain.co.uk, there is a list in the client that knows how many levels deep TLDs go and sets exceptions based on the TLDs offered by Namecheap.

Might have to hack it so if you put in @ for the username and the actual sub.domain.com for the hostname then it would do the right thing… might be a bit before I'd have a chance to take a crack at it, I haven't touched the dyndns code in a while, it's not terribly complex though.

Trel

@jimp:

No, there is code specifically to handle domain.co.uk, there is a list in the client that knows how many levels deep TLDs go and sets exceptions based on the TLDs offered by Namecheap.

Might have to hack it so if you put in @ for the username and the actual sub.domain.com for the hostname then it would do the right thing… might be a bit before I'd have a chance to take a crack at it, I haven't touched the dyndns code in a while, it's not terribly complex though.

Since the "@" and the no username part only exists for namecheap, I can't imagine it being too difficult to do that with an if statement in general.
Other than the program the other person linked earlier, is there any interim solution I can do in the mean time?

Is curl or wget installed by default? If so I imagine I could temporarily install the cron package and do it that way.