Possible bug with Dynamic DNS

steveb53

Not sure this is the correct area, appologies if not.

A friend of mine runs dynamic DNS and this week his credentials were discovered and someone took over his dynamic dns. No real harm done, but annoying.

The effect was the culprits IP became associated with his Dynamic DNS. We changed the password to resecure the service and then updated the password in the Netgate expecting the Dynamic DNS to contact the service and update the public IP to be the correct one. That didnt happen until a force update was done.

The strange thing was that the Netgate was showing the correct IP in green suggesting that it had done a DNS lookup to make sure that the IP and the WAN IP were the same.

To prove what we think we found. We delibratly setup another netgate on a different public IP with his credentials and that published 'that' WAN IP to his dynamic DNS as expected. the proper one didnt notice that the change had happened and when we took the test one off line and left it for a few hours the proper one still had not republished the correct IP until it was forced.

The bug we think we have found is that the dynamic dns service on the netgate isnt checking periodically that the IP registered is the same as the ip of the interface its been told to watch.

If it wasnt designed to do this then its not a bug but a feature request so that if the published IP becomes different from the public IP then it triggers an update.

Bob.Dig

@steveb53 Yep I also think that the check and update are far to less done. pfSense should be much more aggressive about it.
There is a cron job which you can modify with the cron package though.

steveb53

@bob-dig Do tell. whats the info we need to modify the cron job for the dynamic dns checking.

Bob.Dig

@steveb53 said in Possible bug with Dynamic DNS:

Do tell

Change it to your liking.

steveb53

@bob-dig Thanks.

I wasnt looking to alter the checking frequency,

It appears the script isnt checking that the stored pubished IP is the same as the gateway IP which is why if it then changes as I described in the original post the script doesnt notice and then update to make sure its correct.

I think the script should make sure to test externally if a change is required as well. It doesnt look like it does this.

Gertjan

@steveb53

Which one ?

or these :

steveb53

@gertjan Dynamic DNS

I've done some more testing, the Dynamic DNS script definitly doesnt check periodically that the Dynamic IP is the same as the interface its told to monitor.

I've not found out who the maintainer is of this script. does anyone know?

thanks.

SteveITS

@steveb53 I seem to vaguely recall it checks when the WAN IP changes. I suspect it would pick it up if you disconnected the WAN cable and reconnected it to force a down/up.

Gertjan

@steveb53 said in Possible bug with Dynamic DNS:

I've done some more testing

Metoo.

You should have this :

which means : every one minute after each hour :execute /etc/rc.dyndns.update

The "/etc/rc.dyndns.update" is very small.

Because "/etc/rc.dyndns.update" it's executed without any command line parametrs, this part is executed :

The "Dynamic hosts" are handled by the "services_dyndns_configure" in /etc/inc/services.inc.

This function loops over all the configured dynamic hosts that are not disabled.

For each host, it calls the function "services_dyndns_configure_client" (also /etc/inc/services.inc)

This function instantiates this class :

When this PHP class is 'constructed', some tests are executed, depending the type of dyndns host you use, and on line 336 :

			$this->_checkIP();

This functions uses the global exposed function "dyndnsCheckIP" (which has a/the WAN interface as parameter) (defined in /etc/inc/services.inc ).
It's defined here :

Try the pre defined function yourself in a browser. It should show your WAN IPv4 address :
I saw :

and that is my WAN IPv4 right now.

Time to check it for yourself : http://checkip.dyndns.org

The function dyndnsCheckIP() throws out a 'curl' to the host http://checkip.dyndns.org - and this 'site' returns the text "Current IP Address: a.b.c.d".
The a.b.c.d part is parsed out, and considered your WAN IP.

Even if your pfSense router/firewall is connected behind one or several upstream routers, this will always work.

If you want details of each "DYNDNS" check and the (possible) update process, that is : each time the cron task wakes up, check :

You'll see these lines in the master log :

2021-07-13 01:01:02.202246+02:00 	php 	53132 	rc.dyndns.update: Dynamic DNS: updatedns() starting 
2021-07-13 01:01:02.629047+02:00 	php 	53132 	rc.dyndns.update: Dynamic DNS opendns (office): 82.127.34.254 extracted from Check IP Service
2021-07-13 01:01:02.629081+02:00 	php 	53132 	rc.dyndns.update: Dynamic DNS (xxxx): running get_failover_interface for wan. found em0
2021-07-13 01:01:03.055673+02:00 	php 	53132 	rc.dyndns.update: Dynamic DNS opendns (xxx): 82.127.34.254 extracted from Check IP Service
2021-07-13 01:01:03.055673+02:00 	php 	53132 	rc.dyndns.update: Dynamic DNS opendns (xxx): 82.127.34.254 extracted from Check IP Service
2021-07-13 01:01:03.055742+02:00 	php 	53132 	rc.dyndns.update: Dynamic Dns (xxx): Current WAN IP: 82.127.34.254 Cached IP: 82.127.34.254
2021-07-13 01:01:03.055768+02:00 	php 	53132 	rc.dyndns.update: phpDynDNS (xxx): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.

When you see "82.127.34.254 extracted from Check IP Service" you know that this IPv4 has been given to 'you' (pfSense) by http://checkip.dyndns.org/ did not came from a local file or so.

So, this :

@steveb53 said in Possible bug with Dynamic DNS:

the Dynamic DNS script definitly doesnt check periodically

is not a general issue, but, for you, a local issue.
Time to tell us more (example : like I did). Be verbose. We'll tell you whats wrong.

SteveITS

@gertjan said in Possible bug with Dynamic DNS:

No change in my IP address and/or 25 days has not passed

I believe this is the part I had found...if the code doesn't think the pfSense WAN IP has changed there's nothing to update.

IOW it's not "I need to make sure dyndns is correct" it's literally "there's nothing to change."

Gertjan

@steveits said in Possible bug with Dynamic DNS:

No change in my IP address and/or 25 days has not passed

I believe this is the part I had found...if the code doesn't think the pfSense WAN IP has changed there's nothing to update.

Exact.
See line 357 in /etc/inc/dyndns.class.
The "_detectChange()" function checks the IP using "http://checkip.dyndns.org/" - and compares the IPv4 with hat is stored in cache file.

You can find the IPv4 cache file here /etc/conf/
It's called :

-rw-r--r--  1 root  wheel      24 Jun 19 18:52 dyndns_wanopendns'xxxx'1.cache

and contains the IP ( :) ) and a 'unix' time stamp code.

This is the content of my file :

82.127.34.254|1624121569

If the two are identical, there is nothing to do.
My WAN IP is 82.127.34.254 and the file contains also "82.127.34.254" : the hourly dyndns update aborts.

You can test yourself :
Compare your cache file with what comes back from here : http://checkip.dyndns.org/
Is it identical ?

Bob.Dig

@gertjan said in Possible bug with Dynamic DNS:

which means : every one minute after each hour :execute /etc/rc.dyndns.update

Small correction: "At 01:01.”

1 0-23 * * *
would be every hour.

steveb53

@bob-dig Hello.

If the WAN is the same as it was on the last check then no change is pushed to DynDNS, becuase it thinks there is nothing to update.

The original problem was caused by someone else getting the credentials of the DynDNS service and altering the public IP against the DynDNS entry.

If the script were to perform a DNS lookup against its own DynDNS entry to double check that the result from http://checkip.dyndns.org/ matches and perform an update if either it doesnt match or the WAN has changed that would be good.

SteveITS

@gertjan said in Possible bug with Dynamic DNS:

My WAN IP is 82.127.34.254 and the file contains also "82.127.34.254" : the hourly dyndns update aborts

This is the scenario the OP is describing...the WAN IP hasn't changed, but the IP is still wrong in DNS because it was updated by something else.

Vs. other implementations I've seen (and even wrote a basic one, long ago) where the server tracks whether the IP changes.

A few dynamic DNS allow manual updates after logging in to their site, I think I've seen? Otherwise a workaround might be to put in a wrong IP, run the cron job, then go back to the correct IP. Might fool it into updating.

