Originally created by @ukleinek on GitHub (Dec 18, 2024).
When using dns-01 challenge and several certificates in a single DNS zone are to be created/renewed there are more serial bumps involved than theoretically needed. Consider certs for A.example.org and B.example.org are to be created/renewed. Then
the deploy_challenge handler is invoked twice -- once for each domain. In the first invocation it's not known to the hook if another one follows, so the DNS update for the first domain needs to bump the zone's serial and trigger a notify to the slaves. This is also an issue if the serial is based on the current time (seconds since epoch is a usual scheme used here) and the two updates are triggered in the same second. Also the first invocation has to block until all secondaries are updated, just to wait a second time in the second invocation.
However in a bulk_deploy_challenge hook all challenges could be passed together and then only a single serial bump + notify (per domain) + wait would be needed.
Symmetrically for clean_challenge.
Originally created by @ukleinek on GitHub (Dec 18, 2024).
When using dns-01 challenge and several certificates in a single DNS zone are to be created/renewed there are more serial bumps involved than theoretically needed. Consider certs for A.example.org and B.example.org are to be created/renewed. Then
the `deploy_challenge` handler is invoked twice -- once for each domain. In the first invocation it's not known to the hook if another one follows, so the DNS update for the first domain needs to bump the zone's serial and trigger a notify to the slaves. This is also an issue if the serial is based on the current time (seconds since epoch is a usual scheme used here) and the two updates are triggered in the same second. Also the first invocation has to block until all secondaries are updated, just to wait a second time in the second invocation.
However in a `bulk_deploy_challenge` hook all challenges could be passed together and then only a single serial bump + notify (per domain) + wait would be needed.
Symmetrically for `clean_challenge`.
This sounds a lot like what HOOK_CHAIN already does, which for deploy/clean challenge hooks, supplies a list of all host names and they tokens, one hook call per cert, instead of per challenge.
@jobe1986 commented on GitHub (Dec 20, 2024):
This sounds a lot like what HOOK_CHAIN already does, which for deploy/clean challenge hooks, supplies a list of all host names and they tokens, one hook call per cert, instead of per challenge.
See [docs/hook_chain.md](https://github.com/dehydrated-io/dehydrated/blob/master/docs/hook_chain.md) for more information.
Just to be clear: HOOK_CHAIN sounds nice and goes in the right direction, but it's less than I suggested. Default behaviour is one call per challenge, HOOK_CHAIN reduces that to one call per certificate, ideally I'd want one call overall.
@ukleinek commented on GitHub (Dec 20, 2024):
Just to be clear: `HOOK_CHAIN` sounds nice and goes in the right direction, but it's less than I suggested. Default behaviour is one call per challenge, `HOOK_CHAIN` reduces that to one call per certificate, ideally I'd want one call overall.
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.
Originally created by @ukleinek on GitHub (Dec 18, 2024).
When using dns-01 challenge and several certificates in a single DNS zone are to be created/renewed there are more serial bumps involved than theoretically needed. Consider certs for A.example.org and B.example.org are to be created/renewed. Then
the
deploy_challengehandler is invoked twice -- once for each domain. In the first invocation it's not known to the hook if another one follows, so the DNS update for the first domain needs to bump the zone's serial and trigger a notify to the slaves. This is also an issue if the serial is based on the current time (seconds since epoch is a usual scheme used here) and the two updates are triggered in the same second. Also the first invocation has to block until all secondaries are updated, just to wait a second time in the second invocation.However in a
bulk_deploy_challengehook all challenges could be passed together and then only a single serial bump + notify (per domain) + wait would be needed.Symmetrically for
clean_challenge.@jobe1986 commented on GitHub (Dec 20, 2024):
This sounds a lot like what HOOK_CHAIN already does, which for deploy/clean challenge hooks, supplies a list of all host names and they tokens, one hook call per cert, instead of per challenge.
See docs/hook_chain.md for more information.
@ukleinek commented on GitHub (Dec 20, 2024):
Just to be clear:
HOOK_CHAINsounds nice and goes in the right direction, but it's less than I suggested. Default behaviour is one call per challenge,HOOK_CHAINreduces that to one call per certificate, ideally I'd want one call overall.