Dynamic DNS not updating (PPPoE) WAN IP sometimes

SteveITS

I just ran into this again myself today setting up a new router:

set up pfSense
set up no-IP dyndns account from my office, which uses my office address by default
configure no-IP in pfSense

A success shows:

/services_dyndns_edit.php: phpDynDNS (example.com): (Success) No Change In IP Address

As noted this is because pfSense doesn't think its IP changed, but no-IP still has the wrong IP, my office IP. At this point Save and Force Update does not update the hostname.

I can set it manually at no-IP of course but that defeats the purpose. Presumably it would update when the WAN IP changes when it is moved on site.

Edit: it doesn't seem to work to delete the .cache file either. It still logs "No Change In IP Address."

w0w

@SteveITS
Use verbose logging. Does it create cache file again after delete?

The other question is why 25 days? Why not 500 days or 1 hour? Is it some standard specified option?
EDIT: Found this https://redmine.pfsense.org/issues/9092
Looks like we have this option for some DNS providers in the GUI, but not for others. BTW I did not find any limitations on duiaDNS service, except
1k DNS queries / day
300 sec. TTL (Time to Live)
So I don't think I've somehow violated rules/limits.

SteveITS

@w0w Got sidetracked by a new router with a bad WAN port.

If I change the IP in the no-IP web site, delete the cache file and force an update, verbose logs show:

Jul 18 11:38:50	php-fpm	1108	/services_dyndns_edit.php: Dynamic DNS noip (example.com): _update() ending.
Jul 18 11:38:50	php-fpm	1108	/services_dyndns_edit.php: Dynamic DNS noip (example.com): _checkStatus() ending.
Jul 18 11:38:50	php-fpm	1108	/services_dyndns_edit.php: phpDynDNS (example.com): (Success) No Change In IP Address
Jul 18 11:38:50	php-fpm	1108	/services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wannoip'example.com'0.cache: 173.x.x.x
Jul 18 11:38:50	php-fpm	1108	/services_dyndns_edit.php: Dynamic DNS noip (example.com): 173.x.x.x extracted from Check IP Service
Jul 18 11:38:49	php-fpm	1108	/services_dyndns_edit.php: Dynamic DNS noip (example.com): _checkIP() starting.
Jul 18 11:38:49	php-fpm	1108	/services_dyndns_edit.php: Dynamic DNS noip (example.com): _checkStatus() starting.
Jul 18 11:38:49	php-fpm	1108	/services_dyndns_edit.php: Response Data: nochg 173.x.x.x\x0d

...and the IP at no-IP isn't updated. The cache file does get recreated and does contain the correct IP.

If I manually change the IP in the cache file, I get "No Change In IP Address" again. At this point the dyndns page in pfSense shows the wrong IP which I typed in.

I then lowered the second number in the cache file, presumably a timestamp. If I force it, it seems to try to update.

However another thing I seem to be fighting sometimes, and just showed up again, is I keep getting an invalid password message. When that happens it seems like I have to both paste in the same password and type (and remove) a character in the username box to get it to work (i.e. edit the field). Which is weird since I'm not actually changing either field but it would be a large coincidence at this point otherwise as it has happened several times.

Anyway, after re entering the password the cache file is updated, I get the "DynDNS updated IP Address" email from pfSense, but pfSense again logs "No Change In IP Address" and the IP is not updated at the service.

Maybe No-IP integration is broken again? could be that, and is just hidden if none of our clients with it set up have had an IP change.

Gertjan

@SteveITS said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

...and the IP at no-IP isn't updated. The cache file does get recreated and does contain the correct IP

Before this line :

Jul 18 11:38:49 php-fpm 1108 /services_dyndns_edit.php: Response Data: nochg 173.x.x.x\x0d

Is this line noip related ? Do you have more then one dyndns host name ? (they are executed in parallel, and log lines can get intermixed).
I presume you have only one.
The DynDNS had decided to update the info stored @no-ip.
no-ip came back with what is a soft-warning : "there was no change, the IP that I had to put it place was was already stored in the no-ip records". This messages is known as "nochg" and means that the client decided to update the IP at dynsnds service (no-ip ) but the local dyndns code forgot that it already send that IP to no-ip. This, in theory, is already an error condition. To many of them an the dyndns will lock you out.

Whne you see this (one second later !) :

