Adding support for new DNS providers is fairly easy. You can probably expect to have it working in a day or less, but exacting the behavior and handling edge cases will take time and experience with your provider of choice. (There's no hurry to get it perfect right away.)

Since the libdns maintainers do not have an account with every DNS provider in the world, we rely on you to build and maintain the packages you use.

1. File an issue to claim your provider.
2. Refer to this template repository to help bootstrap your new package.
3. After you have it working, make a pull request to either the libdns/libdns or libdns/template repos so it can be reviewed in-line. Once approved, the pull request will not be merged. Instead, we'll close the PR and make a new repository in the libdns organization for your provider and give you push access. We'll also make one at caddy-dns for the associated Caddy plugin.
4. Push your code to the new repository.
5. Maintain the code and respond to issues and pull requests.

We only maintain the providers we use. If you use a certain provider, please do your part in maintaining its package, thank you!

These are some things we look for in code reviews before accepting new implementations:

• Adhere to the libdns godoc for both package-wide semantics and individual methods/interfaces.
• Have proper code documentation: all exported fields, methods, and functions must have helpful godoc comments.
• Use json struct tags for all fields of configuration and use "snake_case,omitempty" convention. Along with consistency, it will allow these packages to be used in a variety of projects. For example, Caddy requires JSON struct tags. All exported fields should either be JSON-serializable or omitted from JSON serialization (json:"-").
• Run go mod tidy before committing; the go.mod and go.sum files must be minimal and orderly (whitespace included).
• The package should have tests or at least be tested. Since testing often requires a live account, we don't run them in CI -- but we need 1) evidence that you have tested it, and, ideally 2) the ability for anyone else to sit down and plug in their own provider credentials and run the tests and see them pass.
• Stick to the Go standard library for testing whenever possible/feasible. (Try to avoid third-party testing packages.)
• Please try to minimize dependencies. The net/http package can get you pretty far with less bloat than most libraries. Use discretion so that any imported libraries are worth their weight.
• Cgo is not allowed; it must be a pure Go implementation, including all dependencies.
• Shelling out to external processes is not allowed unless the essence of the provider is on the command line (this is a very niche case).
• Configuration must be primarily through struct fields. Environment variables are allowed, but should only be used as defaults.
• Each exported method must be safe for concurrent use (i.e. thread-safe) in the sense that there must be no data races. Each provider API may have different atomicity guarantees. Two simultaneous method calls must result in either an error or the expected outcome of each call to be applied successfully.
• Explicit/exported provisioning steps should be avoided. They break a package's drop-in-replacement-ability with other packages because the user has to know to first provision certain types before using them. Instead of requiring explicit provisioning, try to do it implicitly in each exported method that relies on it. If provisioning is expensive, it can be done just once by storing it in the struct (this requires synchronization for thread-safety) or by using sync.Once (which does the synchronization for you) the first time it is needed.
• Your code must be licensed with an open source license compatible with MIT, Apache, and BSD families of licenses. (This usually excludes GPL and variants - sorry.)
• There must be a helpful README that describes the various config parameters, any env variables used, caveats, etc.

We'll help you work through any issues we find as we go through the review process, not to worry! We want more libraries, so we will help you get it in.

• We have a template repository you can start with.
• go-acme/lego has well over 70 DNS provider implementations that just set and delete TXT records. You might refer to them for ideas. But please don't copy their code.
• StackExchange/dnscontrol has a couple dozen DNS provider implementations that support a wider variety of functions. You can also refer to them for ideas. But please don't copy their code.