Go to file
Kevin MacMartin 7a54e0b4e0 Use the private repo for includes 2019-05-16 23:31:33 -04:00
api Update comments and names according to go lint. 2015-05-07 22:00:05 -04:00
dyndns Use the private repo for includes 2019-05-16 23:31:33 -04:00
log Update comments and names according to go lint. 2015-05-07 22:00:05 -04:00
scripts Fix description. systemd prints out 'Starting [description' in log. 2015-05-10 17:08:09 -04:00
.gitignore Initial code commit 2015-04-30 00:18:08 -04:00
.travis.yml Update build version 2016-03-05 03:03:52 -05:00
LICENSE Initial commit 2015-04-29 18:27:41 -04:00
README.md Only update A domains, since we're mapping to an IP. 2017-01-18 18:54:55 -05:00
main.go Use the private repo for includes 2019-05-16 23:31:33 -04:00

README.md

name-dyndns Build Status GoDoc

Client that automatically updates name.com DNS records.

Getting name-dyndns

Since name-dyndns has no external dependencies, you can get it simply by:

go get github.com/mfycheng/name-dyndns

Requirements

In order to use name-dyndns, you must have an API key from name.com, which can be requested from https://www.name.com/reseller/apply.

Once you have your API key, all you must do is setup config.json. An example config.json file can be found in api/config_test.json.

Command Line Arguments

By default, running name-dyndns will run a one-time update, using ./config.json as a configuration file, and stdout as a log output. However, these can be configured. For example:

./name-dyndns -daemon=true -dev=true -log="/var/log/name-dyndns/out.log" -config="~/name_config.json"

This will run name-dyndns in daemon mode for dev configurations, outputting to /var/log/name-dyndns/out.log, using the configuration file ~/name_config.json

A detailed usage can be found by running:

./name-dyndns --help

Error Handling

Currently, there is limited testing, primarily on name-api dependant utilities. While error handling should be done gracefully, not every edge case has been tested.

Ideally, when running in daemon mode, name-dyndns tries to treat any errors arising from network as transient failures, and tries again next iteration. The idea behind this is that a single network failure shouldn't kill the daemon, which could then potentially result in having the DNS records out of sync, which would defeat the whole point of name-dyndns.