The Developer Kit
The DNSid Developer Kit is the open-source toolset for building with DNSid: three SDKs, the dnsid CLI with the DNSid Local environment, a cookbook of runnable recipes, and the conformance suite that ties them together. It is Apache-2.0, implements the open protocol (draft-ihsanullah-dnsid), and lives under github.com/dnsid-ai.
Start here
Section titled “Start here”| I want to | Do this |
|---|---|
| Try the full lifecycle on my laptop | Install the CLI, run dnsid local up, and follow the DNSid Local quickstart |
| Build with Go | go get github.com/dnsid-ai/dnsid-go |
| Build with TypeScript | npm install @dnsid-ai/sdk @dnsid-ai/transport |
| Build with Python | pip install "git+https://github.com/dnsid-ai/dnsid-py.git" |
| See working examples | Clone the cookbook and run a recipe |
| Publish an identity on my own domain | Publish self-managed records with any SDK |
What’s in the kit
Section titled “What’s in the kit”| Component | What it does | Status |
|---|---|---|
| Go SDK | Verify, sign (RFC 9421 and JWT/JWS), OIDC, registry lifecycle, C2SP log verification, and an AWS KMS key provider. | Available—dnsid-go |
| TypeScript SDK | Same surface, runtime-neutral core with a Node transport. | Available—dnsid-ts |
| Python SDK | Same surface, Python-native. Resolves through the system resolver by default, or a DNS-over-HTTPS endpoint you configure. | Available—dnsid-py |
| Conformance suite | The neutral definition of “DNSid-conformant”: IETF-draft-derived test vectors run against every SDK, with a cross-language interoperability matrix. How new language SDKs get built and verified. | Available—dnsid-sdk-compliance |
| Cookbook | Runnable recipes—publish a record, protect an HTTP API, A2A and LangGraph agents, edge verification, and more. Each runs on DNSid Local. | Available—dnsid-cookbook |
| CLI | Identity operations, record inspection and verification, and the dnsid local environment. | Binaries available via Homebrew, Scoop, or the install script; source coming soon |
| DNSid Local | The complete lifecycle—registration, issuance, verification, revocation—in Docker on your laptop. No real DNS records, no account. | Ships with the CLI; source coming soon |
| C2SP witness | A deployable transparency-log witness for independently verifying DNSid lifecycle logs. | Coming soon |
| Reference registry | A self-hostable implementation of the DNSid registry API. | In design |
Every open-source component ships with CI, a documented release process, and a security policy.
How the pieces fit together
Section titled “How the pieces fit together”“Kit” means the pieces are tested together, not just shipped together. The conformance suite runs one IETF-draft-derived vector set against all three SDKs on every change and reports which SDK versions are verified interoperable.
The conformance suite is also the on-ramp for new languages: implement the vectors, pass the matrix, and a community SDK is a first-class member of the ecosystem.
Where identities live
Section titled “Where identities live”A DNSid identity lives in one of two places. On DNSid Local, the full lifecycle runs on your machine with local DNS, TLS, registry, and lifecycle log, and nothing leaves your laptop. On a domain you own, you host the record, JWKS, and status endpoint, and anyone on the internet can verify it. Start on Local, then publish on your own domain. The SDK code is the same in both, and Environments explains what changes.
What’s not in the kit
Section titled “What’s not in the kit”The protocol itself. It lives at the IETF as draft-ihsanullah-dnsid; the kit implements it and does not define it. Protocol changes go through the standards process.
Licensing and contributions
Section titled “Licensing and contributions”Every component is Apache-2.0 with a public issue tracker. To build an integration, an SDK in a new language, or a recipe, start from the conformance suite or the cookbook’s recipe template.