crazy-max / ddns-route53 Goto Github PK

View Code? Open in Web Editor NEW

248.0 9.0 35.0 1.82 MB

Dynamic DNS for Amazon Route 53 on a time-based schedule

Home Page: https://crazymax.dev/ddns-route53/

License: MIT License

Dockerfile 15.04% Go 77.77% HCL 7.19%

dynamic-dns ddns ddns-updater amazon aws golang cron scheduler route53 docker

ddns-route53's Introduction

About

ddns-route53 is a CLI application written in Go and delivered as a single executable (and a Docker image) that lets you run your own dynamic DNS service with Amazon Route 53 on a time-based schedule.

Note

Want to be notified of new releases? Check out 🔔 Diun (Docker Image Update Notifier) project!

Documentation

Documentation can be found on https://crazymax.dev/ddns-route53/

Contributing

Want to contribute? Awesome! The most basic way to show your support is to star the project, or to raise issues. You can also support this project by becoming a sponsor on GitHub or by making a PayPal donation to ensure this journey continues indefinitely!

Thanks again for your support, it is much appreciated! 🙏

License

MIT. See LICENSE for more details.

ddns-route53's People

Contributors

Stargazers

Watchers

ddns-route53's Issues

Error adding network: failed to create bridge "cni0": could not add "cni0": operation not supported

Behaviour

Error starting of container.

Steps to reproduce this issue

Updated to /mnt/data/on_boot.d/20-ddns-route53.sh to latest script from install instructions.
Removed ddns-route53 image
Executed sc

Expected behaviour

container starts and updates dns entry with route 53

Actual behaviour

/mnt/data/on_boot.d/20-ddns-route53.sh

Trying to pull docker.io/crazymax/ddns-route53:latest...
Getting image source signatures
Copying blob 552d1f2373af done
Copying blob b52c5e34a143 done
Copying blob 09f832a68278 done
Copying config 2c90573f47 done
Writing manifest to image destination
Storing signatures
ERRO[0003] Error adding network: failed to create bridge "cni0": could not add "cni0": operation not supported
ERRO[0003] Error while adding pod to CNI network "podman": failed to create bridge "cni0": could not add "cni0": operation not supported
Error: error configuring network namespace for container c1d9b8f10d2d4fe3a9962d79708376fd57056d65d8210021c06b650fe6b3acc7: failed to create bridge "cni0": could not add "cni0": operation not supported

Configuration

ddns-route53 version :
Platform (windows/linux) :
System info (type uname -a) :

# paste your YAML configuration file here and remove sensitive data

credentials:
accessKeyID: "KEY REDACTED"
secretAccessKey: "REDACTED"

route53:
hostedZoneID: "HOSTZONE REDACTED"
recordsSet:
- name: "NAME REDACTED"
type: "A"
ttl: 300
- name: "NAME REDACTED"
type: "AAAA"
ttl: 300

Logs

# paste logs here (set log level to debug first)

Empty

Request to https://v4.ident.me returns "connection refused"

Behaviour

Running using docker image fails to retrieve the IP from https://v4.ident.me.

ddns-route53    | Mon, 04 Jan 2021 19:04:29 EST INF Starting ddns-route53 version=2.2.0
ddns-route53    | Mon, 04 Jan 2021 19:04:29 EST INF Configuration loaded from file: /ddns-route53.yml
ddns-route53    | Mon, 04 Jan 2021 19:04:30 EST ERR Cannot retrieve WAN IPv4 address error="request failed: Get \"https://v4.ident.me/\": dial tcp 0.0.0.0:443: connect: connection refused"
ddns-route53    | Mon, 04 Jan 2021 19:04:30 EST INF Cron initialized with schedule 0 */5 * * * *
ddns-route53    | Mon, 04 Jan 2021 19:04:30 EST INF Next run in 29 seconds (2021-01-04 19:05:00 -0500 EST)

Steps to reproduce this issue

Run docker-compose up with the following docker-compose file

version: "3.5"
services:
  ddns-route53:
    image: crazymax/ddns-route53:latest
    restart: always
    container_name: ddns-route53
    volumes:
      - ./ddns-route53.yml:/ddns-route53.yml:ro
    environment:
      - "TZ=America/New_York"
      - "SCHEDULE=0 */5 * * * *"
      - "LOG_LEVEL=info"
      - "LOG_JSON=false"

Output returns an error:

ddns-route53    | Mon, 04 Jan 2021 19:10:37 EST INF Starting ddns-route53 version=2.2.0
ddns-route53    | Mon, 04 Jan 2021 19:10:37 EST INF Configuration loaded from file: /ddns-route53.yml
ddns-route53    | Mon, 04 Jan 2021 19:10:38 EST ERR Cannot retrieve WAN IPv4 address error="request failed: Get \"https://v4.ident.me/\": dial tcp 0.0.0.0:443: connect: connection refused"
ddns-route53    | Mon, 04 Jan 2021 19:10:38 EST INF Cron initialized with schedule 0 */5 * * * *
ddns-route53    | Mon, 04 Jan 2021 19:10:38 EST INF Next run in 4 minutes (2021-01-04 19:15:00 -0500 EST)

