cn/dyndnsd
1
0
Fork 0
mirror of https://github.com/cmur2/dyndnsd.git synced 2024-12-21 14:54:22 +01:00
Code Releases Activity

docs: fix minor typos in README

Browse Source 
Fix minor typos (#46)
This commit is contained in:
Sam Umbach 2020-03-20 06:09:05 -04:00 committed by GitHub
parent c112b211a0
commit cb3977b553
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
README.md
View File

@ -6,9 +6,9 @@ A small, lightweight and extensible DynDNS server written with Ruby and Rack.
## Description
dyndnsd.rb aims to implement a small [DynDNS-compliant](https://help.dyn.com/remote-access-api/) server in Ruby supporting IPv4 and IPv6 addresses. It has an integrated user and hostname database in it's configuration file that is used for authentication and authorization. Besides talking the DynDNS protocol it is able to invoke a so-called *updater*, a small Ruby module that takes care of supplying the current hostname => ip mapping to a DNS server.
dyndnsd.rb aims to implement a small [DynDNS-compliant](https://help.dyn.com/remote-access-api/) server in Ruby supporting IPv4 and IPv6 addresses. It has an integrated user and hostname database in its configuration file that is used for authentication and authorization. Besides talking the DynDNS protocol it is able to invoke a so-called *updater*, a small Ruby module that takes care of supplying the current hostname => ip mapping to a DNS server.
There is currently one updater shipped with dyndnsd.rb `command_with_bind_zone` that writes out a zone file in BIND syntax onto the current system and invokes a user-supplied command afterwards that is assumed to trigger the DNS server (not necessarily BIND since it's zone files are read by other DNS servers, too) to reload it's zone configuration.
There is currently one updater shipped with dyndnsd.rb `command_with_bind_zone` that writes out a zone file in BIND syntax onto the current system and invokes a user-supplied command afterwards that is assumed to trigger the DNS server (not necessarily BIND since its zone files are read by other DNS servers, too) to reload its zone configuration.
Because of the mechanisms used, dyndnsd.rb is known to work only on \*nix systems.
@ -26,12 +26,12 @@ Create a configuration file in YAML format somewhere:
# listen address and port
host: "0.0.0.0"
port: "80"
# optional: drop priviliges in case you want to but you may need sudo for external commands
# optional: drop privileges in case you want to but you may need sudo for external commands
user: "nobody"
group: "nogroup"
# logfile is optional, logs to STDOUT else
# logfile is optional, logs to STDOUT otherwise
logfile: "dyndnsd.log"
# interal database file
# internal database file
db: "db.json"
# all hostnames are required to be cool-name.example.org
domain: "example.org"
@ -62,7 +62,7 @@ Run dyndnsd.rb by:
## Using dyndnsd.rb with [NSD](https://www.nlnetlabs.nl/nsd/)
NSD is a nice opensource, authoritative-only, low-memory DNS server that reads BIND-style zone files (and converts them into it's own database) and has a simple config file.
NSD is a nice, open source, authoritative-only, low-memory DNS server that reads BIND-style zone files (and converts them into its own database) and has a simple config file.
A feature NSD is lacking is the [Dynamic DNS update](https://tools.ietf.org/html/rfc2136) functionality BIND offers but one can fake it using the following dyndnsd.rb config:
@ -111,7 +111,7 @@ where:
* USER and PASSWORD are needed for HTTP Basic Auth and valid combinations are defined in your config.yaml
* DOMAIN should match what you defined in your config.yaml as domain but may be anything else when using a webserver as proxy
* PORT depends on your (webserver/proxy) settings
* HOSTNAMES is a required list of comma separated FQDNs (they all have to end with your config.yaml domain) the user wants to update
* HOSTNAMES is a required list of comma-separated FQDNs (they all have to end with your config.yaml domain) the user wants to update
* MYIP is optional and the HTTP client's IP address will be used if missing
* MYIP6 is optional but if present also requires presence of MYIP
@ -123,7 +123,7 @@ The following rules apply:
* use any IP address provided via the X-Real-IP header e.g. when used behind HTTP reverse proxy such as nginx, or
* use any IP address used by the connecting HTTP client
If you want to provide an additional IPv6 address as myip6 parameter the myip parameter containing an IPv4 address has to be present, too! No automatism is applied then.
If you want to provide an additional IPv6 address as myip6 parameter, the myip parameter containing an IPv4 address has to be present, too! No automatism is applied then.
### SSL, multiple listen ports
@ -174,7 +174,8 @@ users:
### Tracing (experimental)
For tracing dyndnsd.rb is instrumented using the [OpenTracing](http://opentracing.io/) framework and will emit span tracing data for the most important operations happening during the request/response cycle. Using a middleware for Rack allows handling incoming OpenTracing span information properly.
For tracing, dyndnsd.rb is instrumented using the [OpenTracing](http://opentracing.io/) framework and will emit span tracing data for the most important operations happening during the request/response cycle. Using a middleware for Rack allows handling incoming OpenTracing span information properly.
Currently only one OpenTracing-compatible tracer implementation named [CNCF Jaeger](https://github.com/jaegertracing/jaeger) can be configured to use with dyndnsd.rb.
```yaml