This article walks through each layer where a delegated hostname can fail in an internal network setting, in the order they occur, with commands for both Windows DNS and BIND/Linux. Work through the stages in sequence — later stages assume the earlier ones passed.

If you have not yet created your delegation, start with Connecting your domain to LXP / Learn instead.

A delegation only works if your DNS servers can reach the nameservers you delegated to. Two requirements are easy to miss:

Cloudflare's authoritative nameservers are anycast. The ranges containing them are:

Important: DNS forwarders do not satisfy this requirement. When your DNS server is authoritative for yourdomain.com and encounters a delegation for a hostname inside it, it queries the delegated nameservers directly. Forwarders are only consulted for names outside its authoritative zones. A server with correct forwarders and no direct egress will resolve the entire internet normally and fail on every delegated subdomain.

This is the single most common cause of a correct delegation not working.

The diagnostic path depends entirely on what you are seeing. Find your symptom below and go to the stage indicated.

A correct change that appears not to work is usually a stale cache. Do this before anything else, and allow the previousrecord's TTL to expire before drawing conclusions.

Windows — on each DNS server, then a test workstation:

BIND / Linux — on the DNS server, then a test client:

If your organization runs internal DNS that is authoritative for your domain — most banks and credit unions do — you have two authoritative sources and both must be correct. Machines on your corporate network never consult public DNS for your own domain.

Windows — on a domain controller. -Name is the label relative to the zone, not the FQDN:

For learn.yourdomain.com, -ZoneName is yourdomain.com and -Name is learn. Passing the full hostname to -Name will look for learn.yourdomain.com.yourdomain.com and report nothing found.

If the hostname was created as its own zone, -ZoneName is the full hostname and -Name is @. List your zones to check:

BIND / Linux — query the authoritative server directly, and list the zones it serves:

+norecurse matters. Without it you may get a cached or recursively resolved answer rather than what the zone actually contains. You can also inspect the zone file directly, or dump the running configuration with rndc dumpdb -zones and read /var/named/data/cache_dump.db.

A single-character error produces a delegation that looks perfect and never resolves. cloudfare (missing the l) is the classic. Confirm each nameserver you delegated to actually resolves:

If a nameserver hostname does not resolve, correct the spelling in your NS records.

Run these on the DNS server, not a workstation. The workstation never queries Cloudflare — your DNS server does the recursion, so its egress path is the one that matters.

Note that Test-NetConnection -Port tests TCP only. A successful PingSucceeded with TcpTestSucceeded : False means routing is fine and port 53 is being dropped — it does not tell you anything about UDP, which is why both tests above are needed.

If ICMP succeeds while port 53 fails, you have a firewall permitting ping and dropping DNS. That is a policy decision, not a fault.

A conditional forwarder for the specific hostname, pointing at a resolver that already has permitted egress, is a supported alternative.

Remove the NS delegation if you do this. Authoritative zone data generally takes precedence over a conditional forwarder, so leaving both in place risks the forwarder never being consulted.

This approach should work, but we are unable to assist with its diagnosis.

With the delegation in place and egress open, resolution should complete.

-DnsOnly and -NoHostsFile suppress the hosts file, LLMNR, and NetBIOS so you see the actual DNS answer. dig never consults those sources.

This is the most informative diagnostic available to you. It walks the delegation from the root and shows exactly where it stops.

BIND / Linux:

Read it top down. You should see referrals from the root, to the TLD, to your domain's nameservers, then to the Cloudflare nameservers, then a final answer. The last successful step tells you which layer is failing. If the trace stops at your own nameservers, the delegation is not being served. If it reaches Cloudflare and stalls, egress or DNSSEC is the issue.

Windows — there is no +trace equivalent, so walk the chain manually. Each step queries the nameservers returned by the previous one:

The step that fails is the layer to investigate. Failure at step 2 means your nameservers are not serving the delegation; failure at step 3 means egress or DNSSEC.

For a genuine +trace, dig is available for Windows via BIND Tools, or you can run the trace from any Linux or macOS host and compare its result against your internal one.

If your domain is DNSSEC-signed, a mismatch at the delegation point produces SERVFAIL while every record looks correct.

Windows:

BIND / Linux:

This is the decisive test — if the query succeeds with validation off and fails with it on, DNSSEC is your problem.

BIND / Linux:

Windows — Resolve-DnsName has no checking-disabled flag, so inspect your validation configuration instead:

If you have no Linux host available, running the +cd comparison from any external machine is a valid substitute — the question is whether the record set validates, which is not specific to your network.

Common causes are a DS record published for the delegated hostname that does not match, or a stale DS or trust anchor left behind from a previous configuration.

Note that a delegated subdomain generally should not carry its own DS record unless we have explicitly provided one.

A delegation can be present and correct while another configuration takes precedence over it.

Windows:

BIND / Linux:

Windows:

BIND / Linux:

For Unbound, use unbound-control dump_cache | grep -i learn instead.

Things to look for:

Any of these will win over the delegation and produce a wrong or failing answer.

If resolution now returns Cloudflare addresses and the site still does not load, the problem is at the web layer.

Windows:

BIND / Linux:

Expected: two or three addresses in Cloudflare's proxy ranges — typically 104.x, 172.6x, or 188.114.x.

If you see an address ending in .126, or any address that josh.ns.cloudflare.com resolves to, something is still returning a nameserver address. Return to Stage 1 and Stage 5.

Windows:

BIND / Linux:

The /cdn-cgi/trace endpoint returns the Cloudflare colo that served you and the source IP Cloudflare observed. It is a fast way to confirm you reached Cloudflare's edge at all.

Error 1034 is rejected at Cloudflare's edge before the request is associated with our zone. This means the Ray ID shown on the error page cannot be located in our logs, and we cannot look it up for you. This is expected for this error class and is not a sign of a spoofed page — but it does mean the diagnosis has to come from your side's DNS configuration rather than from our logs.

If you have worked through the stages and are still stuck, send the following and we will pick it up from there:

Item 3 is the one most often missing and most often decisive. Please run it on the DNS server rather than a workstation.