Skip to content
This repository has been archived by the owner on Feb 9, 2021. It is now read-only.
/ dyndns53 Public archive

Run your own dynamic DNS service with Amazon Route 53

License

Notifications You must be signed in to change notification settings

agorf/dyndns53

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

47 Commits
 
 
 
 
 
 
 
 

Repository files navigation

dyndns53

dyndns53 lets you run your own dynamic DNS service with Amazon Route 53 by updating a domain of your choice with the public IP address of the machine it runs on.

Installation

Install Go and issue:

$ go get github.com/agorf/dyndns53

Configuration

Register a domain name, if you haven't already. Then log in to the AWS management console and follow the steps below.

Step 1: Create a hosted zone

Go to the Route 53 Hosted Zones page and click Create Hosted Zone.

Fill in your domain name in Domain Name and choose Public Hosted Zone for Type, then click Create.

In the hosted zone page, note down the domain names of the Amazon name servers (row with type NS). You need to set them as name servers in your domain name registrar.

Note: DNS propagation usually takes a few hours for newly-registered domain names. If resolving your domain doesn't work, try again later.

Click Back to Hosted Zones and note down the Hosted Zone ID since you will need it in the next step.

Step 2: Create an IAM policy

Go to to the IAM Policies page and click Create Policy.

Click Select on the Policy Generator section.

In the following form, choose Allow for Effect, Amazon Route 53 for AWS Service, ChangeResourceRecordSets for Actions, fill in arn:aws:route53:::hostedzone/<HOSTEDZONEID> for Amazon Resource Name (ARN) (replacing <HOSTEDZONEID> with the one from the previous step) and click Add Statement and then Next Step.

Fill in a name for Policy Name so that you can look up the policy later and click Create Policy.

Step 3: Create an IAM user

Go to the IAM Users page and click the Add user button.

Fill in the user name, check Programmatic access for Access type and click Next: Permissions.

On the permissions page, click the last option Attach existing policies directly and fill in the Search field with the name of the policy you created in the previous step. Click on the policy to check it and click Next: Review.

Click Create user and you will be presented with an Access key ID and a Secret access key (masked), the credentials dyndns53 needs to access the service programmatically. Don't close the window since you will need them in the next step.

Step 4: Create an AWS credentials file

In the machine you plan to run dyndns53, issue:

$ mkdir -p ~/.aws
$ touch ~/.aws/credentials
$ chmod go-r ~/.aws/credentials # prevent other users from reading the file

Edit the file with your editor:

$ $EDITOR ~/.aws/credentials

And write:

[dyndns53]
aws_access_key_id = <ACCESS_KEY_ID>
aws_secret_access_key = <SECRET_ACCESS_KEY>

Replacing <ACCESS_KEY_ID> and <SECRET_ACCESS_KEY> with the actual values you were presented in the previous step.

You are now ready to use dyndns53.

Usage

Running the program with no arguments prints a usage text:

$ dyndns53
Usage of dyndns53:
  -log string
        file name to log to (default is stdout)
  -name value
        record set names (-name domain1 -name domain2 -name domain3 ...)
  -ttl int
        TTL (time to live) in seconds (default 300)
  -type string
        record set type; "A" or "AAAA" (default "A")
  -zone string
        hosted zone id

You can set Cron (with crontab -e) to run the program e.g. every five minutes:

*/5 * * * * ~/go/bin/dyndns53 -name mydomain1 -name mydomain2 -zone HOSTEDZONEID -log ~/dyndns53.log

Where ~/go is your $GOPATH, mydomain1 and mydomain2 are the names of the record sets (domains) you want to update and HOSTEDZONEID is the id of the hosted zone they belong to.

If the record set does not exist, it will be created the first time dyndns53 runs.

Assuming that the IP address changes right after dyndns53 runs (with a default TTL of 5 minutes), the above Cron entry has a worst-case scenario of a 10-minute delay until the domain name resolves to the new IP address (5 minutes until next run that issues the update + 5 minutes for the DNS change to propagate).

License

Licensed under the MIT license (see LICENSE.txt).

Author

Angelos Orfanakos, https://agorf.gr/