Cloudflare DNS records

How Cloudflare authoritative DNS answers for your domain

When a zone is active, the nameservers delegated at the registrar direct recursive resolvers to Cloudflare. Cloudflare then answers from the record set stored for that zone. A record can publish a destination directly or, for eligible web hostnames, return Cloudflare anycast addresses so HTTP and HTTPS traffic enters the Cloudflare proxy before reaching the origin.

• Authoritative DNS decides which answer is published; it does not configure the destination server.
• A proxied A, AAAA or CNAME record protects supported web traffic. DNS-only records expose the configured destination directly.
• Delegation, record content and the destination service must all be correct for an application to work.

Record types and the data they carry

Choose a type for the protocol and data being published. A and AAAA map a name to an IPv4 or IPv6 address. CNAME aliases one hostname to another. MX selects mail exchangers and uses a priority. TXT publishes verification and mail-policy data. CAA restricts which certificate authorities may issue certificates. SRV and service-binding records publish structured service information.

• Use @ for the zone apex; a relative label such as www becomes www.example.com.
• MX, TXT, DKIM and other mail records are DNS only. Cloudflare's HTTP proxy does not proxy ordinary SMTP traffic.
• A CNAME cannot normally coexist with unrelated data at the same owner name; apex flattening is Cloudflare's answer-time exception.

Proxy status changes the traffic path

The orange-cloud proxy is available only for supported address and alias records. With proxying enabled, visitors resolve Cloudflare addresses and Cloudflare connects to the origin using the record's actual target. This enables edge TLS, DDoS mitigation, WAF evaluation, caching and performance features. With DNS only, clients connect directly to the published destination and those HTTP-layer services are bypassed.

• Proxy public web applications unless a protocol, port or operational requirement needs direct DNS.
• Keep mail exchangers, mail autodiscovery, ownership-verification records and non-HTTP services DNS only.
• Do not rely on proxy status alone to conceal an origin address that is published elsewhere or accepts unrestricted direct traffic.

TTL, resolver caches and propagation

TTL tells recursive resolvers how long they may reuse an answer. Proxied records use Cloudflare's automatic TTL, normally 300 seconds. DNS-only records can use a configurable TTL. A lower TTL shortens the maximum cache lifetime for a planned change; it cannot invalidate answers already cached under the previous TTL.

• Reduce a DNS-only TTL before a planned migration and wait at least the old TTL before changing the destination.
• Keep the old destination operational while recursive caches expire.
• Raise the TTL after the new destination has been stable.

CNAME flattening at the zone apex

The DNS standard does not allow an ordinary CNAME at the apex alongside the mandatory SOA and NS data. Cloudflare can flatten a CNAME by resolving its target and returning address records to the requester. Flattening can be limited to the apex or extended according to the zone setting and plan.

• The target remains the source of the returned addresses, so target changes can flow through without editing the alias.
• Flattening adds a dependency on the target's DNS availability and does not proxy an otherwise DNS-only record.
• CAA evaluation and certificate issuance can follow alias chains; review CAA records at all relevant names.

Protect web and email while editing records

Inventory every record at the affected owner name and every service that depends on it. A website move should preserve MX, SPF, DKIM, DMARC and verification data. A mail move should preserve web and certificate-validation records. Record the previous type, content, TTL, priority and proxy state before replacing anything.

• Do not delete an old destination until the new service has passed application-level tests.
• Use separate names for staged origins when possible instead of repeatedly changing the production record.
• If DNSSEC is active, keep registrar DS data aligned with the active authoritative DNS provider.

Diagnose a DNS result

Query the authoritative nameservers and at least two independent recursive resolvers for the exact name and record type. Compare the answer, TTL and DNSSEC status, then test the application protocol. A proxied hostname should return Cloudflare addresses; a DNS-only hostname should return its configured address or resolved alias.

• NXDOMAIN: confirm the owner name, zone status and delegation.
• SERVFAIL: inspect DNSSEC validation, nameserver reachability and malformed authoritative data.
• Correct DNS but failed HTTPS: inspect proxy status, edge certificate, origin reachability and the origin Host header.
• Intermittent old and new answers: wait for the previous TTL and verify that every authoritative nameserver serves the same serial and data.

DNS quotas and service-created records

Cloudflare applies DNS record quotas according to zone plan and creation date. Records created by Cloudflare services, including Email Routing, count toward the applicable quota. Remove obsolete records deliberately, but do not delete service-managed MX or TXT data without first disabling or migrating the dependent service.

• Free-zone quotas can differ for older and newer zones.
• Pro and Business zones support larger per-zone record sets.
• Account-level products may create records whose ownership and lifecycle belong to that product.