Project

General

Profile

Actions

Bug #6357

closed

Dynamic DNS (RFC2136) updates always considered successful

Added by Thomas Ward over 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
High
Category:
Dynamic DNS
Target version:
Start date:
05/15/2016
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

Architecture: amd64
Installed version: 2.3

I've set the Priority as High, because the functionality isn't working with newly-entered Dynamic DNS entries in the WebConfigurator.


Issue Details:

It has been observed by myself that when updating RFC 2136 hosts, even with "Save and Force Update", the system does not actually check the IP address on the record (or if it exists), and then does not update the Dynamic DNS record. It only errors saying the IP address hasn't changed, however even with the record existing with mismatched addresses (that is, not matching the specified interface IP address) it still states that the IP Address hasn't changed and will not update. I've attempted to trace this issue, and I track it back to the Dynamic DNS update task in 'cron', which executes /etc/rc.dyndns.update and the same issue appears there.

Testing this a little further, to rule out the pfSense being unable to reach the DNS server, I threw some techie-fu at this, and manually ran 'nsupdate' with relevant command line arguments and pushed the update to my own server. I can confirm that this works.

Therefore, I believe the issue is somewhere in how Dynamic DNS updates are handled, and that they're not being handled correctly at all.


Output of system logs (from Web Configurator screens):

When the update task is run from the command line over SSH (/etc/rc.dyndns.update):
May 15 19:09:04 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub1.domain.tld A record because the IP address has not changed.
May 15 19:09:04 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub1.domain.tld AAAA record because the IPv6 address has not changed.
May 15 19:09:04 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub2.domain.tld A record because the IP address has not changed.
May 15 19:09:04 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub2.domain.tld AAAA record because the IPv6 address has not changed.
May 15 19:09:05 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub3.domain.tld A record because the IP address has not changed.
May 15 19:09:05 php-cgi rc.dyndns.update: phpDynDNS: Not updating sub3.domain.tld AAAA record because the IPv6 address has not changed.

When run from WebConfigurator "Save And Force Update":
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub1.domain.tld A record because the IP address has not changed.
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub1.domain.tld AAAA record because the IPv6 address has not changed.
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub2.domain.tld A record because the IP address has not changed.
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub2.domain.tld AAAA record because the IPv6 address has not changed.
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub3.domain.tld A record because the IP address has not changed.
May 15 22:54:53 php-fpm 1361 /services_rfc2136_edit.php: phpDynDNS: Not updating sub3.domain.tld AAAA record because the IPv6 address has not changed.

Actions #1

Updated by Chris Buechler over 8 years ago

  • Subject changed from Dynamic DNS (RFC2136) updates not being updated - "IP Address Not Changed", even for mis-matched IP record data at DNS server itself to Dynamic DNS (RFC2136) updates always considered successful
  • Status changed from New to Confirmed
  • Target version set to 2.3.2
  • Affected Version changed from 2.3 to All

Couple different issues here. One I opened up #6359 to cover and fixed that there, so the force update actually forces an update now. That was a regression from the Bootstrap conversion that'd gone unnoticed.

The other issue is it populates the cache file as if successful without any consideration for whether it succeeds. That's always been the case and is a bit bigger of an undertaking to address.

Thanks for the report.

Actions #2

Updated by Chris Buechler over 8 years ago

  • Target version changed from 2.3.2 to 2.4.0
Actions #3

Updated by Renato Botelho almost 8 years ago

  • Status changed from Confirmed to Assigned
  • Assignee set to Renato Botelho
Actions #4

Updated by Renato Botelho almost 8 years ago

  • Status changed from Assigned to Feedback
  • % Done changed from 0 to 100
Actions #5

Updated by Jim Pingle almost 8 years ago

  • Status changed from Feedback to Resolved

Seems to work all around. It logs correctly when it is updating, and if it fails that is also logged. It is checking for mismatches and updating the cache appropriately.

Actions #6

Updated by Jim Pingle almost 8 years ago

  • Target version changed from 2.4.0 to 2.3.3
Actions

Also available in: Atom PDF