Skip to main content
Working with this resource via an AI agent? Datum publishes a DNS skill that teaches agents the canonical patterns for this resource.
We offer authoritative DNS hosting for your domains that you can manage through our portal as well as CLI.

​
Current features

  1. Zone Management – Add DNS zones for any domain and subdomain, whether they are hosted by Datum or externally, for broad visibility across all of your DNS zones.
  2. Global Authoritative DNS – Datum serves authoritative DNS through a globally distributed anycast system for performance and redundancy. To use Datum’s authoritative DNS, set up your domain in Datum Cloud (cloud.datum.net or via datumctl) and point it to Datum’s nameservers:
  3. Bulk Import/Export – Import existing zone files (BIND format, screenshot from DNS provider, sync by querying for DNS records) or export current configurations.
  4. Record Operations – Add, edit, and delete modern DNS records: A, AAAA, CAA, NS, SRV, TXT, CNAME, MX, SOA, TLSA, SVCB, HTTPS.
  5. View Zone Details – Active nameserver assignments; record count and zone size; last modified timestamp.
  6. Audit Log – Track all zone and record changes with user attribution and timestamps.
  7. Project Scoped – Manage zones within individual projects with role-based access control.
Datum DNS doesn’t currently support DNSSEC. If DNSSEC is turned on for your domain, turn it off and wait for the DS record to expire before you point your domain at Datum’s nameservers. Otherwise your domain stops resolving for most of the internet. See DNSSEC.

​
DNSSEC

Datum DNS doesn’t currently support DNSSEC. Zones hosted on Datum aren’t signed, and you can’t create DS, DNSKEY, RRSIG, NSEC, or NSEC3 records. This matters most when you move an existing domain to Datum. If your registrar still publishes a DS record for the domain, validating resolvers (Google Public DNS, Cloudflare 1.1.1.1, Quad9, and most ISP resolvers) expect signed answers. Datum’s answers aren’t signed, so those resolvers treat them as tampered with and return SERVFAIL. To your users, the domain looks like it has gone offline.

​
Check whether DNSSEC is on

Look for a DS record at the parent zone:
If this prints nothing, DNSSEC isn’t on and you can move to Datum without extra steps. If it prints one or more lines, DNSSEC is on. If you’ve added the domain to Datum, its registration details also show this. datumctl describe domain <name> --project <project-id> reports status.registration.dnssec.enabled and any DS records the registry has on file.

​
Turn off DNSSEC before you switch nameservers

Do these steps in order. Keep your current DNS provider serving the zone until the last step.
1

Remove the DS record at your registrar

Turn off DNSSEC, or delete the DS record, wherever your domain is registered. If your current DNS provider manages DNSSEC for you (Cloudflare, for example), turn it off there as well. Leave the zone signed at your current provider for now. See Cloudflare’s guide to disabling DNSSEC for an example of this flow.
2

Wait for the DS record to disappear

Run dig +short DS example.com until it returns nothing. Then wait one more full DS TTL so cached copies expire. You can see the TTL with dig DS example.com. For .com and .net it’s 24 hours, and other TLDs vary.
3

Create the zone on Datum

Add the zone and import your records. If your zone file includes DS, DNSKEY, RRSIG, NSEC, or NSEC3 records, the importer skips them and lists them in a warning. You can ignore that warning.
4

Point your domain at Datum

At your registrar, change the nameservers to ns1–ns4.datumdomains.net.

​
If your domain stopped resolving after the move

If the domain resolves when you skip validation but fails normally, a leftover DS record is the likely cause:
Remove the DS record at your registrar. Validating resolvers recover as their cached copy of the DS record expires, which can take up to the DS TTL.

​
Subdomains delegated to Datum

You can delegate a subdomain (for example app.example.com) to Datum even when the parent zone is signed somewhere else. This works as long as the parent zone has no DS record for that subdomain. Without one, resolvers treat the subdomain as unsigned and accept Datum’s answers.

​
DNS record types and behaviors

Most record types are standardized (A, AAAA, CNAME, etc.), but some DNS “record-like” features are provider-specific behaviors (for example, “CNAME flattening”). See ALIAS (“CNAME flattening”) for details.

​
Concepts and definitions

  1. DNS Zone - A DNS zone is a segment of the Domain Name System that contains the DNS records for one domain or subdomain, managed as a single administrative unit.
  2. DNS Host - A DNS host is the provider or server that stores and serves the DNS records for your domain, responding to queries from the internet. Some examples of DNS hosts are Datum, Cloudflare, Amazon Route 53, and GoDaddy.
  3. Nameserver - A nameserver is a specialized DNS server that tells the internet where to find a domain’s DNS Zone and routes queries to the correct host.
  4. DNS Record - A DNS record is an individual entry within a DNS zone that maps a domain name to a specific resource, such as an IP address, mail server, or another domain.
  5. BIND Format - BIND format is a standardized text format used to represent DNS zone files, listing all the records and settings that define a domain’s configuration.
  6. Domain Connect - Domain Connect is an open standard that allows web services and domain registrars to automatically configure DNS settings for users with simple authorization.

​
ALIAS / CNAME flattening

​
What is an ALIAS record?

An ALIAS record is a provider-side feature that lets you point a hostname (including the zone apex, like example.com) at another hostname the way a CNAME does, while still returning A/AAAA answers to clients. Different providers use different names for the same idea:
  • Cloudflare commonly describes this as “CNAME flattening”
  • Other DNS providers may call it ALIAS, ANAME, or flattened CNAME

​
When to use ALIAS

Use ALIAS when you want “point this name at that hostname” behavior but you can’t (or shouldn’t) use CNAME, most commonly:
  • At the zone apex (example.com) where CNAME is not allowed by standard DNS rules.
  • When you want the convenience of targeting a hostname that may change IPs (CDNs, hosted services), but still need clients to receive A/AAAA records.

​
Expected name and value

  • Name: the hostname inside the zone you’re creating the record for.
    • For the zone apex, many DNS tools use @ (BIND/zone-file notation) to mean “the zone root”.
    • For a subdomain, use the label (for example www for www.example.com).
  • Value: a target hostname (FQDN), like myapp.hosting-provider.com.
    • ALIAS values should be hostnames, not IP addresses.
    • The target hostname should ultimately resolve to A and/or AAAA records (directly or through other DNS indirection).

​
How it works

ALIAS does not exist as a standardized DNS RRType that recursive resolvers understand everywhere. Instead, the DNS provider’s authoritative system does the work:
  1. A client’s recursive resolver asks for A and/or AAAA for the ALIAS name (for example example.com).
  2. Datum resolves the ALIAS target hostname (for example myapp.hosting-provider.com) to its current A/AAAA records.
  3. Datum returns the resulting A/AAAA answers as if they were directly configured on the ALIAS name.
Important consequence: clients typically do not see a CNAME in the response. They see A/AAAA records for the name they queried.

​
What to expect compared to CNAME

  • CNAME: returns a CNAME response and relies on the resolver to chase it.
  • ALIAS / “CNAME flattening”: returns A/AAAA directly (synthesized by the DNS provider).

​
Notes and limitations

  • Portability: ALIAS/flattening is not uniform across providers. If you move DNS providers, you may need to translate this into whatever equivalent that provider supports.
  • Answer types: ALIAS is primarily about synthesizing A/AAAA answers. It is not a general replacement for other record types.
Last modified on September 18, 2026