Features

We hold the domain and answer for it. That is why a wildcard, a certificate for a machine on a private address, DNSSEC, and your own CAA record are ordinary API calls here rather than a reason to run your own DNS.

The hostname

Move the machine, keep the name

The hostname does not encode the address, so changing the address does not invalidate it. Move the machine between hosts, regions or providers, PUT the new one, and every client holding the URL keeps working. A name with the address built into it cannot do that: change the address and it is a different name.

Name the subdomain, or let us

Send one and it is yours, or leave the field out and we mint one that says nothing about what is behind it or where it runs. A subdomain you choose is abuse-scanned, and the check is the same whether you are one developer or a platform minting thousands.

Choose the domain

Holding several dedicated domains lets you pick which one a hostname is minted on, so you can separate environments or tenants across domains rather than stacking them in one namespace. The API takes a domain on any plan; what you choose is how many you hold.

Your own records

Publish TXT, TLSA, CAA, MX, SRV, SSHFP, HTTPS and SVCB records under a hostname through the API. Domain verification strings and service metadata, which CA may issue for your name, an MX so the hostname receives mail, a SRV for anything not on 443, an SSH host key a client can verify before it connects, an HTTPS record advertising HTTP/3 or carrying an Encrypted ClientHello config. Up to 10 records per hostname, on every plan. TLSA becomes publishable once a domain is signed.

Point it at a platform, not just an address

Some platforms hand you a URL and no address at all, so there is nothing to register. Send a target instead of an IP and the hostname follows that endpoint: we resolve it and serve ordinary A and AAAA records, refreshed within the target's own TTL. Not a CNAME, which would hand the address behind your name to whoever runs the target and could not sit beside the CAA, TLSA and other records a hostname carries. Your issuer policy and every record under the name keep working.

Certificates

DNS-01 certificate API

Every hostname can return its own DNS-01 credential. We publish the challenge record on our side, so the certificate authority never opens a connection to your machine. That is what makes the two cases below possible at all, and it is the reason to be here rather than at a DNS host.

Machines the internet cannot reach

HTTP-01 validation requires the CA to connect back to the host. Anything behind NAT, on an internal network, or without port 80 fails that test and cannot get a publicly trusted certificate by that route. Register the private address and validate over DNS-01 instead, and a machine nothing on the public internet can reach still holds a real certificate.

Wildcards

Let's Encrypt will not issue a wildcard over HTTP-01, by design. DNS-01 is the only path, so a wildcard covering every subdomain of your hostname is an ordinary request rather than a reason to stand up your own nameserver.

The clients you already use

Every one of them needs an API key and nothing else. Caddy and cert-manager through modules we maintain, lego and Traefik through their built-in httpreq provider, certbot through a hook script it already supports. The DNS-01 API also speaks the acme-dns protocol, for a client that expects it. One recipe per client is on the integrations page.

Credentials scoped to one hostname

A DNS-01 credential publishes the challenge record for the hostname it was issued for and nothing else. A zone-wide token handed to an ACME client can usually rewrite or delete every record in the zone, which is a lot of authority to leave on a machine you do not fully control.

Any CA

Our domains carry a CAA record naming Let's Encrypt and Google Trust Services, so a CA that should not be issuing for your hostname cannot. That is a default, not a limit: publish your own CAA record on your hostname and it applies instead - ZeroSSL, Buypass, an internal CA, whatever you run. Deleting it puts ours back.

Certificate modeselfcsrmanaged
Who generates the private keyYouYouUs
Who ends up holding itYouYouYou, and us until you release the hostname
Who answers the DNS-01 challengeYour client, through the APIUsUs
Who renewsYouYou, by sending a fresh requestUs, before it expires
What you send usNothingA certificate request you signedNothing

The domain

A dedicated domain

A dedicated domain is a domain assigned to your team alone. A registrable domain is the unit browsers use for cookie scope, the unit Let's Encrypt counts certificates against, and the unit a blocklist applies to; sharing one means sharing all three. Every account gets one, including Starter.

We are the registrant

