By Greg Nowak. Last updated 2026-09-21.
The DNS record is sitting in the dashboard. The hostname looks right. So does the value. Yet public resolvers return something else—or nothing at all.
Propagation delay is an easy suspect, but it may have nothing to do with the problem. The record could be shadowed: stored in one DNS zone even though a delegation has placed that name under the authority of another.
On September 14, 2026, Cloudflare introduced shadowed-record warnings for all zones. Those warnings make a subtle DNS problem much easier to spot. A provider can store a record in its control panel without serving that record as the authoritative answer.
Follow the authority, not the dashboard
A subdomain delegation begins with NS records below the parent zone’s apex. Those records direct resolvers to a child zone and its nameservers. Microsoft’s guidance on DNS zone delegation describes the records as both the transfer of authority and the referral that tells DNS servers and clients where to continue.
Take app.example.com. If example.com delegates that subdomain to another set of nameservers, an ordinary A, CNAME, TXT, MX or similar record added for that name—or below it—in the parent dashboard will not take precedence. The resolver reaches the delegation, follows the NS referral and asks the child zone.
The terminology in RFC 8499 helps explain what is happening. A delegation creates a separate zone below the parent at a zone cut. From that point, authority follows the DNS hierarchy, regardless of which provider interface an administrator happens to have open.
This catches teams during migrations, staging launches, SaaS verification and agency handovers. Someone adds the requested record to the familiar account, checks that it saved successfully and assumes the job is done. The missing step is confirming which zone is authoritative for the exact hostname.
| What you find | What it probably means | What to check next |
|---|---|---|
| The record appears in the parent zone and is marked shadowed | A delegation at or above that name has moved authority elsewhere | Locate the relevant NS records and query the child nameservers |
| The parent returns an NS referral and the child returns the expected record | The delegation works; the parent-side copy is redundant | Check dependencies before removing stale configuration |
| The parent returns an NS referral but the child lacks the record | The record was probably added to the wrong zone | Create or correct it with the child-zone operator |
| A delegated server is not authoritative for the child zone | The delegation may be lame | Fix the parent NS set or configure the delegated server correctly |
| An A or AAAA record supplies the address of an in-zone nameserver | It may be required glue, not disposable clutter | Establish whether the glue is live or unreachable |
Some shadowed records are still essential
Most shadowed records are not served from the zone where they appear. Glue is the important exception.
Glue is an A or AAAA record that provides the address of a delegated nameserver whose hostname sits inside the delegated namespace. Without that address, resolution can become circular: the resolver needs to contact the child zone to find the nameserver’s address, but it needs the address before it can contact the child zone. RFC 8499 defines this role, while the Cloudflare shadowed-record reference separates ordinary shadowed records from live and unreachable glue.
Cloudflare can attach shadowed_by metadata to a record, mark required glue with is_glue, and identify unreachable glue with dead_glue. Live glue is technically shadowed because it lies below the delegation, but the parent still includes it with the referral. Deleting it simply because the dashboard displays a warning can break resolution.
Unreachable glue needs a different investigation. Cloudflare uses that term when a shallower delegation intercepts the glue, preventing the parent from serving it. The record may be harmless residue, or it may point to a faulty higher-level delegation. Before removing it, Cloudflare advises checking whether the external nameserver at the shallower delegation contains the deeper records that are still needed.
This is not merely historical DNS trivia. The BIND 9.21.23 release notes include fixes for missing required A glue, glue accepted from the wrong parent, and parent-side handling at zone cuts. Referrals and glue need to be tested directly; a tidy-looking zone file is not enough.
A practical authority check
A useful investigation answers four questions, in order.
- Where is the nearest zone cut? List non-apex NS records and map the branches they delegate. One shallow delegation can shadow a large group of records, including deeper delegations.
- What referral does the parent serve? Query the parent’s authoritative nameservers directly. Capture the returned NS set and any accompanying glue instead of relying solely on a recursive resolver and its cache.
- How does each child server respond? Ask every delegated nameserver for the affected hostname and record type. Inconsistent answers can reveal a partial deployment. A server listed in the delegation but not serving the child zone is a lame delegation in RFC terminology.
- Who is supposed to own the subdomain? Confirm whether the child zone should remain independently operated or whether the delegation is obsolete. That decision determines where the record—and the operational responsibility—belongs.
For Cloudflare zones, the DNS Records API can return the relevant metadata when include_shadow_metadata=true is included in the request. Delegation-oriented filters can help find records shadowed by a particular zone cut or identify the NS records shadowing a given name. That is much more manageable than opening records one by one, especially when several zones are involved.
Fix the ownership model behind the failure
If the delegation is intentional, add or correct the record in the child zone. The parent-side non-glue copy can then be treated as stale configuration. If the delegation is obsolete, remove or replace it only after checking that no live service still depends on the child zone. Where the delegated servers are not authoritative, repair the parent referral and child configuration until they agree.
Plan the change around the TTLs already in place. Capture the current answers, prepare the destination records, allow relevant caches to age when necessary, make the record or delegation change, and repeat the same authoritative queries afterward. Recursive lookups are useful confirmation, but they cannot replace direct checks against the parent and child servers.
Greg can handle this as a focused infrastructure audit: pull Cloudflare’s shadow metadata, map the zone cuts, compare parent referrals with child answers, distinguish working glue from dead or stale records, and set out a TTL-aware correction plan. The result should include before-and-after evidence, so it is clear what changed and why.
A shadowed-record warning is a useful lead. The real diagnosis comes from identifying which server has authority for the hostname and seeing what that server actually returns.
Related on GrN.dk
- Cloudflare Service Keys: Audit Old Automation Before September 30
- Google’s 2026 AI Search Guidance: SEO Still Matters, but Reporting Has Changed
- Your AI Gateway Can Name the User. Decide What That Log Is For
Need help with this kind of work?
Plan a DNS authority audit Get in touch with Greg.
