• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

dynamic DNS - 1/3 not correctly set at boot

Scheduled Pinned Locked Moved DHCP and DNS
18 Posts 2 Posters 1.1k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D
    dvl
    last edited by Feb 27, 2019, 1:36 PM

    @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
    badauth
    

    Thank you

    G 1 Reply Last reply Feb 27, 2019, 1:53 PM Reply Quote 0
    • G
      Gertjan @dvl
      last edited by Feb 27, 2019, 1:53 PM

      @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.

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

      D 1 Reply Last reply Feb 27, 2019, 2:01 PM Reply Quote 1
      • D
        dvl @Gertjan
        last edited by Feb 27, 2019, 2:01 PM

        @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?

        G 1 Reply Last reply Feb 27, 2019, 4:23 PM Reply Quote 0
        • G
          Gertjan @dvl
          last edited by Feb 27, 2019, 4:23 PM

          @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.org
          

          This 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.

          No "help me" PM's please. Use the forum, the community will thank you.
          Edit : and where are the logs ??

          1 Reply Last reply Reply Quote 1
          • D
            dvl
            last edited by dvl Feb 27, 2019, 5:01 PM Feb 27, 2019, 5:01 PM

            Are you sure that checkip.dyndns.org is being invoked at this point or is pfSense acting upon knowing a change has occurred?

            1 Reply Last reply Reply Quote 0
            • G
              Gertjan
              last edited by Gertjan Feb 27, 2019, 11:22 PM Feb 27, 2019, 11:19 PM

              _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.

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              D 1 Reply Last reply Feb 28, 2019, 2:56 PM Reply Quote 1
              • D
                dvl @Gertjan
                last edited by Feb 28, 2019, 2:56 PM

                @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.

                1 Reply Last reply Reply Quote 0
                • G
                  Gertjan
                  last edited by Gertjan Feb 28, 2019, 3:03 PM Feb 28, 2019, 3:02 PM

                  👍

                  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 !

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  1 Reply Last reply Reply Quote 1
                  • D
                    dvl
                    last edited by Feb 28, 2019, 3:35 PM

                    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

                    1 Reply Last reply Reply Quote 0
                    • D
                      dvl
                      last edited by Feb 28, 2019, 3:43 PM

                      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.update
                      

                      What 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.

                      1 Reply Last reply Reply Quote 0
                      • D
                        dvl
                        last edited by Feb 28, 2019, 4:00 PM

                        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.

                        1 Reply Last reply Reply Quote 0
                        • D
                          dvl
                          last edited by Feb 28, 2019, 4:03 PM

                          An interesting popup when trying to delete a cron entry:

                          0_1551369702981_Screen Shot 2019-02-28 at 11.00.48 AM.png

                          1 Reply Last reply Reply Quote 0
                          • D
                            dvl
                            last edited by Feb 28, 2019, 4:08 PM

                            This is what the resulting cronjob looks like:

                            0_1551370121202_Screen Shot 2019-02-28 at 11.02.15 AM.png

                            1 Reply Last reply Reply Quote 2
                            18 out of 18
                            • First post
                              18/18
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                              This community forum collects and processes your personal information.
                              consent.not_received