dynamic DNS - 1/3 not correctly set at boot
-
@dvl said in dynamic DNS - 1/3 not correctly set at boot:
Curl error occurred: Could not resolve host: members.dyndns.org
I see the same thing :
[2.4.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: host members.dyndns.org members.dyndns.org is an alias for vip.web1-05-ussnn1.prod.dc.dyndns.com. vip.web1-05-ussnn1.prod.dc.dyndns.com has address 162.88.175.12 [2.4.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: curl 162.88.175.12 404I not using any DynDNS paid (?) services - but this URL returns "404" as a text result.
That's not really a valid IP address.
You really need "members.dyndns.org" ? The default "checkip.dyndns.org" isn't good enough ? -
@gertjan said in dynamic DNS - 1/3 not correctly set at boot:
I not using any DynDNS paid (?) services - but this URL returns "404" as a text result.
That's not really a valid IP address.
You really need "members.dyndns.org" ? The default "checkip.dyndns.org" isn't good enough ?Good catch. However, I think that tests the wrong URL.
In my case, the 'Service Type' I have selected at /services_dyndns_edit.php?id=0 is 'DynDNS (dynamic)'.
This is defined in /etc/inc/services.inc, look for define('DYNDNS_PROVIDER_VALUES'
In /etc/inc/dyndns.class I find: $server = "https://members.dyndns.org/nic/update";
That URL works:
$ curl https://members.dyndns.org/nic/update badauthThank you
-
@dvl said in dynamic DNS - 1/3 not correctly set at boot:
However, I think that tests the wrong URL
The "DynDNS client" build into pfSense uses checkip.dyndns.org because it's special : it should return an nearly empty html page as a reply.
It should contain a IPv4 address. That's the adress the web server (at checkip.dyndns.org) caught as our WAN IPv4.
It's has nothing to do with the URL or domain name. Yo could use any test page, as long as it returns the WAN IP as a reply.Btw : click on it and see for yourself : checkip.dyndns.org
Your "members.dyndns.org" page bails out with a "404" as a reply. That's good enough to fail the test. The DynDNS update procedure stops.
This : https://members.dyndns.org/nic/update (with a lot of parameters which must be valid) is part of the update API @ dyndns.org - and has nothing to do with detecting a WAN IP. User ID, the IPv4 and whatever else should be added (encoded) so you, the DynDNS client, can identify itself.
-
@gertjan said in dynamic DNS - 1/3 not correctly set at boot:
Your "members.dyndns.org" page bails out with a "404" as a reply. That's good enough to fail the test. The DynDNS update procedure stops.
You say 'your'. It is not mine. It is built into the pfSense code. It is the page used to update the IP address with my DynDNS provider. It is not the page used to determine the IP address.
Am I confused about this interpretation of what is going on?
-
@dvl said in dynamic DNS - 1/3 not correctly set at boot:
Am I confused about this interpretation of what is going on?
Hummmm.
I see what you mean .... !Feb 25 16:55:56 bast php-fpm[336]: /rc.dyndns.update: Curl error occurred: Could not resolve host: members.dyndns.orgThis is probably an error spit out during line 460 - /etc/inc/dyndns.class - suddenly "members.dyndns.org" couldn't be be resolved.
Or, a small moment just before that point, checkip.dyndns.org resolved very well.I guess it's actually just bad timing : the resolver (or forwarder) was being restart at that very moment.
-
Are you sure that checkip.dyndns.org is being invoked at this point or is pfSense acting upon knowing a change has occurred?
-
_Checkip() is called first, and uses the checkip.dyndns.org URL to get the actual WAN IP.
It's compared with the cached IP.
If different, in the case of a dyndns.org, htpps://members.dyndns.org&...... is called to set the new WAN IP.
It's that last call that fails with a "cannot resolve", I guess because at that moment the Resolver was asked to restart for some reason.edit : remember : power came just back, processes starting up, like the dyndns house keeping. At boot time, it's not unknown that processes restart more often. Unbound is pretty known for being kicked around a lot.
-
@gertjan For what it's worth, I'm using BIND here.
In the case of a power-up after a power-failure, what can be done to ensure success on this? I have an idea.
I am tempted to invoke create a cronjob which will be invoked using the @reboot feature. That script will first sleep for 5 minutes, and then invoke /etc/rc.dyndns.update
This sleep time is based on:
- the system booted at Feb 25 16:55:01
- the 'Could not resolve host' log entry at Feb 25 16:55:56
This means any failed initial sequence will be fixed 5 minutes later.
-
In my early "pfSEnse" days, I also discovered that sometimes my dyndns IP was not updated.
What I did : I inserted into the /etc/inc/dyndns.class file a sleep(60) timer.
You solution is much more cleaner ! -
Thanks.
I try to never modify vendor code, instead preferring to send patches upstream.
Maintaining your own set of patches is not sustainable for moving targets.
I just installed the cron package. What is an appropriate place to install my scripts? I'm planning on /usr/local/sbin/fix-dydns-after-reboot.sh
-
Here is the file:
$ ls -l /usr/local/sbin/fix-dydns-after-reboot.sh -rwxr-xr-x 1 root wheel 138 Feb 28 15:40 /usr/local/sbin/fix-dydns-after-reboot.sh $ cat /usr/local/sbin/fix-dydns-after-reboot.sh #!/bin/sh # sleep for 5 minutes /bin/sleep 300 # invoke the same code as found in the crontab /usr/bin/nice -n20 /etc/rc.dyndns.updateWhat I just found amusing: I ran the job from the command line and wondered why I was not seeing anything in the log files....
I need to wait 5 minutes.
-
Confirmed, this worked, by viewing: /status_logs.php
I then added to cron, to run at a soon-to-occur time. That ran fine too.
I am now confident this will run at @reboot.
-
An interesting popup when trying to delete a cron entry:
-
This is what the resulting cronjob looks like:
