On Netlify, the first decision is not which record to create but who answers DNS for the domain. Netlify DNS takes over the zone once your registrar delegates to it; external DNS leaves the zone where it is, and you copy Netlify’s records there. Apex handling, IPv6, and wildcard certificates all follow from that choice.
Netlify DNS or external DNS
| Netlify DNS | External DNS | |
|---|---|---|
| Setup | Point the registrar at the four name servers Netlify lists for your zone | Keep your nameservers and add the records below |
| Apex as the primary domain | Netlify’s recommended way to run an apex primary | Works, but Netlify strongly recommends a subdomain as primary |
| IPv6 | Can be switched on under DNS, then Enable IPv6 | Not for the apex: the load balancer doesn’t support IPv6 |
| Wildcard certificate for subdomain sites | Provisioned automatically | Not automatic |
| DNSSEC | Not supported; disable it at the registrar | Stays with your DNS provider |
Once the registrar delegates to Netlify DNS, only the records in the Netlify zone are served, so copy mail, verification, and service records into it before you change nameservers. In either case, start by confirming who is authoritative. A Netlify DNS zone that exists in the dashboard answers nothing until the registrar delegates to it.
dig +short NS example.comExternal DNS: the records Netlify documents
Add the domain under Domain management, then Add a domain, in the site that should serve it. Netlify then shows tailored instructions in a Pending DNS verification dialog. For a standard site they amount to this:
| Host | Type | Value | Note |
|---|---|---|---|
www or any other subdomain |
CNAME | <your-site>.netlify.app |
Your site’s own Netlify subdomain |
Apex (@ or empty) |
ALIAS, ANAME, or flattened CNAME | apex-loadbalancer.netlify.com |
Preferred when your DNS provider supports it |
Apex (@ or empty) |
A | 75.2.60.5 |
Fallback; keep exactly one A record |
Sites on Netlify’s High-Performance Edge use dedicated targets from that dialog instead. The ALIAS family of record types is provider-specific; the CNAME flattening guide explains what they return.
Netlify’s documentation is candid about the apex: both methods end at a load balancer, so the apex “can’t take advantage of direct DNS routing” on Netlify’s CDN. That is why Netlify recommends a subdomain as the primary domain when DNS stays external.
What the apex target resolves to today
Live capture, 26 September 2026. The documented apex target from two resolvers, its IPv6 answer, and the registration of both addresses from ARIN’s RDAP service:
$ dig +nocmd @1.1.1.1 apex-loadbalancer.netlify.com A +noall +answer
apex-loadbalancer.netlify.com. 300 IN A 75.2.60.5
apex-loadbalancer.netlify.com. 300 IN A 99.83.231.61
$ dig +nocmd @8.8.8.8 apex-loadbalancer.netlify.com A +noall +answer
apex-loadbalancer.netlify.com. 44 IN A 75.2.60.5
apex-loadbalancer.netlify.com. 44 IN A 99.83.231.61
$ dig +nocmd @1.1.1.1 apex-loadbalancer.netlify.com AAAA +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59631
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
$ for ip in 75.2.60.5 99.83.231.61; do curl -s https://rdap.arin.net/registry/ip/$ip | jq -r '"\(.startAddress)-\(.endAddress) \(.name) \(.entities[0].vcardArray[1][] | select(.[0]=="fn") | .[3])"'; done
75.2.0.0-75.2.191.255 AMAZO-4 Amazon.com, Inc.
99.83.64.0-99.84.255.255 AMAZO-4 Amazon.com, Inc.What to read from it:
- The load balancer name returns two addresses, and the documented fallback is only one of them. An ALIAS, ANAME, or flattened record picks up both and follows whatever Netlify publishes later; a hard-coded A record stays at 75.2.60.5.
- There is no AAAA answer, which matches Netlify’s statement that the load balancer doesn’t support IPv6.
- Both blocks are registered to Amazon, not Netlify. An IP-ownership lookup won’t tell you whether a record points at Netlify; compare it with the documented values instead.
- The 44-second TTL from 8.8.8.8 is a cached copy counting down; 300 seconds is the full value.
A resolving netlify.app name proves nothing
Live capture, 26 September 2026. A netlify.app name we made up, which belongs to no site:
$ dig +nocmd @1.1.1.1 and-guide-no-such-site-20260926.netlify.app A +noall +answer
and-guide-no-such-site-20260926.netlify.app. 120 IN A 13.215.239.219
and-guide-no-such-site-20260926.netlify.app. 120 IN A 52.74.6.109
$ dig +nocmd @1.1.1.1 and-guide-no-such-site-20260926.netlify.app AAAA +noall +answer
and-guide-no-such-site-20260926.netlify.app. 311 IN AAAA 2406:da18:b3d:e201::259
and-guide-no-such-site-20260926.netlify.app. 311 IN AAAA 2406:da18:b3d:e201::258
$ curl -sI https://and-guide-no-such-site-20260926.netlify.app/ | grep -iE "^(HTTP|server|x-nf-request-id)"
HTTP/2 404
server: Netlify
x-nf-request-id: 01M3F35H0M67HVFYZE4689RMYRnetlify.app answered for a name that belongs to no site, with both IPv4 and IPv6 addresses; only the HTTP 404 gave it away. That has three practical consequences:
- A typo in your CNAME target still resolves.
diglooks healthy and the browser shows Netlify’s 404. Before touching DNS, request your site’s exactnetlify.apphostname withcurl -sIand confirm a200and your content. - Deleting a Netlify site doesn’t break the CNAME that pointed at it. The old name keeps resolving, so remove the record when you retire the site. Dangling DNS and subdomain takeover explains why a leftover record is a risk and not just clutter.
- A subdomain can get IPv6 answers even with external DNS, because resolvers follow the CNAME into
netlify.app, while the apex behind the load balancer stays IPv4-only.
Apex and www arrive as a pair
When you assign the apex or www as the primary domain, Netlify adds both names to Production domains. The one you entered is primary, and Netlify automatically redirects the other one to it. Other subdomains get no automatic redirect; use domain-level redirect rules for those. Configure DNS for both names, or the secondary one will neither redirect nor receive a certificate.
Netlify’s own site follows the www-primary pattern, although its DNS isn’t external: the zone is delegated to netlifydns.com and nsone.net name servers.
Live capture, 26 September 2026. Delegation, IPv6, and the apex redirect for netlify.com:
$ dig +nocmd netlify.com NS +noall +answer
netlify.com. 3600 IN NS ns01.netlifydns.com.
netlify.com. 3600 IN NS dns4.p04.nsone.net.
netlify.com. 3600 IN NS dns1.p04.nsone.net.
netlify.com. 3600 IN NS ns02.netlifydns.com.
netlify.com. 3600 IN NS dns3.p04.nsone.net.
netlify.com. 3600 IN NS ns04.netlifydns.com.
netlify.com. 3600 IN NS ns03.netlifydns.com.
netlify.com. 3600 IN NS dns2.p04.nsone.net.
$ dig +nocmd @1.1.1.1 netlify.com AAAA +noall +answer
netlify.com. 20 IN AAAA 2406:da12:53f:c100::1f5
$ curl -sI https://netlify.com/ | grep -iE "^(HTTP|location|server)"
HTTP/2 301
location: https://www.netlify.com/
server: Netlify
$ curl -sI https://www.netlify.com/ | grep -iE "^(HTTP|server:|x-nf-request-id)"
HTTP/2 200
server: Netlify
x-nf-request-id: 01M3F35VD8TQGQ7A9W6K9SWM2DThe apex has an AAAA record, which the external-DNS load balancer path can’t give you, and it answers with a 301 to www. server: Netlify plus an x-nf-request-id header is the practical sign that Netlify is serving a hostname. www vs apex canonical redirects covers how to pick the direction.
Verify an external-DNS setup in this order
- Confirm the authoritative provider, and edit records only there.
- Confirm your site’s
netlify.appURL returns200and your content. - Confirm the
wwwCNAME is exactly your site’snetlify.appname. - Confirm the apex returns 75.2.60.5 alone, or the load balancer’s two addresses if you used an ALIAS-type record.
- Confirm the apex has no AAAA record.
- Confirm CAA is either absent or allows Let’s Encrypt.
- Request both names over HTTPS: expect
server: Netlify, and a 301 from the secondary name to the primary one.
dig +short NS example.com
curl -sI https://your-site.netlify.app/
dig +short CNAME www.example.com
dig +short A example.com
dig +short AAAA example.com
dig +short CAA example.com
curl -sI https://www.example.com/
curl -sI https://example.com/If public resolvers disagree with the authoritative answer right after a change, they are serving cached data; DNS propagation: TTLs, caches, and verification shows how to tell.
When the certificate doesn’t provision
Netlify provisions Let’s Encrypt certificates automatically once DNS points at it. Its troubleshooting page maps the common failures:
| What you see | Cause | Fix |
|---|---|---|
| DNS verification failed | Records don’t match what Netlify expects, or with Netlify DNS the registrar isn’t delegating | Apex A to 75.2.60.5 and www CNAME to <your-site>.netlify.app, or fix the nameservers at the registrar |
| Waiting on DNS propagation for more than 48 hours | Old records are still published or cached somewhere | Check from several locations, remove stale records at the source, and let cached copies expire |
| Certificate stalls, apex has AAAA records | IPv6 records left over from a previous host | Delete all AAAA records |
| Certificate stalls, zone has CAA records | CAA doesn’t include Let’s Encrypt | Allow Let’s Encrypt or remove the CAA record |
| Several A records at the apex | Old addresses left next to Netlify’s | Keep only the single A record to 75.2.60.5 |
| Domain on Netlify DNS fails on validating resolvers | DNSSEC is still enabled at the registrar | Disable DNSSEC there; Netlify DNS doesn’t support it |
Automatic wildcard certificates, which give every subdomain site instant HTTPS, are available only when the domain uses Netlify DNS.