Expected behaviour

Should retrieve IP from v4.ident.me and update route 53

Actual behaviour

Fails to retrieve IP from https://v4.ident.me with "connection refused"

Configuration

ddns-route53 version :
Platform (windows/linux) :
System info (type uname -a) :

cat ddns-route53.yml

credentials:
  accessKeyID: "###########################"
  secretAccessKey: "###########################"

route53:
  hostedZoneID: "###########################"
  recordsSet:
    - name: "#######.#######."
      type: "A"
      ttl: 180
    # - name: "another.example2.com."
    #   type: "A"
    #   ttl: 300

Logs

$ docker-compose up
Recreating ddns-route53 ... done
Attaching to ddns-route53
ddns-route53    | Mon, 04 Jan 2021 19:15:55 EST INF Starting ddns-route53 version=2.2.0
ddns-route53    | Mon, 04 Jan 2021 19:15:55 EST INF Configuration loaded from file: /ddns-route53.yml
ddns-route53    | Mon, 04 Jan 2021 19:15:55 EST DBG No DDNSR53_* environment variables defined
ddns-route53    | Mon, 04 Jan 2021 19:15:55 EST DBG {
ddns-route53    |   "credentials": {
ddns-route53    |     "accessKeyID": "###########################",
ddns-route53    |     "secretAccessKey": "###########################"
ddns-route53    |   },
ddns-route53    |   "route53": {
ddns-route53    |     "hostedZoneID": "###########################",
ddns-route53    |     "recordsSet": [
ddns-route53    |       {
ddns-route53    |         "name": "#######.#######.",
ddns-route53    |         "type": "A",
ddns-route53    |         "ttl": 180
ddns-route53    |       }
ddns-route53    |     ]
ddns-route53    |   }
ddns-route53    | }
ddns-route53    | Mon, 04 Jan 2021 19:15:56 EST ERR Cannot retrieve WAN IPv4 address error="request failed: Get \"https://v4.ident.me/\": dial tcp 0.0.0.0:443: connect: connection refused"
ddns-route53    | Mon, 04 Jan 2021 19:15:56 EST INF Cron initialized with schedule 0 */5 * * * *
ddns-route53    | Mon, 04 Jan 2021 19:15:56 EST INF Next run in 4 minutes (2021-01-04 19:20:00 -0500 EST)

Really appreciate this useful utility, it would be great if I could figure out what is causing the issue here, or somehow specify a different IP lookup command such as dig +short myip.opendns.com @resolver1.opendns.com. Thanks!

Multiple Domains

Description

Is there a way to configure this script for multiple domains and sub-domains?

Getting a 403 error

I tried searching already the past issues and can't find any solution. I changed my accessKeyID and secretAccessKey and restarted the docker image and no cigar. Not sure what else to try?

The security token included in the request is invalid.

stuck in "WRN Already running"

Behaviour

Steps to reproduce this issue

restart your fw/router
add some luck
ddns-route-53 is stuck
after restarting ddns-route-53 it instantly updates my DNS records

Expected behaviour

ddns-route53 is not stuck

Actual behaviour

ddns-route53 is stuck

Configuration

ddns-route53 version : v2.9.0
Platform (windows/linux) : linux
System info (type uname -a) : Linux espresso 6.1.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 18 Jan 2023 19:54:38 +0000 x86_64 GNU/Linux

running in docker

    environment:
      - "TZ=Europe/Paris"
      - "SCHEDULE=*/1 * * * *"
      - "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"

Logs

i am sorry, i did not have loglevel set to debug. i will try to reproduce and update the logs later.

ddns-route53  | Tue, 24 Jan 2023 00:56:01 CET INF Next run in 59 seconds 952 milliseconds (2023-01-24 00:57:00 +0100 CET)
ddns-route53  | Tue, 24 Jan 2023 00:58:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 00:59:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:00:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:01:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:02:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:03:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:04:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:05:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:06:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:07:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:08:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:09:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:10:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:11:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:12:00 CET WRN Already running
ddns-route53  | Tue, 24 Jan 2023 01:12:07 CET WRN Caught signal terminated

Support AWS Environment Variables in Route53 Session Creations

It'd be pretty handy to support passing AWS security context through environment variables in addition configuration section - specifically this would enable storing and pass credentials using mechanisms such as Kubernetes secrets.

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Specifically the *Configuration.Check method demands credentials get loaded from the file. Seems like the shortest path is to look for the environment variables if the credential block is not fully populated. I'll take a look later and maybe come back with a PR.