Gertjan

@bob-dig said in Possible bug with Dynamic DNS:

Small correction: "At 01:01.”
1 0-23 * * *
would be every hour.

Your right
And seems more logic also.
Most DynDNS suppliers don't like having their systems accessed for unneeded updates.

Keep in mind : there is another situation that forces the /etc/rc.dyndns.update to get called : when the WAN interface goes DOWN and UP, and (another) IP gets assigned.

@steveb53 said in Possible bug with Dynamic DNS:

The original problem was caused by someone else getting the credentials of the DynDNS service and altering the public IP against the DynDNS entry.

You (your dyndns updater) should be the only one able to update your dyndns host name. If the system gets hacked, everything is possible.

@steveb53 said in Possible bug with Dynamic DNS:

If the script were to perform a DNS lookup against its own DynDNS entry to double check that the result from http://checkip.dyndns.org/ matches and perform an update if either it doesnt match or the WAN has changed that would be good.

Such an access must exist first, the dyndns must publish some sort of API to read back the value. Or do a 'dig' locally for your dyndns hostname.
But again : why bother : just make sure no one else uses your credentials and everything will be fine. "keep it simple" is always the best solution.

You won't be able to negotiate something with your car insurance neither when you give your car keys to some stranger ....

steveb53

@gertjan said in Possible bug with Dynamic DNS:

Most DynDNS suppliers don't like having their systems accessed for unneeded updates.

The issue is there had been an update and it was changed to another IP.

The original problem was caused by someone else getting the credentials of the DynDNS service and altering the public IP against the DynDNS entry.

You (your dyndns updater) should be the only one able to update your dyndns host name. If the system gets hacked, everything is possible.

Correct, however the system didnt get hacked, the credentials for the service was used.

If the script were to perform a DNS lookup against its own DynDNS entry to double check that the result from http://checkip.dyndns.org/ matches and perform an update if either it doesnt match or the WAN has changed that would be good.

Such an access must exist first, the dyndns must publish some sort of API to read back the value. Or do a 'dig' locally for your dyndns hostname.

It doesnt need to access the service to do this, a simple DNS lookup will achieve the same.

But again : why bother : just make sure no one else uses your credentials and everything will be fine. "keep it simple" is always the best solution.

Agreed, but credentials get compromised all the time.

The script logic could be;

What's my public IP
Check 1 : Local check is my WAN different from my cached YES/NO
Check 2 : Regular DNS lookup, is my WAN different from DNS. YES/NO
If check 1 YES then perform update, its a natural change of our WAN
if check 2 YES then perform update, something else must have changed it. report to sysop for further checks.

frankz

hi, I have a problem with noip, as before the update it worked correctly, but now I have noticed that if I force update it gives me the ip green, but on nonip.com the ip remains the old one. I tried has install DUC on windows and it works. Can someone tell me why they update the ip on pfsense with green color while on the provider not?

Gertjan

@frankz
Check the logs on your system.

frankz

@gertjan i'am resolve to patch 4aab19d4ade5d164c22bd63b2833d54bab740d59

steveb53

@gertjan
I've done a bit of fiddling and cobbled this together and its logging correctly. - I made a manual change directly on the service and it detected it.

$dyndnsis = gethostbyname($this->_FQDN); // lets see what the public DNS things our IP is

if ($this->_dnsIP != $dyndnsis) {

log_error(sprintf(gettext('Dynamic DNS Someting is wrong %1$s should be %2$s and its come back as %3$s'), $this->_FQDN, $this->_dnsIP, $dyndnsis));
}

else {

log_error(sprintf(gettext('Dynamic DNS all is well %1$s should be %2$s and its come back as %3$s'), $this->_FQDN, $this->_dnsIP, $dyndnsis));
}

I'm not too sure where it should sit in the dyndns.class file, I've got it at line 360 just above the line that reads $this->_debugID = rand(1000000, 9999999);

I also need to be able to trigger an update should the public DNS return a different IP than expected.