Hetzner DNS provider - request to contribute

Hi,

I noticed CONTRIBUTING.md says external contributions are currently
limited until 1.0, with bug fixes and small well-scoped changes as
the only exception. I’d like to ask whether a self-contained new DNS
provider would qualify, or whether this is something you’d prefer to
defer until contributions reopen.

The work in question:

  1. dns-update: a Hetzner Cloud DNS provider, implementing the
    DnsUpdater trait the same way as the existing DigitalOcean,
    DeSEC, and Bunny providers (including TXT chunking for DKIM).
    PR: Add Hetzner Cloud DNS provider · Pull Request #50 · stalwartlabs/dns-update

  2. stalwart: wires DnsServer::Hetzner through the registry, reusing
    the existing DnsServerCloud struct (no new config shape). The
    change is ~70 lines plus regenerated schema files. Branch is
    pushed at bmack94/stalwart:add-hetzner-dns and ready to open as a
    PR once the restriction is lifted (or if you can grant access for
    this one).

    One note on the stalwart side: I did not include
    resources/schema/schema.json.gz in the branch, since I wasn’t
    sure whether you have a generation mechanism that produces it
    from another source. If you’d like me to commit the regenerated
    artifact as well, just let me know.

Both pieces are tested against a real Hetzner zone for all standard
record types (A, AAAA, CNAME, NS, MX, TXT, SRV, CAA, TLSA).

I’m aware of the FLA requirement and am happy to sign before any
code is merged.

Two things I’d appreciate guidance on:

  • Whether you’d want this contribution now, or prefer I hold it
    until contributions reopen post-1.0.
  • If now: the simplest path on your side — should I open the PR via
    a different mechanism, or would you rather pull from my fork
    directly?

Thanks for your work on Stalwart, and either answer is fine — I’d
rather know than send a PR you can’t review.

Best,
Benedikt

This is a contribution/governance question directed at the Stalwart maintainers — it’s outside what the Help Bot can answer. The maintainers will need to weigh in on whether a new DNS provider qualifies as a “well-scoped change” under the current contribution policy and what the preferred PR workflow is.

A couple of things that may be useful while you wait:

Hi Benedikt, great question and thank you for asking upfront rather than opening a PR without checking first.

Here is what CONTRIBUTING.md says verbatim:

Stalwart is currently not accepting external contributions, except for bug fixes and small, well-scoped changes. … We plan to open the project to broader contributions once we reach a stable 1.0 release.

A new DNS provider (even a well-contained one) sits outside the stated “bug fix / small well-scoped change” exception, so the formal answer per the current policy is: hold it until 1.0.

That said, your proposal is clearly well-prepared (trait-compatible implementation, real-zone testing, FLA acknowledgement, schema question already thought through). The best next step would be to open a GitHub issue in the stalwartlabs/mail-server repo describing the work and explicitly asking the maintainers whether they’d like to grant a one-off exception — that keeps the conversation on record and lets them decide without review pressure. They have said they will update the policy when the time comes, so tagging the issue for post-1.0 triage is also a reasonable outcome.

Regarding schema.json.gz: the maintainers will be best placed to answer whether the artifact should be committed or is regenerated in CI. Worth asking in that same issue.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

This is a contribution/project-governance question directed at the Stalwart maintainers — it’s outside the scope of what the Help Bot can answer, as it requires a decision from the core team.

A staff member will need to respond regarding whether the Hetzner DNS provider PR qualifies as an acceptable contribution under the current pre-1.0 restriction, and what the preferred intake path would be.

Your preparation looks thorough (implementing the existing DnsUpdater trait pattern, real-zone testing, FLA awareness, and keeping the schema artifact question open) — that should make it easy for the maintainers to evaluate quickly.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

Hi, we can only accept contributions to the dns-update crate at this time. We will take care of updating the Stalwart code to use your contributed DNS provider.

Awesome, Hetzner is broadly used.