We register, renew, delegate, and defend the domain. There is no registrar account to hold, no renewal to miss, no ICANN registrant verification, and no WHOIS record to keep accurate. A lapsed renewal takes down every hostname under it at once, and that is our problem rather than yours.

DNSSEC, before the hostname is live

Every domain is signed and its DS published at the registry before anything on it serves. Both are gates, not later steps - and the DS half is the one usually skipped, because a signed zone nobody can find the DS for is not protected and a resolver cannot tell it was meant to be. On a domain you brought yourself this is a chain you finish by hand, or do not.

Several domains, and scale beneath them

Hold as many dedicated domains as you need and mint beneath them through the same API, so a platform can issue hostnames for its own customers and put each one on a dedicated domain. Same endpoints a single developer uses.

You cannot move it to your own registrar

A dedicated domain is yours alone to use and stays registered to us, so it is not an asset you can move to a registrar account of your own. When a subscription ends we release the hostnames on it and revoke their certificates, so they stop resolving then, and the domain is not renewed. That is the trade for a name meant to be disposable - an agent's endpoint, a preview, a device - and the wrong one for a name you need to keep.

Resolution

Answered directly, never queued

A lookup is answered by the nameserver that received it and waits on nothing else, so resolution does not slow down because something else of ours is busy.

Registration can be down; resolution is not

The nameservers and the rest of the product are separate systems, so an outage in one is not an outage in the other. If registration or the dashboard were unavailable, existing hostnames carry on resolving.

Pending until the nameservers answer

A new hostname reads pending until the nameservers holding its zone have been seen answering for it, then flips to live. Your tooling can wait on that instead of sleeping and hoping.

A TTL that follows the address

An address that has just moved is served with a short TTL, so a change propagates quickly. The same address held still earns a longer one, up to an hour, so a stable hostname stops paying for lookups it does not need. You get the responsiveness of a low TTL without setting one and living with it forever, and a zone can carry its own ceiling if that is too long or not long enough.

Lifecycle

Release, and take it back

Releasing stops DNS at once and revokes any certificate we hold. The subdomain returns to you immediately and can be minted again, because nobody else is on your domain and so there is no one else who could ever receive it.

An account and an activity log

Every create, update, and release is recorded and readable later. Not one shared login and no record of who changed what.

Built for programs

Queries and reads are unlimited

DNS queries and API reads are unlimited on every plan, under a published fair use policy. We sell namespace, not consumption, so a hostname that gets popular does not cost more to keep reachable. Registration, updates and record writes carry technical rate limits, which is the one place a hard limit exists.

Four endpoints

The hostname lifecycle is four endpoints: create, read, update, release. The quickstart goes from a bare IP to working HTTPS with one POST and an ACME client, and there is an OpenAPI 3.1 description of the whole surface.

An agent can ask for the name itself

An MCP server at https://dnsmint.com/mcp lets an agent mint a hostname, repoint it, diagnose it and release it mid-task, rather than needing a person to have written the config first. Add the URL as a connector in Claude or ChatGPT and choose what it may do, or send an API key from Claude Code, Cursor or VS Code. What a connector is offered follows what you granted it, and you can disconnect it at any time.

Written to be read by a machine

The reference is published as plain text at /llms-full.txt alongside the OpenAPI spec, so an agent reading the docs does not have to parse a marketing site to find out how the API works.

What we do not do

We never touch your traffic

We answer DNS queries and stop. Nothing is proxied, terminated, or inspected, so there is no provider in the request path whose outage is your outage, whose latency is added to yours, and whose bandwidth bill grows as you get popular. It is also why unlimited queries are solvent for us to offer.

We never connect to your infrastructure

Nothing we run opens a connection to a machine you registered. Everything moves in one direction, from you to us.

We do not hide the address

The hostname keeps it out of logs, referrer headers and certificate transparency entries, which is where an address usually leaks. Anyone who resolves the name gets it.

For what people build on this, see use cases. For how it stacks up against the alternatives, see the comparisons. To try it, the quickstart goes from a bare IP to HTTPS with one POST and an ACME client.

Need something that is not here? hello@dnsmint.com. We would rather hear that we are missing something than have you work around it quietly - and if we have decided against it on purpose, standards says so and why.