hoster.by module for Caddy

This package contains a DNS provider module for Caddy. It can be used to manage DNS records with hoster.by through libdns/hosterby.

Caddy module name

dns.providers.hosterby

Build

xcaddy build --with github.com/caddy-dns/hosterby

Config examples

To use this module for the ACME DNS challenge, configure the ACME issuer in your Caddy JSON like so:

{
	"module": "acme",
	"challenges": {
		"dns": {
			"provider": {
				"name": "hosterby",
				"access_key": "{env.HOSTERBY_ACCESS_KEY}",
				"secret_key": "{env.HOSTERBY_SECRET_KEY}"
			},
			"propagation_delay": "2m"
		}
	}
}

or with the Caddyfile:

# globally
{
	cert_issuer acme {
		dns hosterby {
			access_key {env.HOSTERBY_ACCESS_KEY}
			secret_key {env.HOSTERBY_SECRET_KEY}
		}
		propagation_delay 2m
	}
}

# one site
tls {
	dns hosterby {
		access_key {env.HOSTERBY_ACCESS_KEY}
		secret_key {env.HOSTERBY_SECRET_KEY}
	}
	propagation_delay 2m
}

access_key and secret_key are the keys of a hoster.by API service account. For the ACME DNS challenge, the keys need permissions to list the DNS hosting services and to list, add, change and delete TXT records. See libdns/hosterby for how to get the keys and for caveats.

At the time of writing, the hoster.by API fails to return the records of internationalized zones such as .бел, so certificates for them can't be obtained yet.

Propagation delay

At the time of writing, a new record appears on u2.hoster.by about a minute after it appears on u1.hoster.by (59 to 60 seconds in four measurements). Caddy considers the record propagated once one nameserver returns it, so without a delay Let's Encrypt queries u2 too early and the challenge fails with NXDOMAIN. A propagation_delay of 2 minutes worked in all tests.