Messages

Thanks Franco,

I Have unbound listening to all the LAN interfaces, but not the WAN:

Code Select Expand


# grep -i interface /var/unbound/unbound.conf
# Interface IP(s) to bind to
interface: 192.168.1.1
interface: 192.168.2.1
interface: 192.168.3.1
interface: 127.0.0.1
interface: ::1
# Outgoing interfaces to be used
outgoing-interface: 1.2.3.4
    control-interface: 127.0.0.1


Greetings,

On an installation running OPNsense 18.7.10_3 (amd64/OpenSSL), the wan ip address changed, which for some reason caused unbound to also restart. In the race condition, rc.newwanip tried to update the DDNS record, but unbound wasn't until ready to resolve the endpoint and therefore the update failed.

Code Select Expand


Apr 12 03:07:57 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS: updatedns() starting
Apr 12 03:07:57 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS (blah.blah): 1.2.3.4 extracted
Apr 12 03:07:57 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS (blah.blah): running get_failover_interface for wan. found em0
Apr 12 03:07:57 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS (blah.blah via freeDNS): _update() starting.
Apr 12 03:08:08 192.168.1.1 unbound: [81806:0] notice: init module 0: validator
Apr 12 03:08:08 192.168.1.1 unbound: [81806:0] notice: init module 1: iterator
Apr 12 03:08:08 192.168.1.1 unbound: [81806:0] info: start of service (unbound 1.8.3).
Apr 12 03:08:08 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS (blah.blah): _checkStatus() starting.
Apr 12 03:08:08 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Dynamic DNS (blah.blah): Current Service: freedns
Apr 12 03:08:08 192.168.1.1 opnsense: /usr/local/etc/rc.newwanip: Curl error occurred: Could not resolve host: freedns.afraid.org

This is not the only set of conditions that could lead to this situation. In general any temporary DNS resolution errors, or connectivity issues could leave the DDNS record pointing to the previous wan ip address.

Is this worth opening an issue? Ideally the DDNS update should either continue retrying implementing a back off mechanism, or, schedule itself to retry later, maybe via cron.