DNS hosting

DNS hosting is the authoritative side of Dinio: you host your domains on it, and Dinio’s nameservers answer for them to everyone on the internet. Everything on this page belongs to a zone, and access to it is access to that zone.

Tip

Looking for blocking ads, trackers or malware for your own devices? That is the other service, DNS filtering.

Zones

A zone is a domain you host on Dinio, such as example.com. Whoever creates a zone becomes its Owner; Dinio creates the apex SOA and NS records for it at the same time. A zone has a uuid, but anywhere a zone is referenced you can also use its name.

Deleting a zone deletes everything in it: records, health checks, geo bans, redirects and certificates.

Dinio can suspend a zone, for example for abuse. Dinio’s nameservers refuse queries for a suspended zone; you can still read it and delete it, but every change to it is refused with 403 SUSPENDED. A zone shows this in suspended, and in owner_suspended when its Owner’s account is suspended.

Free domains

Dinio offers some free domains: you can take a subdomain of one, such as myhome.example.net, as a zone of your own — a lease. A lease is an ordinary zone that you own, with its own SOA and NS, and Dinio delegates it from the free domain. The name is a single label of 3–63 letters, digits and hyphens, and some names are reserved (www, mail, admin, …). How many leases you can have is set by your package; leases don’t count as zones there. See Free domains.

Zone files

A zone can be exported as a file and records can be imported from one: Dinio’s own JSON document (with geo bans, health checks and redirects, and names relative to the zone, so it also works as a template for another zone), a BIND zone file, or CSV. An import only adds what the zone doesn’t have yet — it never changes or deletes anything.

Moving a domain from another provider, Dinio can discover its records: it asks the current nameservers about the names a zone usually has, and returns them as a file to review and import. Discovery finds common names, not every record. See Zone files.

Record sets and values

DNS answers come from record sets (RRsets): all records with the same owner name and type, such as every A record at www.example.com. Dinio models this directly:

• A record set is identified by (zone, name, type). It has no uuid of its own. Its TTL belongs to the set — every value in it shares one TTL.
• A record value is one member of the set, such as 192.0.2.1. Each value has its own uuid and its own options:

Option	Meaning
geo_routing	Answer with this value by the client’s location.
balance_ratio	Weight among the values of the set (0–65535).
host_health	Whether the value counts as healthy: None, Up, Down or Auto — see Health checks.

Adding the first value creates the set (that is when its TTL is set); removing the last value removes it. TTL changes go through a separate, set-level operation.

The options only apply where they make sense: geo_routing and balance_ratio choose among the values of an address set, so they are for A and AAAA. Health checks (and host_health) work for A, AAAA, SRV and MX; geo bans for A, AAAA, SRV and CNAME. Other combinations are refused — see Options by type.

Records Dinio keeps

Some values exist because of something else, and are marked with managed_by:

managed_by	What it is	Can you change it?
System	The zone’s apex SOA and NS, created with the zone; for a lease, also its delegation NS in the free domain.	Yes — but NS pointing elsewhere means the zone stops using Dinio’s nameservers. The SOA and the last apex NS can’t be removed.
Redirect	The CNAME (or apex A/AAAA) that points a redirect’s name at Dinio.	No. Change or delete the redirect instead.
Acme	The _acme-challenge TXT used while a certificate is issued. Gone within minutes.	No.

Values without managed_by are your own.

Names

The API stores and expects full names: www.example.com, lowercase, without the trailing dot. The CLI and the SDKs’ name helpers also accept zone-file style names: @ for the apex, www relative to the zone, and other.org. (trailing dot) as absolute.

Validation

Every write is checked against DNS rules before it is stored: the name must be inside the zone, the type must be supported, the data must be valid for the type, and the change must keep the zone consistent (for example, a CNAME must be the only record at its name, and two identical values cannot exist in one set). A rejected write returns every violated rule — see Errors.

Supported types: A, AAAA, CAA, CDNSKEY, CDS, CNAME, CSYNC, DNSKEY, DS, HINFO, HTTPS, MX, NAPTR, NS, OPENPGPKEY, PTR, SOA, SRV, SSHFP, SVCB, TLSA, TXT.

Health checks

A health check belongs to one record value — at most one per value. It probes a target over http, tcp or ping on an interval, from every 30 seconds to once a day (your package may set a longer minimum), and keeps the last result (HEALTHY, UNHEALTHY or UNKNOWN).

Whether a value counts as healthy is decided by its host_health mode. An unhealthy value is left out of answers, and its weight goes to the healthy values of the set.

host_health	The value is	The health check
None (default)	always served	doesn’t run
Auto	served while the check passes	runs
Up	always served (forced)	stays configured, paused
Down	never served (forced) — e.g. for maintenance	stays configured, paused

Creating a check switches its value to Auto; removing the check turns Auto back into None. Auto needs a check. To take a value out for maintenance, set it to Down, then back to Auto. A value on Auto counts as healthy until the first run says otherwise.

Geo bans

A geo ban hides one record value from clients in an area: a country (ISO 3166-1 numeric code, e.g. 191 for Croatia), a sub-region or a region (UN M49 codes, e.g. 150 for Europe). A value can have many bans. Dinio publishes the list of areas and their codes (GET /geo); the CLI and SDKs read it and accept names and ISO codes (HR, Croatia, Europe) instead of numbers. Every area and its codes are listed in Geo areas.

Members

Zone access for people is held by zone members: the zone’s single Owner, and any number of Administrators the Owner adds. Administrators can manage everything in the zone — records, health checks, geo bans, redirects and certificates; deleting the zone and managing members stay with the Owner. The Owner adds an Administrator by the email of their Dinio account; there are no invitations, so the person needs an account first.

A zone key gives a script the same access to one zone, without a user.

Redirects

A redirect answers HTTP(S) requests for a host name in one of your zones with an HTTP redirect (301, 302, 303, 307 or 308) to another URL — go.example.com → https://www.example.com/campaign, say.

You don’t add DNS records for it. When you create a redirect, Dinio adds the records that point the name at its edge (a CNAME, or A/AAAA at the zone apex, marked managed_by: "Redirect") and removes them when you delete it. For that reason, the name must not already have A, AAAA or CNAME records of your own.

A redirect is identified by its host name, and tls decides where its HTTPS certificate comes from:

tls	Certificate
Auto	Dinio issues one from Let’s Encrypt and renews it.
Manual	You upload your own certificate for the name.
None	None of its own; HTTPS requests get the platform’s default certificate. The default.

Certificates

A zone certificate is a TLS certificate you upload for names in your zone. Dinio’s edge serves it by SNI. Every name on it must be served by the zone, and one name can be covered by only one certificate.

Certificates that Dinio issued for a redirect with tls: Auto are listed too, with source: "Acme". They are read-only: Dinio replaces and deletes them together with the redirect. To use your own certificate for such a name, switch the redirect to Manual first.

The private key goes in once, on upload, and is never returned.

Statistics and audit log

Dinio’s DNS servers count the queries to your zones: answers per response code, type and country, the busiest names, and the names asked for that don’t exist. Read them per zone, or summed over all of your zones, with Statistics. How far back they reach depends on the zone Owner’s package.

The audit log records every change to your zones — who did what, and when — for every Owner and Administrator of the zone.