DynDNS

aeroliteflyer

Yeah, I put the password in by hand numerous times. I even went to the xml file in pfSense that actually stores the login credentials and checked that, and it's correct. I am baffled, the Windows client works fine. Could be a cert issue? I remember reading something about DynDNS is using TLS?

Thanks,
Chris

cmb

If there were a cert problem it would fail well before that, and wouldn't have the provider response code as it wouldn't send a request to obtain a reply.

If you enable verbose logging do you get anything more in the logs?

MikeV7896

I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?

aeroliteflyer

I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red. I do have verbose logging on. The log entries are the same as before.

Chris

cmb

@aeroliteflyer:

I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red.

That's what I'd expect after switching service types, that removes the cached IP so you end up with 0.0.0.0 until it updates successfully for the first time.

@virgiliomi:

I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?

I was wondering the same thing. That dates way back, to when they were named DynDNS and not Dyn. If the diff service types had differing config options or update URLs or error response codes, that'd be why you might have 3 diff types. But looking at /etc/inc/dyndns.class, those 3 all do exactly the same thing. Haven't looked back in the history to see if things used to be different way back at some point. That probably should be consolidated to one, and renamed to Dyn, at some point.

I think we almost certainly would have heard from another Dyn user if it were completely non-functional. But they're not nearly as widely used since discontinuing free accounts, so maybe not.

My best suggestion at this point is to go back to the point where it worked (which in this case is easy, just replacing one file), and see if it still works. Replace /etc/inc/dyndns.class with:
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class
and you'll be back to how it was from February 4-14, which I believe is where your last working snapshot fell. Then trigger a dyndns update, and see what happens.

r-daneel

Hi,

I just installed pfSense to replace a small wifi router that was working fine with DynDNS.
Found this topic because I got the exact same error message (even changing the type did not help).

I'll try the code change to see if that solves the issue.

Will let you know shortly.

r-daneel

So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class

Now logs are different. Worse in a sense ;)


php-fpm[67544]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn) There was an error trying to determine the public IP for interface - (). Probably interface is not a WAN interface.
php-fpm[67544]: /services_dyndns_edit.php: phpDynDNS: (ERROR!) No Password Provided.

So I guess the code has changed too much.

Meanwhile, here are the logs I get with the original code:

php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): (Unknown Response)
php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): PAYLOAD: badauth
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): Current Service: dyndns-custom
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _checkStatus() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS: (my.hostname.fqdn) DNS update() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _update() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): running get_failover_interface for wan. found rl0
php-fpm[70638]: /services_dyndns_edit.php: DynDns (my.hostname.fqdn): XXX.XXX.XXX.XXX extracted from local system.
php-fpm[70638]: /services_dyndns_edit.php: DynDns: updatedns() starting

Credentials have been checked.

Any clue ?

P.S.: also tried ZoneEdit and it worked flawlessly.

r-daneel

Hi,

Good news.

I was fiddeling with the update URL for DynDNS trying to understand what was failing.
I used curl to do so (https://help.dyn.com/remote-access-api/perform-update/).
Also tried FireFox at some point.
Indeed, 'badauth' indicates authentication failure (https://help.dyn.com/remote-access-api/return-codes/).

I tried to update a standard 'host.dyndns.org' entry but still failed to authenticate.

While searching I found an old post (https://wiki.openwrt.org/doc/howto/ddns.client) stating:

'badauth' in Update Output, you have to change your password which contains only letters and numbers. Because busybox's (v1.15.3) wget implementation has an issue handling encoded URLs

As it did not work at first (during my very first attempts in pfSense), I switched back to the regular password for my account (just in case), full of special characters.
After reading the above post, I reverted to using the 'Updater Client Key' you can get on the 'Account Settings' page.

Now this worked for the dyndns.org domain. Also using it to update my FQDN worked.

I can't tell why I had failures using the 'Updater Client Key' in the first place, but well … now it works.

Hope this helps out.

cmb

@r-daneel:

So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class

Now logs are different. Worse in a sense ;)

Guessing you must be on 2.2.x, since the called parameters are different there, in which case that file won't work.

Could you narrow down which character in particular is causing an issue?

hasenfrasen

@cmb:

Could you narrow down which character in particular is causing an issue?

I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!

cmb

@hasenfrasen:

I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!

In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.

hasenfrasen

@cmb:

In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.

I also have a Asus RT-N65U (padavan fw) using the same DYN-Pro account (different hostname though) for two years that has worked fine lately while pfsense didn't. I also have three other (total four) virtual pfSense installations using four different hostnames, all fails the same. Either the uppercase or the exclamation did it. Dunno.

I know the DYN password was correct as I was able to log in to their site using the "wrong" password, but the "correct" credentials in pfSense failed. I have deleted and recreated the DDNS client entry numerous times in pfSense and thought… alzheimer? Phew... anyhow, it works with "special/upper" characters added.