Jul 18 11:38:50 php-fpm 1108 /services_dyndns_edit.php: Dynamic DNS noip (example.com): 173.x.x.x extracted from Check IP Service

Then pfSense / dyndns uses this Services > Dynamic DNS > Check IP Services == http://checkip.dyndns.org ti check the IPv4 (only ?) address of the interface that is use to map the WAN IPv4.

The IP that you get back, a simple html page like : "Current IP Address: 82.127.27.108" is parsed out to extract the IPv4 "82.127.27.108". This IPv4 is compared with the content of the cache file.
Have a look at this file : it contains de IP and a 'nix' time stamp. The time stamp is the date/moment of the last successful dyndns service update.
If the IP in the cache file is the same as the IP obtained by "http://checkip.dyndns.org" then all is well and nothing needs to be done => the WAN IP didn't change.
The time stamp is used for the "25 days refresh" : if the last successful time stamp was more then 25 days ago (in the past) then the dyndns service is updated with the IP even when it didn't change. See this as a "service is still active" heart-beep. In the past, some dyndns services could consider that the dyndns host wasn't there anymore as it wasn't updated anymore : the host name would be deleted.

In your case, less then a second later :

Jul 18 11:38:50 php-fpm 1108 /services_dyndns_edit.php: phpDynDNS (example.com): (Success) No Change In IP Address