Systemd service

What would be the preferred way to run this in the background, and have it restarted upon system reboots?

Error getting IPv6 address when running in Docker

When I run ddns-route53 on Docker, I'm getting the following error:

Cannot get WAN IPv6 address error="Get https://v6.ident.me/: dial tcp [2a01:7e00::f03c:91ff:fe70:2b9d]:443: connect: cannot assign requested address"

When I run it from the binary on the same machine, it successfully updates my AAAA record.

Save the last IP to save API requests to Routeu53

Description

Sometimes you would like to have a DNS Update every minute, but normally it is not neccesary.

To avoid making so many API Requests to Route53 it would be nice to have a last_known_ip file somewhere to check if the IP has changed and only update on changes.

I saw this on https://github.com/sjmayotte/route53-dynamic-dns which I was testing before, but the multi record sets in that repo did not work stable.

Automatically detect timezone by mounting /etc/localtime in docker

Hi, i have a suggestion,

It's a known practice to mount /etc/localtime in read only to deduce the timezone.

Deployment and execution of docker failing on UDM Pro

Behaviour

Running on Unifi Dream Machine Pro fails on first startup.

Steps to reproduce this issue

Followed instructions outlined in https://crazymax.dev/ddns-route53/install/unifi-os/
Execute service for first time.

Expected behaviour

Service starts with no errors.

Actual behaviour

Startup of service produces the following error.

# /mnt/data/on_boot.d/20-ddns-route53.sh
Trying to pull docker.io/crazymax/ddns-route53:latest...
Getting image source signatures
Copying blob b538f80385f9 done
Copying blob a3ca3f385fd2 done
Copying blob f03d88339f6b done
Copying blob 28c7e7792935 done
Copying blob 7dc23cf6ac8b done
Copying config 9985eb89eb done
Writing manifest to image destination
Storing signatures
ERRO[0005] Error adding network: failed to find plugin "loopback" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin]
ERRO[0005] Error while adding to cni lo network: failed to find plugin "loopback" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin]
Error: error configuring network namespace for container a16cce8dae48b8bb68e37580b4053d3f2ec7a7b74951bfe9c4706a51384f9c4e: failed to find plugin "loopback" in path [/usr/libexec/cni /usr/lib/cni /usr/local/lib/cni /opt/cni/bin]

Configuration

ddns-route53 version : latest
Platform (windows/linux) : UDM Pro
System info (type uname -a) : Linux FTLGATE 4.1.37-v1.8.0.2888-8f25fa3 #1 SMP Wed Aug 19 13:02:14 MDT 2020 aarch64 GNU/Linux

credentials:
  accessKeyID: "redacted"
  secretAccessKey: "redacted"

route53:
  hostedZoneID: "redacted"
  recordsSet:
    - name: "redacted.net."
      type: "A"
      ttl: 300
    - name: "redacted.net."
      type: "AAAA"
      ttl: 300

Logs

# paste logs here (set log level to debug first)

None Produced

General Question: can i use an apex domain with this tool?

I currently use this with a subdomain and love it but running my blog I wanted to resolve an apex domain to a CNAME which recursively points to the A record that this docker updates with my home IP. However you can’t CNAME apex (root domain names) in AWS. Wondering if I can add just the root address as an A record and this will update it?

Multiple zones (multiple hostedZoneID)

It would help me a lot if it was possible to configure multiple zones (multiple hostedZoneID) in the YAML. I have alias domains, I prefer to use A and AAAA records than CNAME.

Documentation: one-shot mode

Description

Update the documentation so that readers will know that the program does not need to run as a daemon. That it runs in a one-shot mode when schedule is not provided.

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

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

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

2.0.0 docker image segfaults / crashes seemingly on any configuration, appears to not read credentials correctly

Behaviour

segfault is on this line: accessKeyID, err := utl.GetSecret(cfg.Credentials.AccessKeyID, cfg.Credentials.AccessKeyIDFile)

I specify my AWS credentials using the bog-standard environment variables.

Steps to reproduce this issue

Migrate a v1 config and environment variables to v2
Observe the following error:

{"level":"info","version":"2.0.0","time":"2020-08-05T02:50:25Z","message":"Starting ddns-route53"}

{"level":"info","time":"2020-08-05T02:50:25Z","message":"Configuration loaded from file: /etc/ddns-route53/ddns-route53.yml"}

{"level":"info","time":"2020-08-05T02:50:25Z","message":"Configuration loaded from 1 environment variables"}

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x9a769e]


goroutine 1 [running]:

github.com/crazy-max/ddns-route53/v2/internal/app.New(0xae1659, 0xc, 0xae1659, 0xc, 0xafdda8, 0x38, 0xaf6969, 0x29, 0xb01233, 0x58, ...)

	/app/internal/app/ddnsr53.go:39 +0x3e

