- this adds a new workflow for Github Actions that mirrors what the existing Travis CI workflow tests
- Travis CI might become unfriendly to opensource soonish so migration might be necessary
- update base of Docker image to Alpine 3.19.0 (from 3.18.3 before)
## 3.9.2 (August 10th, 2023)
OTHER:
- update base of Docker image to Alpine 3.18.3 (from 3.18.2 before)
## 3.9.1 (July 6, 2023)
OTHER:
- update base of Docker image to Alpine 3.18.2 (from 3.18.0 before)
## 3.9.0 (June 8, 2023)
IMPROVEMENTS:
- Drop EOL Ruby 2.7 support, now minimum version supported is Ruby 3.0
## 3.8.2 (April 1st, 2023)
OTHER:
- update base of Docker image to Alpine 3.17.3 (from 3.17.2 before)
## 3.8.1 (March 2nd, 2023)
OTHER:
- update base of Docker image to Alpine 3.17.2 (from 3.17.1 before)
## 3.8.0 (January 13th, 2023)
IMPROVEMENTS:
- add Ruby 3.2 support
OTHER:
- update base of Docker image to Alpine 3.17.1 (from 3.17.0 before)
## 3.7.3 (December 29th, 2022)
OTHER:
- update base of Docker image to Alpine 3.17.0 (from 3.16.2 before)
## 3.7.2 (November 10th, 2022)
OTHER:
- re-release 3.7.1 to rebuild Docker image with security vulnerabilities fixes
## 3.7.1 (September 20th, 2022)
IMPROVEMENTS:
- fix [TypeError](https://github.com/cmur2/dyndnsd/issues/205) when user has no hosts configured
## 3.7.0 (September 16th, 2022)
IMPROVEMENTS:
- Update to Rack 3
## 3.6.2 (August 11th, 2022)
OTHER:
- update base of Docker image to Alpine 3.16.2 (from 3.16.1 before)
## 3.6.1 (July 21st, 2022)
OTHER:
- update base of Docker image to Alpine 3.16.1 (from 3.16.0 before)
## 3.6.0 (June 2nd, 2022)
IMPROVEMENTS:
- Drop EOL Ruby 2.6 and lower support, now minimum version supported is Ruby 2.7
OTHER:
- update base of Docker image to Alpine 3.16 (from 3.15.7 before)
## 3.5.3 (May 5th, 2022)
OTHER:
- re-release 3.5.2 to rebuild Docker image with security vulnerabilities fixes
## 3.5.2 (April 7th, 2022)
OTHER:
- re-release 3.5.1 to rebuild Docker image with security vulnerabilities fixes
## 3.5.1 (February 17th, 2022)
OTHER:
- re-release 3.5.0 to rebuild Docker image with security vulnerabilities fixes
## 3.5.0 (January 8th, 2022)
IMPROVEMENTS:
- add Ruby 3.1 support
OTHER:
- update base of Docker image to Alpine 3.15 (from 3.13.7 before, **Note:** please be aware of the quirks around [Alpine 3.14](https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2))
## 3.4.8 (December 11th, 2021)
OTHER:
- re-release 3.4.7 to rebuild Docker image with security vulnerabilities fixes
## 3.4.7 (November 19th, 2021)
OTHER:
- re-release 3.4.6 to rebuild Docker image with security vulnerabilities fixes
## 3.4.6 (November 19th, 2021)
OTHER:
- re-release 3.4.5 to rebuild Docker image with security vulnerabilities fixes
## 3.4.5 (August 26th, 2021)
OTHER:
- re-release 3.4.4 to rebuild Docker image with security vulnerabilities fixes
## 3.4.4 (August 26th, 2021)
OTHER:
- re-release 3.4.3 to rebuild Docker image with security vulnerabilities fixes
## 3.4.3 (August 20th, 2021)
OTHER:
- re-release 3.4.2 to rebuild Docker image with security vulnerabilities fixes
## 3.4.2 (July 30, 2021)
IMPROVEMENTS:
- move from OpenTracing to OpenTelemetry for experimental tracing feature
OTHER:
- re-release 3.4.1 to rebuild Docker image with security vulnerabilities fixes
- adopt Renovate for dependency updates
## 3.4.1 (April 15, 2021)
OTHER:
- update base of Docker image to Alpine 3.13.5 to fix security vulnerabilities
## 3.4.0 (April 2, 2021)
IMPROVEMENTS:
- **change** Docker image to run as non-root user `65534` by default, limits attack surface for security and gives OpenShift compatibility
## 3.3.3 (April 1, 2021)
OTHER:
- update base of Docker image to Alpine 3.13.4 to fix security vulnerabilities
## 3.3.2 (February 20, 2021)
OTHER:
- update to use `docker/build-push-action@v2` for releasing Docker image in GHA
## 3.3.1 (February 18, 2021)
OTHER:
- update base of Docker image to Alpine 3.13.2 to fix security vulnerabilities
## 3.3.0 (January 18, 2021)
OTHER:
- update base of Docker image to Alpine 3.13
## 3.2.0 (January 14, 2021)
IMPROVEMENTS:
- Add Ruby 3.0 support
## 3.1.3 (December 20, 2020)
OTHER:
- fix Docker image release process in Github Actions CI, 3.1.2 was not released as a Docker image
## 3.1.2 (December 20, 2020)
OTHER:
- fixes vulnerabilities in Docker image by using updated Alpine base image
- start using Github Actions CI for tests and drop Travis CI
## 3.1.1 (October 3, 2020)
IMPROVEMENTS:
- Use webrick gem which contains fixes against [CVE-2020-25613](https://www.ruby-lang.org/en/news/2020/09/29/http-request-smuggling-cve-2020-25613/)
## 3.1.0 (August 19, 2020)
IMPROVEMENTS:
- Add officially maintained [Docker image for dyndnsd](https://hub.docker.com/r/cmur2/dyndnsd)
## 3.0.0 (July 29, 2020)
IMPROVEMENTS:
- Drop EOL Ruby 2.4 and lower support, now minimum version supported is Ruby 2.5
## 2.3.1 (July 27, 2020)
IMPROVEMENTS:
- Fix annoying error message `log writing failed. can't be called from trap context` on shutdown by not attempting to log redundant information there
## 2.3.0 (July 20, 2020)
IMPROVEMENTS:
- Allow enabling debug logging
- Add updater that uses [DNS zone transfers via AXFR (RFC5936)](https://tools.ietf.org/html/rfc5936) to allow any secondary nameserver(s) to fetch the zone contents after (optionally) receiving a [DNS NOTIFY (RFC1996)](https://tools.ietf.org/html/rfc1996) request
## 2.2.0 (March 6, 2020)
IMPROVEMENTS:
- Refactor gemspec based on [recommendations](https://piotrmurach.com/articles/writing-a-ruby-gem-specification/) so tests are now excluded from gem and binaries move to `./exe` directory
- Fix potential `nil` cases detected by [Sorbet](https://sorbet.org) including refactorings
## 2.1.0 (March 1, 2020)
IMPROVEMENTS:
- Add Ruby 2.7 support
- Add [solargraph](https://github.com/castwide/solargraph) to dev tooling as Ruby Language Server usable e.g. for IDEs (used solargraph version not compatible with Ruby 2.7 as bundler-audit 0.6.x requires old `thor` gem)
- Document code using YARD tags, e.g. for type information and better code completion
## 2.0.0 (January 25, 2019)
IMPROVEMENTS:
@@ -9,7 +293,7 @@ IMPROVEMENTS:
- Better code maintainability by refactorings
- Update dependencies, mainly `rack` to new major version 2
- Add Ruby 2.5 and Ruby 2.6 support
- Add experimental [OpenTracing](http://opentracing.io/) support with [CNCF Jaeger](https://github.com/jaegertracing/jaeger)
- Add experimental [OpenTracing](https://opentracing.io/) support with [CNCF Jaeger](https://github.com/jaegertracing/jaeger)
- Support host offlining by deleting the associated DNS records
- Add textfile reporter to write Graphite-style metrics (also compatible with [Prometheus](https://prometheus.io/)) into a file
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 are currently two updaters shipped with dyndnsd.rb:
-`zone_transfer_server` that uses [DNS zone transfers via AXFR (RFC5936)](https://tools.ietf.org/html/rfc5936) to allow any secondary nameserver(s) to fetch the zone contents after (optionally) receiving a [DNS NOTIFY (RFC1996)](https://tools.ietf.org/html/rfc1996) request
-`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.
See the [changelog](CHANGELOG.md) before upgrading. The older version 1.x of dyndnsd.rb is still available on [branch dyndnsd-1.x](https://github.com/cmur2/dyndnsd/tree/dyndnsd-1.x).
## General Usage
Install the gem:
@@ -25,14 +29,16 @@ Create a configuration file in YAML format somewhere:
```yaml
# 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
port:80
# 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"
# enable debug mode?
debug:false
# all hostnames are required to be cool-name.example.org
domain:"example.org"
# configure the updater, here we use command_with_bind_zone, params are updater-specific
@@ -58,17 +64,98 @@ users:
Run dyndnsd.rb by:
dyndnsd /path/to/config.yaml
```bash
dyndnsd /path/to/config.yml
```
## 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.
### Docker image
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:
There is an officially maintained [Docker image for dyndnsd](https://hub.docker.com/r/cmur2/dyndnsd) available at Dockerhub. The goal is to have a minimal secured image available (currently based on Alpine) that works well for the `zone_transfer_server` updater use case.
Users can make extensions by deriving from the official Docker image or building their own.
The Docker image consumes the same configuration file in YAML format as the gem, inside the container it needs to be mounted/available as `/etc/dyndnsd/config.yml`. The following YAML should be used as a base and extended with user's settings:
```yaml
host:"0.0.0.0"
port:"8245"# the DynDNS.com alternative HTTP port
port:8080
# omit the logfile: option so logging to STDOUT will happen automatically
db:"/var/lib/dyndnsd/db.json"
# User's settings for updater and permissions follow here!
```
more ports might be needed depending on if DNS zone transfer is needed
Run the Docker image exposing the DynDNS-API on host port 8080 via:
*Note*: You may need to expose more than just port 8080 e.g. if you use the `zone_transfer_server` which can be done by appending additional `-p 5353:5353` flags to the `docker run` command.
## Using dyndnsd.rb with any nameserver via DNS zone transfers (AXFR)
By using [DNS zone transfers via AXFR (RFC5936)](https://tools.ietf.org/html/rfc5936) any secondary nameserver can retrieve the DNS zone contents from dyndnsd.rb and serve them to clients.
To speedup propagation after changes dyndnsd.rb can issue a [DNS NOTIFY (RFC1996)](https://tools.ietf.org/html/rfc1996) to inform the nameserver that the DNS zone contents changed and should be fetched even before the time indicated in the SOA record is up.
Currently, dyndnsd.rb does not support any authentication for incoming DNS zone transfer request, so it should be isolated from the internet on these ports.
This approach has several advantages:
- dyndnsd.rb can be used in *hidden primary* fashion isolated from client's DNS traffic and does not need to implement full nameserver features
- any existing, production-grade, caching, geo-replicated nameserver setup can be used to pull DNS zone contents from the *hidden primary* dyndnsd.rb and serve it to clients
- any nameserver(s) and dyndnsd.rb do not need to be located on the same host
Example dyndnsd.rb configuration:
```yaml
host:"0.0.0.0"
port:8245# the DynDNS.com alternative HTTP port
db:"/opt/dyndnsd/db.json"
domain:"dyn.example.org"
updater:
name:"zone_transfer_server"
params:
# endpoint(s) to listen for incoming zone transfer (AXFR) requests, default 0.0.0.0@53
server_listens:
- 127.0.0.1@5300
# where to send DNS NOTIFY request(s) to on zone content change
send_notifies:
- '127.0.0.1'
# TTL for all records in the zone (in seconds)
zone_ttl:300# 5m
# zone's NS record(s) (at least one)
zone_nameservers:
- "dns.example.org."
# info for zone's SOA record
zone_email_address:"admin.example.org."
# zone's additional A/AAAA records
zone_additional_ips:
- "127.0.0.1"
users:
foo:
password:"secret"
hosts:
- foo.example.org
```
## Using dyndnsd.rb with [NSD](https://www.nlnetlabs.nl/projects/nsd/about/)
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 configuration file.
A feature NSD is lacking is the [Dynamic DNS update (RFC2136)](https://tools.ietf.org/html/rfc2136) functionality BIND offers, but one can fake it using the following dyndnsd.rb configuration:
```yaml
host:"0.0.0.0"
port:8245# the DynDNS.com alternative HTTP port
db:"/opt/dyndnsd/db.json"
domain:"dyn.example.org"
updater:
@@ -93,12 +180,15 @@ users:
Start dyndnsd.rb before NSD to make sure the zone file exists else NSD complains.
## Using dyndnsd.rb with X
Please provide ideas if you are using dyndnsd.rb with other DNS servers :)
## Advanced topics
### Update URL
The update URL you want to tell your clients (humans or scripts ^^) consists of the following
@@ -107,39 +197,45 @@ The update URL you want to tell your clients (humans or scripts ^^) consists of
where:
* the protocol depends on your (webserver/proxy) settings
* 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 commaseparated 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
* the protocol depends on your (webserver/proxy) settings
*`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
*`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`
### IP address determination
The following rules apply:
* use any IP address provided via the myip parameter when present, or
* 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 provided via the `myip` parameter when present, or
* 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
Use a webserver as a proxy to handle SSL and/or multiple listen addresses and ports. DynDNS.com provides HTTP on port 80 and 8245 and HTTPS on port 443.
Use a webserver as a proxy to handle SSL and/or multiple listen addresses and ports. DynDNS.com provides HTTP on port 80 and 8245 and HTTPS on port 443.
### Init scripts
The [Debian 6 init.d script](init.d/debian-6-dyndnsd) assumes that dyndnsd.rb is installed into the system ruby (no RVM support) and the config.yaml is at /opt/dyndnsd/config.yaml. Modify to your needs.
### Startup
There is a [Dockerfile](docs/Dockerfile) that can be used to build a Docker image for running dyndnsd.rb.
The [Debian 6 init.d script](docs/debian-6-init-dyndnsd) assumes that dyndnsd.rb is installed into the system ruby (no RVM support) and the config.yaml is at /opt/dyndnsd/config.yaml. Modify to your needs.
### Monitoring
For monitoring dyndnsd.rb uses the [metriks](https://github.com/eric/metriks) framework and exposes several metrics like the number of unauthenticated requests, requests that did (not) update a hostname, etc. By default the most important metrics are shown in the [proctitle](https://github.com/eric/metriks#proc-title-reporter) but you can also configure a [Graphite](https://graphiteapp.org/) backend for central monitoring or the [textfile_reporter](https://github.com/prometheus/node_exporter/#textfile-collector) which outputs Graphite-style metrics that are also compatible with Prometheus to a file.
For monitoring dyndnsd.rb uses the [metriks](https://github.com/eric/metriks) framework and exposes several metrics like the number of unauthenticated requests, requests that did (not) update a hostname, etc. By default, the most important metrics are shown in the [proctitle](https://github.com/eric/metriks#proc-title-reporter, butt you can also configure a [Graphite](https://graphiteapp.org/) backend for central monitoring or the [textfile_reporter](https://github.com/prometheus/node_exporter/#textfile-collector) which outputs Graphite-style metrics that are also compatible with Prometheus to a file.
```yaml
host:"0.0.0.0"
port:"8245"# the DynDNS.com alternative HTTP port
port:8245# the DynDNS.com alternative HTTP port
db:"/opt/dyndnsd/db.json"
domain:"dyn.example.org"
# configure the Graphite backend to be used instead of proctitle
@@ -172,23 +268,23 @@ users:
password:"ihavenohosts"
```
### 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.
Currently only one OpenTracing-compatible tracer implementation named [CNCF Jaeger](https://github.com/jaegertracing/jaeger) can be configured to use with dyndnsd.rb.
For tracing, dyndnsd.rb is instrumented using the [OpenTelemetry](https://opentelemetry.io/docs/ruby/) framework and will emit span tracing data for the most important operations happening during the request/response cycle. Using an [instrumentation for Rack](https://github.com/open-telemetry/opentelemetry-ruby/tree/main/instrumentation/rack) allows handling incoming OpenTelemetry parent span information properly (when desired, turned off by default to reduce attack surface).
Currently, the [OpenTelemetry trace exporter](https://github.com/open-telemetry/opentelemetry-ruby/tree/main/exporter/jaeger) for [CNCF Jaeger](https://github.com/jaegertracing/jaeger) can be enabled via dyndnsd.rb configuration. Alternatively, you can also enable other exporters via the environment variable `OTEL_TRACES_EXPORTER`, e.g. `OTEL_TRACES_EXPORTER=console`.
```yaml
host:"0.0.0.0"
port:"8245"# the DynDNS.com alternative HTTP port
port:8245# the DynDNS.com alternative HTTP port
db:"/opt/dyndnsd/db.json"
domain:"dyn.example.org"
# enable and configure tracing using the (currently only) tracer jaeger
tracing:
trust_incoming_span:false# default value, change to accept incoming OpenTracing spans as parents
jaeger:
host:127.0.0.1# defaults for host and port of local jaeger-agent
port:6831
service_name:"my.dyndnsd.identifier"
trust_incoming_span:false# default value, change to accept incoming OpenTelemetry spans as parents
service_name:"my.dyndnsd.identifier"# default unset, will be populated by OpenTelemetry
jaeger:true# enables the Jaeger AgentExporter
# configure the updater, here we use command_with_bind_zone, params are updater-specific
updater:
name:"command_with_bind_zone"
@@ -210,6 +306,7 @@ users:
password:"ihavenohosts"
```
## License
dyndnsd.rb is licensed under the Apache License, Version 2.0. See LICENSE for more information.
release_date=$(LC_ALL=en_US.utf8 date +"%B %-d, %Y")
if grep "## $2 (" CHANGELOG.md;then
true
elif grep "## $2" CHANGELOG.md;then
sed -i "s/## $2/## $2 ($release_date)/g" CHANGELOG.md
else
echo"## $2 ($release_date)" >> CHANGELOG.md
fi
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.