What feature-rich DNS actually means

Basic DNS is a solved problem. Every registrar gives you a record table, you add an A record and an MX record, and your domain works. The trouble starts when DNS has to do something beyond pointing a name at a fixed address, because that is usually the moment you discover the box you are in. Here is what we mean by feature-rich, in concrete terms, and each of these is something you eventually want when DNS is load-bearing.

Failover and traffic steering

A static A record cannot route around a dead backend. Health-checked pools can: you define a set of targets, a probe checks each one, and the answer is built from whichever are healthy, by priority for failover or by location for geo steering. This is the difference between DNS that points at your infrastructure and DNS that participates in keeping it up. It is covered on its own in the GSLB write-up.

ANAME at the apex

You cannot put a CNAME on a bare domain; the DNS spec forbids it at the zone apex. So pointing example.com (no www) at a load balancer's hostname is a classic pain point. An ANAME record solves it: it behaves like an alias at the apex, resolving the target hostname and serving its addresses, so the naked domain can follow a load balancer or CDN endpoint that only gives you a name.

DNSSEC without the ceremony

DNSSEC stops someone from forging answers for your domain, but plenty of providers either do not offer it or make you manage keys and signing yourself. It should be a switch. In dnswiz, signing is online and per-zone: you enable it, the zone is signed, and the DS record you hand to your registrar is generated for you.

A query firewall and hijack monitoring

Authoritative DNS is a target. A query firewall lets you rate-limit by source and refuse query types you never serve, which trims abuse and reflection traffic. Alongside it, hijack monitoring watches for your records being answered differently out in the world than what you published, which is how you find out about a compromise or a misconfiguration before your users do.

Certificates, issued through DNS

Because the authoritative DNS already controls your zone, it is in the right position to answer ACME DNS-01 challenges. dnswiz can issue a TLS certificate for a name and solve the challenge for you, returning the chain and key, no separate certbot dance and no exposing port 80. This is the part most DNS providers cannot do at all.

Insight into what is actually being asked

Most DNS is a black box: queries go in, answers come out, and you see none of it. dnswiz keeps per-zone query analytics and a forensic view of refused queries, so you can see what is being asked for, what you are turning away, and what changed when an incident started. Failover that you cannot observe is just hope, and the same is true of the rest of the zone.

Transfers, so you are never stuck

Feature-rich should not mean trapped. Standard zone transfers (AXFR, with TSIG) let you pull your zone out, run a secondary, or move on entirely. A provider confident in its product does not need to hold your records hostage, and the ability to leave cleanly is itself a feature.

You do not need all of it on day one

Most domains start with a handful of plain records and that is correct. The point is not to use every feature immediately; it is to not have to switch providers, or upgrade to a tier, or pay extra for the API, the day you need the next one. Everything above is on the same platform, driven by the same API and Terraform provider, so growing into it is a config change rather than a migration.

See also: Multi-cloud resilience with GSLB, DNS as code, Why we built dnswiz.