main.main()

	/app/cmd/main.go:82 +0x8c7

Expected behaviour

The application should run.

Actual behaviour

It segfaults compared to v1.

Configuration

ddns-route53 version : 2.0.0
Platform (windows/linux) : linux

Working v1

route53:
  records_set:
    - name: "*.example.com"
      type: "A"
      ttl: 300

    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - AWS_HOSTED_ZONE_ID=${AWS_HOSTED_ZONE_ID}
      - LOG_JSON=true
      - SCHEDULE=@every 10s

Crashing v2

route53:
  recordsSet:
    - name: "*.example.com"
      type: "A"
      ttl: 300

    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - DDNSR53_ROUTE53_HOSTEDZONEID=${AWS_HOSTED_ZONE_ID}
      - LOG_JSON=true
      - SCHEDULE=@every 10s

Trouble setting SCHEDULE via k3s/TrueCharts

First, thank you for making this. It works great and is exactly what I needed after finding Route53 support missing from ddns-updater.

I do have an issue trying to run this in a docker container that's being configured by k3s/TrueCharts. The SCHEDULE value doesn't sanitize well and can't be provided. I can provide configuration via the yaml file, but it doesn't appear that SCHEDULE is supported this way.

It would be awesome if it could be configured from the yaml route.

Configuration Passed in by Environment Variables doesn't Seem to be Validated

Behaviour

I am using this image as part of an Ansible deployment, and a typo in my playbook resulted in an extra curly brace being inserted into the domain name (because the configs are templated from variables - the result was e.g. subdomain.example.com}.)
I am passing in configuration via environment variables in the podman args, as in the docs here
This means that I had a route53 container up for about two weeks with an invalid configuratioin, and a domain it wasn't ever going to be able to change. Because my IP remained stable for a good long time, it continued happily, and it was only when I had an outage today I was assigned a new IP and errors revealed themselves.

Steps to reproduce this issue

Recreate the example from the docs for configuration via environment variables
Change DDNSR53_ROUTE53_RECORDSSET_0_NAME from ddns.example.com. to an (I believe) illegal domain ddns.example.com}. - or try any other symbol that obviously should be erroneous for any sane setup.

Expected behaviour

