Every request is signed
Apply requests carry an RSA-SHA256 signature. The matching public key is published in DNS, so the provider verifies it before touching a zone.
Security
Nothing to take. Everything signed.
RelayDNS asks your customers to let us change their DNS. That deserves a plain account of what we hold, what we do not, and what each part is protected by.
Last updated 22 August 2026
There are no DNS credentials
We hold no provider logins or API tokens for your customers' DNS. There is nothing there to take.
API keys are hashed
Keys are shown once at creation and stored as a SHA-256 digest. We cannot show you a key again, only replace it.
Browser tokens are narrow
The token the widget uses reaches one setup, expires within the hour, and can be pinned to a single origin.
What we do not hold
The strongest part is what is missing. There is no credential here worth stealing.
No DNS provider credentials
No logins, API tokens or nameserver access for your customers' domains, and nowhere in the product to enter them. Records are written by the customer's own provider, after they approve the change.
No control of the zone
We ask for two records under one subdomain. We cannot read the rest of a zone, and we cannot alter it.
No access to the zone apex
Our template places a CNAME under a required host, and refuses to run without one.
Domain Connect
Every request is signed. A changed URL fails.
When a provider supports Domain Connect, we build an apply URL and send your customer to their provider to approve it. The signature covers every parameter, so the target of a record cannot be altered in transit.
The template itself is public and reviewed. It is a fixed set of records with variable values, so a provider running ours can only ever produce the two records on our home page.
Authentication
Four ways in. Four separate keys, and none accepts another's.
Dashboard
Supabase sessionThe signature on every token is verified server side before it is acted on, never merely decoded.
Developer API
Project API keyShown once at creation, stored only as a SHA-256 digest and compared in constant time. We cannot recover a key, only replace it. A session cookie is never accepted here.
Widget
Short lived tokenReaches exactly one setup, expires within the hour, and can be pinned to a single origin. It is designed to be visible in a browser, which is why it can do so little.
Provider callback
Single use valueTied to one setup, with an expiry, and burned when redeemed, so a replayed redirect cannot advance a setup twice.
The API authorises every organisation and project itself rather than trusting an identifier sent by the browser. A resource belonging to another tenant is reported as missing rather than forbidden, so the API does not confirm that it exists.
Data
Sealed at rest. Kept to what each reader needs.
Secrets at rest
Webhook signing secrets are sealed before they reach the database, under a key held only in the server environment. A database copy on its own does not yield them.
Row level security is on for tenant tables. Tables holding credentials and signing material carry no policy at all, so only the API can read them, after it authorises the caller.
What your customers see
The widget is shown to your customer, who does not work for you. It gets only the state of their own setup: the domain, the records, and whether they are live yet.
Internal failure detail is withheld from it. Those messages can describe how you have configured RelayDNS, so they stay in the dashboard, where the audience is you.
Where it runs
Operated by Sukses360 Ltd. Hosted on providers you already know.
Hosting
Vercel, Railway
Database
Supabase
Background work
Inngest
Our own DNS
Cloudflare
Verification
Public recursive resolvers
Verification queries read published DNS records and carry no credentials.
What we have not done
A young service. So this page says what is missing.
No certification
We hold no third party security certification. There is no SOC 2 report and no ISO 27001 certificate.
No penetration test
No independent penetration test has been carried out yet.
No paid bug bounty
Reports are read and answered by a person, but not rewarded.
These will change as the service grows. Until they do, we say so rather than staying quiet.
Reporting a vulnerability
Found something? Tell us.
Say what you found and how to reproduce it. We aim to acknowledge within three working days. Please do not test against domains you do not control or access anyone else's data: report it and we will reproduce it ourselves.