The IP in the cache file cache file was identical to the actual WAN IP, so nothing needs to be done.
That is : the cache file is updated with (the same, I hope, as it is extracted again from http://checkip.dyndns.org) IP, and a current time stamp.
A message notification (mail, telegram, etc) is send "DynDNS updated IP Address on...." and a log line is added "phpDynDNS: updating cache file ...." : you have that line shown.

Note that your log lines are not complete.

A dyndns check/update/whatever start with

Dynamic DNS: updatedns() starting

as that line is shown when "dyndns.class" is invoked.

Right now : the fact that a '_error' happened says to me :
an _update() happened. That means that you :
Forced the update in the GUI
or
The cached file didn't contain the current WAN IPv4 ( or more then 25 days have past)

What was it ?

edit :

@SteveITS said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

Maybe 'whatever dyndns' integration is broken again?

Yeah, that one.
And that person that said to me ones : "master DNS, or do something entirely different, like growing flowers"
made me to have a face-to-face with 'bind'.
To make a long story short : with bind, you don't bother with DNS (all of it) anymore **. A sub-advantage is also : free dyndns for live. The one that works.

** not considering DNSSEC.

SteveITS

@Gertjan Only one dyndns for me. Yes I just snipped the logs.

I was trying to Save and Force each time on my testing yesterday. The public WAN IP on the router is detected correctly by pfSense but No-IP isn't updating the A record on its end. The recurring "wrong password" issue also makes me think something is incorrect in the process. I was going to try the No-IP software client and if it works not use pfSense in this case, but it makes me wonder if others with No-IP are silently not being updated.

w0w

@SteveITS
I don't remember exactly all the reasons why I have been stopped using no-ip, because it was about 7 years ago. But definitely there were some changes made in their use policy and some lack of free service since. So I just moved to strangled.net and then to duia.eu as far as I can remember it.

I don't know what exactly happens when IP is suddenly not updated. But if I understand it correctly, it should be possible to dig the current IP directly from DNS service and compare it with saved one and current one existing on interface.
If DNS returns some IP that differs from that one currently used on the interface and some minimal period, not that “25 days” one, is over, then IP should be forced to update or give some clear warning, send notification. It can be also adjustable, option “use at own risk” warning included.
I am not sure do we really need this cached IP locally? Can't it just compare the IP online? Just using “safe” interval in between of updates and checks if it already updated? A couple of hours or days, adjustable?
Just stupid thoughts.
Currently, I have played with maxcacheage option in config. Will report back if this helps.

SteveITS

@w0w said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

stopped using no-ip, because it was about 7 years ago. But definitely there were some changes made in their use policy and some lack of free service

Last I knew they still have free accounts but you have to click a link in a monthly email to keep it active. The one I'm using is a paid account though. We gave up on "free" pretty quickly...which was obviously their goal.

@w0w said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

do we really need this cached IP locally? Can't it just compare the IP online?

In essence it does seem overly complicated. The two things that need comparing are the dynamic DNS A record answer, and the detected public IP. The value the WAN IP had last time is actually irrelevant. It might be correct, or it might not, but if it's correct and the dyndns service is wrong it still needs updating.

Perhaps there's some edge case or service where the hostname is deleted by the service after "n" days but can still be updated? Actually even then the update wouldn't work because the cached value in pfSense would still be correct...unless the 25 days had expired.

Gertjan

@w0w said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

I am not sure do we really need this cached IP locally?

That file is needed.
The file contains an IP : that was the IP that was 'updated' successfully the last time by the pfSEnse the dyndns service.
It also contains a time stamp, so locally it is known when the last update happened.
Even if the IP didn't not change, after every (daily) test the time stamp will be updated.

The "25" days test was created as, because the orignal dyndns.org wanted you to update the IP even if it did not change on your side for 25 days.
See this as a sort of "I'm still there, I still need the service, just my WAN I did not change".
The dyndns host name were used a lot as a sort of free domain name, and dydns didn't wanted that to happen. dyndns.org type of domain names are 'expensive' for them as the domain name has a very low TTL, so, when it gets asked for DNS resolving, a lot more then normal DNS traffic is generated.
Normal DNS master name servers use a TTL of hours or even days. because IP are static == never change anyway. This means that resolvers can cache the info, so overall DNS get less.

Btw : you can test the entire sequences yourself.
First : make the pfSEnse dyndns service log with details / verbose.

Now, connect with a browser to no-ip, login, and manually change your IP registerd : make it for example 1.2.3.4 - anything else as your WAN actual WAN IP.

When done. Stop pfSense. Count to 30. Start pfSense.

Let it boot.

Now, console or SSH in (or if you have to : use the GUI) and look at the logs.
Look at all dyndns log lines. Especially the data payload lines (the answer that came back when the update happens) as that one shows the result of the update.
name-cheap, no-ip etc can change a letter or two in the result-payload. Instead of "Ok, ....." it could now reply with "OK ....." and that answer will be seen as a fail by pfSense as a (one) letter changed.
The update did happen, but pfSense will show you something went wrong.
This forces you to "do something" and "get fed up with it" and "make you think something is wrong" and changes are great that you become tired of all this so you take the $$ option. The $$ option won't "break" suddenly, as you now pay for a service.

Why all this ?
Because that's the first thing you and I would do if we worked for this company

@SteveITS said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

or it might not, but if it's correct and the dyndns service is wrong it still needs updating.

I'll present you with a case.

You (your script) updates the IP, as there was a mismatch.
The dyndns service accepts your update, but fails to transmit the updated hostname to its DNS name server.
On your side, an event restarts packages. dyndns locally is restarted, and finds again a mismatch.
An update happens ...

Now, take in consideration you are not the one and only client of the dyndns service, they have millions of clients. Their back end upgrade service will get wiped of the "Internet surface", it will melt down : a real DDOS will take place.

This scenario really happened. And not just ones.

w0w

@Gertjan said in Dynamic DNS not updating (PPPoE) WAN IP sometimes:

You (your script) updates the IP, as there was a mismatch.
The dyndns service accepts your update, but fails to transmit the updated hostname to its DNS name server.
On your side, an event restarts packages. dyndns locally is restarted, and finds again a mismatch.
An update happens ...

Well, I do not know…
What prevents you from continuing to record the time stamp of the last update without writing down the IP itself and, based on this stamp, choose the next period for updating, so DDoS does not happen, with a safe interval? Each time checking if the record has been updated and only trying to update if the IP is not the same? You don’t even need to process dyndns server responses.
And yes, you can also force it to update as it doing after desired period of time 25 days by default or 6 for some services.

If it comes to that, you can also write to the file the number of FAILURE attempts to update the record. Failure attempts are how many times the address comparison on the interface was incorrect and after some attempt, say the 10th, stop everything altogether or set new safe interval for whatever you think, ex. one week and giving clear error to user that something is definitely wrong with that service or it's settings.

SteveITS

So....finally figured out I had the incorrect credentials when I couldn't get it to log in using the No-IP software. Using a group, the login field is format groupname:account-username not groupname:dyndns-first-part-of-hostname. However, I am left wondering why it "succeeded" so often using pfSense, in that I only got the "mysterious" credential error sometimes.