If possible, on startup, it'd be ideal to verify that the domain specified can be updated, without actually updating it - this way any issues that would occur dewn the line would be pre-emptively found before an update is needed.
Alternatively, perform validation of domains (and other configs, I don't know if you do this alrerady) passed in to ensure they are legal as the minimum.

Actual behaviour

It was only on trying to update the IP address with AWS that what would (as far as I know) be an invalid domain name was identified

Configuration

ddns-route53 version : c6652645eff7 from Docker Hub
Platform (windows/linux) : Podman, rootless, Focal host
System info (type uname -a) : N/A for container

Logs

Afraid I lost these as I had to get this machine restarted ASAP, so the container had to be pulled down and I cleared my terminal. It should be simple enough to recreate however, simply enter an extra symbol into the domain name, before the final dot. I remember that this came out as an escape sequecne. I presume it'll be straightforward, but if there are nay issues recreating I can get back to you.

Thanks for providing this!!

Make Hosted Zone ID + Route53 Credentials support Docker Secrets with _FILE Suffix

Description

It would be really nice to have the possibility to use Docker Secrets on the following ENVs

DDNSR53_CREDENTIALS_ACCESSKEYID
DDNSR53_CREDENTIALS_SECRETACCESSKEY
DDNSR53_ROUTE53_HOSTEDZONEID

The ENVs should support the _FILE suffix to get it working like this:

DDNSR53_CREDENTIALS_ACCESSKEYID_FILE
DDNSR53_CREDENTIALS_SECRETACCESSKEY_FILE
DDNSR53_ROUTE53_HOSTEDZONEID_FILE

So you can use the docker stack in a more save manner and create the docker secrets before you run the stack in a excrypted manner https://docs.docker.com/engine/reference/commandline/secret_create/

version: '3.9'

services:

  ddns-route53:
    image: crazymax/ddns-route53:latest
    secrets:
      - AWS_HOSTED_ZONE_ID_EXAMPLE_COM
      - AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY
    environment:
      - TZ=Europe/Amsterdam
      - SCHEDULE=* * * * *
      - LOG_LEVEL=info
      - LOG_JSON=false
      - DDNSR53_CREDENTIALS_ACCESSKEYID_FILE=/run/secrets/AWS_ACCESS_KEY_ID
      - DDNSR53_CREDENTIALS_SECRETACCESSKEY_FILE=/run/secrets/AWS_SECRET_ACCESS_KEY
      - DDNSR53_ROUTE53_HOSTEDZONEID_FILE=/run/secrets/AWS_HOSTED_ZONE_ID_EXAMPLE_COM
      - DDNSR53_ROUTE53_RECORDSSET_0_NAME=domain.example.com
      - DDNSR53_ROUTE53_RECORDSSET_0_TYPE=A
      - DDNSR53_ROUTE53_RECORDSSET_0_TTL=60
      
      
secrets:
  # AWS DNS
  AWS_HOSTED_ZONE_ID_EXAMPLE_COM:
    name: AWS_HOSTED_ZONE_ID_EXAMPLE_COM
    external: true
  AWS_ACCESS_KEY_ID:
    name: AWS_ACCESS_KEY_ID
    external: true
  AWS_SECRET_ACCESS_KEY:
    name: AWS_SECRET_ACCESS_KEY
    external: true

ttl not updated if ip does not change

Behaviour

Steps to reproduce this issue

change your TTL config
restart ddns-route53

Expected behaviour

The DNS records TTL gets adjusted.

Actual behaviour

ddns-route53 reports that our WAN ip did not change and does nothing

Using CONFIG environment variable doesn't work in Docker

Behaviour

Steps to reproduce this issue

Create a docker container with config pointed to a file
Run docker container
Fail

Expected behaviour

File should be loaded based on CONFIG environment variable path

Actual behaviour

Dockerfile --config argument path is used instead

Logs

Tue, 21 Sep 2021 21:04:51 PDT INF Starting ddns-route53 version=2.7.0
Tue, 21 Sep 2021 21:04:51 PDT DBG No configuration file found
Tue, 21 Sep 2021 21:04:51 PDT DBG No DDNSR53_* environment variables defined
Tue, 21 Sep 2021 21:04:51 PDT FTL Cannot load configuration error="route53 configuration required"

I was able to get this running by overridding the CMD when calling the docker container to use the value that was in my CONFIG environment variable, but I'd rather not have to do that as it feels hacky.

Custom message in spanish

Hi,

Please let me know how can translate message to Spanish, or let me know how can modify and compile again.

Thanks

TZ setting getting ignored?

Support guidelines

I've read the support guidelines

I've found a bug and checked that ...

... the documentation does not mention anything about my problem
... there are no open or closed issues that are related to my problem

Description

ddns-route53 container seems to ignore TZ variable

Expected behaviour

environment:
  - "TZ=Europe/Helsinki"

expecting that Europe/Helsinki time is used by container and shown in logs

Actual behaviour

UTC time is used instead (off by 2 hours)

Tue, 16 Jan 2024 20:46:52 UTC INF Starting ddns-route53 version=v2.11.0
Tue, 16 Jan 2024 20:46:52 UTC INF Configuration loaded from 9 environment variables
Tue, 16 Jan 2024 20:46:52 UTC INF Current WAN IPv4: censored
Tue, 16 Jan 2024 20:46:53 UTC INF WAN IPv4 has not changed for my.little.domain. record set
Tue, 16 Jan 2024 20:46:53 UTC WRN No Route53 record set to update. Skipping...
Tue, 16 Jan 2024 20:46:53 UTC INF Cron initialized with schedule */30 * * * *
Tue, 16 Jan 2024 20:46:53 UTC INF Next run in 13 minutes 6 seconds (2024-01-16 21:00:00 +0000 UTC)

Steps to reproduce

Deploy container as follows:

version: "3.5"

services:
ddns-route53:
image: crazymax/ddns-route53:latest
container_name: ddns-route53
environment:
- "TZ=Europe/Helsinki"
- "SCHEDULE=*/30 * * * *"
- "LOG_LEVEL=info"
- "LOG_JSON=false"
- "DDNSR53_CREDENTIALS_ACCESSKEYID=censored"
- "DDNSR53_CREDENTIALS_SECRETACCESSKEY= censored"
- "DDNSR53_ROUTE53_HOSTEDZONEID= censored"
- "DDNSR53_ROUTE53_RECORDSSET_0_NAME=censored."
- "DDNSR53_ROUTE53_RECORDSSET_0_TYPE=A"
- "DDNSR53_ROUTE53_RECORDSSET_0_TTL=600"
- "DDNSR53_ROUTE53_RECORDSSET_1_NAME= censored."
- "DDNSR53_ROUTE53_RECORDSSET_1_TYPE=A"
- "DDNSR53_ROUTE53_RECORDSSET_1_TTL=600"
restart: always

ddns-route53 version

v2.11.0

Docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc.)
    Version:  v2.17.3
    Path:     /usr/local/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 4
  Paused: 0
  Stopped: 0
 Images: 4
 Server Version: 23.0.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 5.13.0.x
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.544GiB
 Name: cerberus
 ID: 5bc02020-8a7e-4a5d-8160-f0e7200c3b88
 Docker Root Dir: /volume1/.@plugins/AppCentral/docker-ce/docker_lib
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Docker Compose config

