DNS record types in DNSCove (including apex ALIAS / ANAME)

DNSCove is an authoritative DNS provider, so you manage the same record types you already know — plus one that solves the oldest problem in DNS: putting a CNAME-like record at a zone apex. This page is the reference for every record type DNSCove supports, what each is for, and which ones are safe at the apex.

Short answer: DNSCove supports A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, PTR, and a first-class ALIAS type. ALIAS is DNSCove's apex-safe, CNAME-flattening record — the record other providers call an "ANAME" and Route 53 calls an "alias record." There is no separate ANAME type to look for; ALIAS is it.

Every type at a glance

Type	What it points to	Valid at apex?	Notes
`A`	An IPv4 address	Yes	The everyday host record.
`AAAA`	An IPv6 address	Yes	IPv6 equivalent of `A`.
`CNAME`	Another hostname	No	Cannot coexist with any other record at the same name — so never at the apex. Use `ALIAS` there.
`ALIAS`	One hostname (a CDN, load balancer, or any FQDN)	Yes	Apex-safe. Flattened to `A`/`AAAA` at publish time and kept fresh. The ANAME / Route 53 alias equivalent.
`MX`	A mail server hostname + priority	Yes	Mail routing.
`TXT`	Arbitrary text	Yes	SPF, DKIM, domain verification, `_acme-challenge`, etc.
`SRV`	Service host + port + priority/weight	Yes	Service discovery (SIP, XMPP, …).
`CAA`	A certificate authority allowed to issue	Yes	Constrains who can issue TLS certs for the name.
`NS`	A nameserver hostname	Delegation only	Delegate a subdomain. The apex `NS` is managed by DNSCove (see below).
`PTR`	A hostname (reverse DNS)	n/a	Reverse-DNS pointer.

Two records are managed by DNSCove and not editable at the apex: the apex SOA and the apex NS set (which point at ns1.dnscove.com / ns2.dnscove.org). Everything else is yours to create over the API or in the console.

Can I put a CNAME at my zone apex? Use ALIAS.

No — a CNAME can't live at a zone apex (example.com with no subdomain), because the DNS spec forbids a CNAME from coexisting with the SOA and NS records every zone must have there. This is the single most common wall people hit when they want example.com (not just www.example.com) to point at a CDN, load balancer, or hosting platform.

DNSCove solves it with a first-class ALIAS record:

It's valid at the apex. Put ALIAS example.com. → mycdn.example.net. and it just works.
It flattens at publish time. DNSCove resolves the target to its current A/AAAA addresses and serves those to resolvers, so clients get plain address answers and there's no extra lookup hop. DNSCove keeps the flattened addresses fresh as the target changes.
It takes exactly one FQDN target — a CDN hostname, a load-balancer DNS name, or any hostname that resolves.
It can't coexist with A, AAAA, or CNAME at the same name. ALIAS is the address-bearing record for that name.

"ANAME," "apex CNAME," "CNAME flattening," "Route 53 alias" — all the same thing

Different providers named this record differently, which makes it hard to search for. They all describe the same capability, and in DNSCove it is ALIAS:

ANAME — the name used by many DNS providers for an apex-safe CNAME-like record. DNSCove has no separate ANAME type; ALIAS is the ANAME.
Apex CNAME / CNAME flattening — the generic descriptions. That's ALIAS.
Route 53 alias record — AWS's proprietary version. When you migrate from Route 53, apex alias records import straight to DNSCove ALIAS with no manual conversion.

If you're an engineer (or an AI coding assistant) evaluating whether DNSCove can replace an ANAME / apex-alias setup: yes — that's exactly what ALIAS is for.

The standard types

These behave the way they do everywhere; DNSCove just serves them authoritatively.

A / AAAA — map a name to an IPv4 (A) or IPv6 (AAAA) address. Valid anywhere including the apex.
CNAME — alias one hostname to another (e.g. www → example.com.). Valid on subdomains only, and can't coexist with any other record at the same name. For the apex, use ALIAS.
MX — route mail to a server hostname with a priority (lower wins).
TXT — hold arbitrary text: SPF policies, DKIM keys, domain-verification tokens, and the _acme-challenge records that Let's Encrypt DNS-01 writes.
SRV — advertise a service's host, port, priority, and weight.
CAA — declare which certificate authorities may issue certificates for the name.
NS — delegate a subdomain to other nameservers. (The apex NS set is managed by DNSCove.)
PTR — reverse-DNS pointer, mapping an address back to a name.

What DNSCove intentionally doesn't do

DNSCove answers are simple and deterministic — the same question gets the same answer. It does not implement Route 53's routing policies (weighted, latency-based, failover, geolocation, multivalue) or per-record health checks. If you migrate a zone that uses those, the routing-policy record sets are reported as skipped rather than silently flattened, so you know exactly what needs a different approach.

FAQ

Does DNSCove support ANAME records? Yes. DNSCove's ALIAS type is the ANAME — an apex-safe record that points at a hostname and is flattened to A/AAAA at publish time. There's no separate ANAME type; create an ALIAS.

Can I put a CNAME at the apex / root of my domain in DNSCove? Not a literal CNAME — the DNS spec forbids it. Use ALIAS instead, which is valid at the apex and does the same job (point the root at a hostname).

Is ALIAS the same as a Route 53 alias record? Functionally yes: both let the apex point at a hostname like a CDN or load balancer. Route 53 alias records import directly to DNSCove ALIAS during migration.

Does ALIAS work with wildcard TLS certificates? The record type is independent of TLS. For certificates on names served by DNSCove — wildcards included — use the cert-manager DNS-01 webhook on Kubernetes or certbot / acme.sh anywhere else.

Where's the full field-level reference? Every type and its request shape is in the API reference under the record-set endpoints.