Managed DNS is the control layer between a domain name and the services that answer for it. This guide explains how to configure core DNS records, reduce avoidable mistakes, monitor security and availability, and create a recurring review process for changes such as hosting migrations, certificate updates, email-provider changes, and failover events.
Overview
A DNS hosting service stores and publishes the records that tell resolvers where to find a website, email system, verification service, or other hostname. Managed DNS adds an operational workflow around those records: access controls, change history, DNSSEC support, health checks, notifications, and dependable name-server infrastructure may all be part of the service. The exact features vary, so treat the provider’s documentation and plan details as the source of truth.
The most important principle is to separate the purpose of each record from the system that manages it. Your domain registrar controls registration and delegation, while your DNS provider publishes the zone. Your web host serves the application, and your email provider handles mail delivery. These systems can be operated by one company or several, but their responsibilities should be documented clearly.
Before editing a live zone, create an inventory of every hostname and service in use. Include the root domain, the www hostname, staging environments, APIs, mail hosts, verification records, third-party applications, and any subdomain used by a team. If you are moving a website, the guide on transferring a domain to a new host without downtime provides a useful companion checklist.
What to track
Core DNS records
Keep a record-level inventory with the hostname, type, value, TTL, purpose, owner, and date of the last review. The common record types have distinct jobs:
- A: Maps a hostname to an IPv4 address. It is commonly used for a website or service with a stable IPv4 endpoint.
- AAAA: Maps a hostname to an IPv6 address. Publish it only when the destination and network path are configured to serve IPv6 correctly; an incorrect AAAA record can send some visitors to a broken endpoint.
- CNAME: Points one hostname to another hostname. It is useful when a provider gives you a destination that may change, but follow the provider’s rules about which hostnames may use it.
- MX: Identifies the mail servers responsible for receiving email. MX records use priorities, so record both the destination and its priority value.
- TXT: Holds text-based configuration and verification data. SPF guidance, DKIM-related values, DMARC policy, and service ownership checks often use TXT records. Copy long values carefully and avoid deleting an existing record without confirming its purpose.
- CAA: Restricts which certificate authorities may issue certificates for a domain or hostname. If you use CAA, document the intended certificate workflow and verify that it matches your certificate provider.
Also track NS records and delegation at the registrar. A perfectly configured zone will not help if the domain delegates to different name servers. For a practical walkthrough of pointing a domain to hosting, see how to point a domain to web hosting.
Security and access
Review who can change DNS, which accounts have administrator privileges, and whether multi-factor authentication is enabled where available. Keep registrar access separate from routine DNS editing when possible. Record the recovery contacts and escalation path, but do not store passwords or private keys in a shared DNS inventory.
DNSSEC should be treated as a complete chain rather than a single switch. It uses signed DNS data and a delegation component at the parent zone. Before enabling it, confirm that your DNS provider and registrar support the required workflow, document the key-signing information, and understand the recovery procedure. After a change, validate both successful resolution and the expected DNSSEC status. A broken delegation can make a domain appear unavailable even when its DNS records are otherwise correct.
Performance and resilience
Track resolution success from more than one network or geographic location. A single successful lookup is not proof that every resolver or user can reach the intended answer. Monitor the critical hostnames separately: the public website, API endpoints, mail-related records, and any service that supports sign-in or checkout.
For DNS failover, document the health check target, the failure condition, the alternative destination, and the process for restoring the primary service. Failover is not a substitute for application redundancy. It should be tested in a controlled way, because a DNS response can change where new connections go while existing connections may continue using the previous destination.
Cadence and checkpoints
A recurring review prevents DNS from becoming an undocumented collection of historical exceptions. The right cadence depends on how often your infrastructure changes, but the following schedule is a practical starting point.
After every change
Record what changed, why it changed, who approved it, the previous value, and the expected result. Check authoritative answers directly, then test the service itself. For a website, load the root domain and important subdomains over both HTTP and HTTPS as appropriate. For email, verify that the intended MX, SPF, DKIM, and DMARC-related records remain present. If the change involves hosting, test the origin and the public hostname separately.
Monthly review
Compare the live zone with your inventory. Look for unused records, duplicate verification entries, stale staging hosts, unexpected nameservers, and values that no longer match current infrastructure. Review alerts from DNS monitoring and investigate recurring lookup failures rather than dismissing them as propagation.
Quarterly review
Reconfirm registrar access, DNS-provider access, recovery contacts, DNSSEC status, and delegated nameservers. Review the list of people who can make changes. Test a documented rollback for a low-risk record or use a nonproduction zone if a live test would be disruptive. Recheck failover documentation and confirm that the alternate destination still exists and is maintained.
Whenever you plan a migration, lower TTLs in advance only when there is a clear reason and enough time to make the change safely. A lower TTL may help caches refresh sooner, but it does not instantly clear every cached answer and should not be treated as a guarantee of immediate global change. After the migration, restore a sensible TTL based on how frequently the record normally changes.
How to interpret changes
When a DNS issue appears, first identify whether the problem is delegation, resolution, routing, or the service itself. Check the domain’s authoritative nameservers and query them for the record in question. Then compare those answers with results from public or local recursive resolvers. Finally, test the destination directly where appropriate.
Different answers do not always indicate an error. Recursive resolvers may retain cached data until the record’s TTL expires, and different locations may refresh at different times. However, inconsistent results that persist beyond the expected caching window deserve investigation. Check for multiple DNS providers serving different versions of the zone, an incorrect registrar delegation, an unplanned wildcard record, or a recently changed CNAME chain.
Be cautious when interpreting DNS response time. A slow website is not automatically a slow DNS problem. DNS lookup time is only one part of a page request; hosting capacity, TLS negotiation, server response time, application code, CDN behavior, caching, and large assets may matter more. Use a performance review such as this guide to speeding up a slow website to separate DNS symptoms from origin and front-end causes.
For security changes, distinguish between a missing record and an invalid record. A TXT value may be present but formatted incorrectly; a CAA policy may be valid but exclude the certificate authority your process uses; DNSSEC may be enabled in one system but not correctly delegated at the registrar. Capture the exact query, response, time, and location in an incident note so the next person can reproduce the finding.
When to revisit
Revisit this DNS setup immediately before and after a domain transfer, hosting migration, email-provider change, CDN change, certificate workflow change, or major application launch. These events can alter A, AAAA, CNAME, MX, TXT, CAA, or nameserver settings. Review it as well when an organization changes its registrar, DNS provider, access model, or incident-response process.
On a normal schedule, perform a lightweight monthly check and a deeper quarterly review. Set a calendar reminder that links to the zone inventory, monitoring dashboard, change log, and rollback notes. Update the article or internal runbook whenever the provider interface, delegation process, DNSSEC workflow, monitoring method, or failover design changes. The goal is not to edit records on a fixed schedule; it is to confirm that the documented design still matches reality.
To make the next review actionable, finish with a short checklist:
- Export or record the current zone and mark each record’s purpose.
- Confirm registrar delegation and authoritative nameserver answers.
- Check A, AAAA, CNAME, MX, TXT, and CAA records against active services.
- Review DNSSEC, account access, authentication, and recovery details.
- Test critical hostnames from more than one resolver or location.
- Verify failover targets and document the rollback procedure.
- Log findings, assign owners, and schedule the next monthly or quarterly review.
A managed DNS setup is healthiest when it is observable, documented, and easy to change deliberately. Regular checkpoints turn DNS from a one-time launch task into a maintainable part of website and cloud operations.