no configuration file provided: not found

Logs

Tue, 16 Jan 2024 20:54:57 UTC INF Starting ddns-route53 version=v2.11.0
Tue, 16 Jan 2024 20:54:57 UTC DBG No configuration file found
Tue, 16 Jan 2024 20:54:57 UTC INF Configuration loaded from 9 environment variables
Tue, 16 Jan 2024 20:54:57 UTC DBG {
  "credentials": {
    "accessKeyID": "censored",
    "secretAccessKey": "censored"
  },
  "route53": {
    "hostedZoneID": "censored",
    "recordsSet": [
      {
        "name": "censored",
        "type": "A",
        "ttl": 600
      },
      {
        "name": "censored",
        "type": "A",
        "ttl": 600
      }
    ]
  }
}
Tue, 16 Jan 2024 20:54:57 UTC INF Current WAN IPv4: censored
Tue, 16 Jan 2024 20:54:58 UTC INF WAN IPv4 has not changed for censored. record set
Tue, 16 Jan 2024 20:54:58 UTC INF WAN IPv4 has not changed for censored. record set
Tue, 16 Jan 2024 20:54:58 UTC WRN No Route53 record set to update. Skipping...
Tue, 16 Jan 2024 20:54:58 UTC INF Cron initialized with schedule */30 * * * *
Tue, 16 Jan 2024 20:54:58 UTC INF Next run in 5 minutes 1 second (2024-01-16 21:00:00 +0000 UTC)

Additional info

Other containers on the same system (MariaDB, Pi-hole) do not exhibit this issue and respect the TZ value set in docker compose during their operation.

Multiarch package? Not working on armv7.

Behaviour

Steps to reproduce this issue

Pulling to ODROID-HC2 as a NAS running OpenMediaVault
docker-compose up resulting in "exec format error"

Expected behaviour

Container should run. Works from amd64 desktop (Windows10).

Actual behaviour

Creating ddns-route53 ... done
Attaching to ddns-route53
ddns-route53 | standard_init_linux.go:211: exec user process caused "exec format error"
$ uname -a
Linux odroidnas 4.14.133-odroidxu4 #2 SMP PREEMPT Tue Jul 16 19:33:01 CEST 2019 armv7l GNU/Linux

Configuration

ddns-route53 version : latest
Platform (windows/linux) : Debian GNU/Linux 9.9 (stretch)
Docker:

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:35:21 2019
 OS/Arch:           linux/arm
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:29:21 2019
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

credentials:
  access_key_id: "keyid"
  secret_access_key: "key"

route53:
  hosted_zone_id: "Zone"
  records_set:
    - name: "intranet.example.com."
      type: "A"
      ttl: 300

annot update records set error="SignatureDoesNotMatch:

ERR Cannot update records set error="SignatureDoesNotMatch: Signature expired: 20191218T101837Z is
now earlier than 20191218T102749Z (20191218T103249Z - 5 min.)\n\tstatus code: 403, request id: b326bb3d-70b0-45c0-a24f-ec712ba8bf
a6"

Cannot retrieve WAN IPv4 address

Support guidelines

I've read the support guidelines

I've found a bug and checked that ...

... the documentation does not mention anything about my problem
... there are no open or closed issues that are related to my problem

Description

component	details
ddns-route53	latest docker image
server A	the one running this docker image
server B	the proxy server that forwards network traffic to server A, using wireguard server-to-server tunnel

Problem: ddns-route53 is using server B instead of server A IPv4

I think the issue is due to wireguard server-to-server tunnel

Browser

If I open these in browser

https://ipv4.nsupdate.info/myip
https://ipv4.wtfismyip.com/text
https://ipv4.yunohost.org
https://v4.ident.me

They show server A IPv4 address. Good

Terminal

If I curl -k these in server A terminal

https://ipv4.nsupdate.info/myip
https://ipv4.wtfismyip.com/text
https://ipv4.yunohost.org
https://v4.ident.me

They show server B IPv4 address. Bad

Disable wireguard

If I disable the wireguard server-to-server tunnel, they show server A IPv4 address. This is why I conclude wireguard is the cause.

Expected behaviour

ddns-route53 adds server A IPv4 to route53 A record.

While keeping the current wireguard server-to-server tunnel up.

Actual behaviour

ddns-route53 adds server B IPv4 to route53 A record

Steps to reproduce

Install ddns-route53 docker image in server A, and configure it
Server B (proxy server) install wireguard server-to-server tunnel that forwards all traffic to Server A

ddns-route53 version

v2.11.0

Docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc.)
    Version:  v2.21.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 45
  Running: 25
  Paused: 0
  Stopped: 20
 Images: 45
 Server Version: 23.0.6
 Storage Driver: btrfs
  Btrfs: 
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 nvidia
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.34-Unraid
 Operating System: Slackware 15.0 x86_64 (post 15.0 -current)
 OSType: linux
 Architecture: x86_64
 CPUs: 24
 Total Memory: 125.7GiB
 Name: Something
 ID: 77c1a25d-3397-4b29-a350-583ea75fbba2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: No swap limit support

