Trigger record update if current record value != WAN IP even if WAN IP has not changed

[sherif-fanous]

Behaviour

ddns-route53 doesn't attempt to update the record unless the WAN IP has changed. I ran across a situation where I manually updated the record being monitored by ddns-route53 to a different value. I was expecting ddns-route53 to notice that the current value != WAN IP and therefore update the record but that didn't happen.

Steps to reproduce this issue

1.Start ddns-route53 2.Update the record being monitored by ddns-route53 to any value 3.Wait for ddns-route53 scheduled runs. You'll only see output similar to the following

ddns-route53    | Wed, 16 Feb 2022 07:00:00 EST INF Current WAN IPv4: XXX.XXX.XXX.XXX
ddns-route53    | Wed, 16 Feb 2022 07:00:00 EST INF WAN IPv4/IPv6 addresses have not changed since last update. Skipping...

Expected behaviour

I propose 2 options

1. On each scheduled run ddns-route53 should get the current value of the record being monitored and compare it's value with the WAN IP. If they are different then it should perform the update even if the WAN IP hasn't changed
2. Introduce a new configuration option (e.g. force-update / FORCE_UPDATE) that will always update the record to the WAN IP value regardless of whether the value has changed or not.

Actual behaviour

Record is not updated to WAN IP value

Configuration

• ddns-route53 version : 2.8.0
• Platform (windows/linux) : Docker image on Linux
• docker-compose.yml

version: "3.5"

services:
  ddns-route53:
    container_name: ddns-route53
    environment:
      - "TZ=America/Toronto"
      - "SCHEDULE=*/30 * * * *"
      - "LOG_LEVEL=info"
      - "LOG_JSON=false"
      - "DDNSR53_CREDENTIALS_ACCESSKEYID="
      - "DDNSR53_CREDENTIALS_SECRETACCESSKEY="
      - "DDNSR53_ROUTE53_HOSTEDZONEID="
      - "DDNSR53_ROUTE53_RECORDSSET_0_NAME="
      - "DDNSR53_ROUTE53_RECORDSSET_0_TYPE=A"
      - "DDNSR53_ROUTE53_RECORDSSET_0_TTL=60"
    image: crazymax/ddns-route53:latest
    restart: unless-stopped

[crazy-max]

@sfanous Good point we might also need to check if record matches the actual WAN.