Docker Compose config

No response

Logs

{"level":"error","error":"Get \"https://ipv4.nsupdate.info/myip\": GET https://ipv4.nsupdate.info/myip giving up after 4 attempt(s): Get \"https://ipv4.nsupdate.info/myip\": net/http: TLS handshake timeout","provider-url":"https://ipv4.nsupdate.info/myip","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
{"level":"error","error":"Get \"https://ipv4.nsupdate.info/myip\": GET https://ipv4.nsupdate.info/myip giving up after 4 attempt(s): Get \"https://ipv4.nsupdate.info/myip\": net/http: TLS handshake timeout","provider-url":"https://ipv4.nsupdate.info/myip","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://v4.ident.me\": GET https://v4.ident.me giving up after 4 attempt(s): Get \"https://v4.ident.me\": net/http: TLS handshake timeout","provider-url":"https://v4.ident.me","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
{"level":"error","error":"Get \"https://ipv4.nsupdate.info/myip\": GET https://ipv4.nsupdate.info/myip giving up after 4 attempt(s): Get \"https://ipv4.nsupdate.info/myip\": net/http: TLS handshake timeout","provider-url":"https://ipv4.nsupdate.info/myip","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://v4.ident.me\": GET https://v4.ident.me giving up after 4 attempt(s): Get \"https://v4.ident.me\": net/http: TLS handshake timeout","provider-url":"https://v4.ident.me","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://ipv4.yunohost.org\": GET https://ipv4.yunohost.org giving up after 4 attempt(s): Get \"https://ipv4.yunohost.org\": net/http: TLS handshake timeout","provider-url":"https://ipv4.yunohost.org","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
{"level":"error","error":"Get \"https://ipv4.nsupdate.info/myip\": GET https://ipv4.nsupdate.info/myip giving up after 4 attempt(s): Get \"https://ipv4.nsupdate.info/myip\": net/http: TLS handshake timeout","provider-url":"https://ipv4.nsupdate.info/myip","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://v4.ident.me\": GET https://v4.ident.me giving up after 4 attempt(s): Get \"https://v4.ident.me\": net/http: TLS handshake timeout","provider-url":"https://v4.ident.me","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://ipv4.yunohost.org\": GET https://ipv4.yunohost.org giving up after 4 attempt(s): Get \"https://ipv4.yunohost.org\": net/http: TLS handshake timeout","provider-url":"https://ipv4.yunohost.org","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}
,"error":"Get \"https://ipv4.wtfismyip.com/text\": GET https://ipv4.wtfismyip.com/text giving up after 4 attempt(s): Get \"https://ipv4.wtfismyip.com/text\": net/http: TLS handshake timeout","provider-url":"https://ipv4.wtfismyip.com/text","time":"2024-01-08T08:33:13Z","message":"Cannot retrieve WAN IPv4 address"}

Additional info

No response

Add the ability to specify an interface

When using a dual WAN setup in a load balancing configuration, it is unknown over which interface the request will go. This can be achieved using a custom Transport, as explained here.

I can produce a pull-request for this around the coming weekend.

[Feature] AWS Cloudfront CDN to hide origin IP

Hi @crazy-max , thanks for this awesome library and documentation, works flawlessly. 😁

Wonder if we can mask/hide origin IP in route53? By adding AWS Cloudfront as optional config?

Inspired from Cloudflare. It offers a nice security feature which hides the origin IP and returns a proxy one when a DNS lookup is performed against the domain. This is helpful in preventing direct attacks to the domain's origin IP.

Allow disabling IPv6

The program always tries to fetch an IPv6, regardless whether AAAA records are configured.
This leads to warnings in the logs on every update.

Suggestion: Allow disabling the IPv6 lookup, or only do the lookup if an AAAA record has been defined in config.

Documentation detailing the IP source

Description

Hi - love the project!

Documentation needs a single line that clearly describes where the IP address used is sourced from.
Would save having to install to find out it does not work as expected.

unRAID Docker unable to update records

Behaviour

I am not able to update 'A' or 'AAAA' records in route53 after docker installation with unRAID.

Steps to reproduce this issue

Create tokens
Create a configuration file using the official documentation
Create initial records in route53 with values "127.0.0.1" for record "A" and "::1" for record "AAAA"
Install ddns-route53 through Community Applications plugin in unraid
add configuration information to /mnt/user/appdata/ddns-route53/ddns-route53.yml using unRAID browser terminal and nano
Click apply

Expected behaviour

I expect that the 'A' record for the specified subdomain will have updated values in Route53
I expect that ipv6 will not be acquired so "AAAA" should not change

Actual behaviour

Neither the 'A' or 'AAAA' record is updating in route53

Configuration

ddns-route53 version : crazymax/ddns-route53:latest
Platform (windows/linux) : unRaid 6.8.3
System info (type uname -a) : Linux unRaid-NA 4.19.107-Unraid #1 SMP Thu Mar 5 13:55:57 PST 2020 x86_64 AMD Ryzen 5 3600X 6-Core Processor AuthenticAMD GNU/Linux

credentials:
  accessKeyID: "AXXXXXXXXXXXXXXXXXX"
  secretAccessKey: "R+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

route53:
  hostedZoneID: "ZXXXXXXXXXXXXXXXXXC"
  recordsSet:
    - name: “unraid-na.example.com.”
      type: "A"
      ttl: 300
    - name: “unraid-na.example.com.”
      type: "AAAA"
      ttl: 300

Logs

�[90mSun, 06 Sep 2020 15:26:03 PDT�[0m �[32mINF�[0m Starting ddns-route53 �[36mversion=�[0m2.0.1
�[90mSun, 06 Sep 2020 15:26:03 PDT�[0m �[32mINF�[0m Configuration loaded from file: /ddns-route53.yml
�[90mSun, 06 Sep 2020 15:26:03 PDT�[0m �[33mDBG�[0m No DDNSR53_* environment variables defined
�[90mSun, 06 Sep 2020 15:26:03 PDT�[0m �[33mDBG�[0m {
"credentials": {
"accessKeyID": "AXXXXXXXXXXXXXXXXXX",
"secretAccessKey": "R+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
},
"route53": {
"hostedZoneID": "ZXXXXXXXXXXXXXXXXXC",
"recordsSet": [
{
"name": "“unraid-na.example.com.”",
"type": "A",
"ttl": 300
},
{
"name": "“unraid-na.example.com.”",
"type": "AAAA",
"ttl": 300
}
]
}
}
�[90mSun, 06 Sep 2020 15:26:04 PDT�[0m �[32mINF�[0m Current WAN IPv4: 135.23.XXX.XXX
�[90mSun, 06 Sep 2020 15:26:04 PDT�[0m �[1m�[31mERR�[0m�[0m Cannot retrieve WAN IPv6 address �[31merror=�[0m�[31m"request failed: Get https://v6.ident.me/: dial tcp [2a01:7e00::f03c:91ff:fe70:2b9d]:443: connect: network is unreachable"�[0m

�[90mSun, 06 Sep 2020 15:26:04 PDT�[0m �[1m�[31mERR�[0m�[0m No WAN IPv6 address available to update “unraid-na.iremadze.com.” record
�[90mSun, 06 Sep 2020 15:26:05 PDT�[0m �[1m�[31mERR�[0m�[0m Cannot update records set �[31merror=�[0m�[31m"InvalidInput: Invalid XML ; cvc-complex-type.2.4.b: The content of element 'Change' is not complete. One of '{\"https://route53.amazonaws.com/doc/2013-04-01/\":Action, \"https://route53.amazonaws.com/doc/2013-04-01/\":ResourceRecordSet}' is expected.\n\tstatus code: 400, request id: 1c887be7-3c9c-4c9b-8c60-53fc17d26bb6"�[0m
�[90mSun, 06 Sep 2020 15:26:05 PDT�[0m �[32mINF�[0m 2 records set updated �[36mchanges=�[0m{"ChangeInfo":null}
�[90mSun, 06 Sep 2020 15:26:05 PDT�[0m �[32mINF�[0m Cron initialized with schedule */30 * * * *
�[90mSun, 06 Sep 2020 15:26:05 PDT�[0m �[32mINF�[0m Next run in 3 minutes (2020-09-06 15:30:00 -0700 PDT)

[Feature] Run once on startup

Loving this project, thank you so much!

Somewhat unimportant feature request but would it be possible to execute a once-off DNS sync on start-up? Would be nice for testing purposes and being sure that it actually works so you don't have to come back in 30min or more.

crazy-max / ddns-route53 Goto Github PK

ddns-route53's Introduction

About

Documentation

Contributing

License

ddns-route53's People

Contributors

Stargazers

Watchers

Forkers

ddns-route53's Issues

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

/mnt/data/on_boot.d/20-ddns-route53.sh

Configuration

Logs

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Logs

Description

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Logs

Description

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Logs

Description

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Configuration

Logs

Description

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Behaviour

Steps to reproduce this issue

Expected behaviour

Actual behaviour

Logs

Support guidelines

I've found a bug and checked that ...

Description

Expected behaviour

Actual behaviour

Steps to reproduce

ddns-route53 version

Docker info

Docker Compose config

Logs

Additional info

Behaviour

Steps to reproduce this issue

Expected behaviour