Subdomain delegation: give another DNS provider a defined branch

Subdomain delegation gives a separate set of nameservers authority over part of a domain. For example, the owner of example.com can let another team manage the DNS zone for app.example.com without handing over the whole parent zone.

Use delegation when the other team or platform needs DNS control over that branch. If you only need a website hostname to point at an application, an A or CNAME record may be sufficient. Delegation changes who answers DNS queries; it is not just another way to enter an IP address.

Where the records belong

Get the actual nameserver set from the child DNS provider. Create the child zone and its needed records before publishing the delegation at the parent. A nameserver hostname alone is not proof that the server has a working zone for your subdomain.

Do not confuse delegation with moving the whole domain

The parent’s nameservers at the domain registrar can stay unchanged. The parent zone contains the NS records for the child. Cloudflare’s outgoing delegation guide shows this model and explains when glue records are required: when a delegated nameserver itself sits inside the delegated namespace.

For example, a child served by ns1.app.example.com introduces a lookup dependency that must be handled correctly. If your provider supplies nameservers in a separate domain, follow that simpler supported configuration instead of inventing private nameservers.

DNSSEC adds another relationship: the parent’s DS record must correspond to the child’s signing configuration when a secure delegation is used. Coordinate key changes with both sides. Copying a DS value from an older child zone can break validation even when the ordinary records look correct.

Why edits in the parent can appear to do nothing

Once the child is delegated, ordinary records for names under that branch belong in the child zone. Cloudflare’s shadowed-record documentation explains why a record may remain visible in the parent’s dashboard but no longer be authoritative.

Before deleting a seemingly unused parent record, identify its purpose and confirm the child has the required replacement. Record visibility in a dashboard and authority on the public DNS path are different things.

Cloudflare has two distinct arrangements

Delegating from a Cloudflare parent to external nameservers is different from adding the child as a separately managed Cloudflare zone. The Cloudflare subdomain setup documentation describes the latter as an Enterprise feature. Do not assume a guide for one direction establishes availability in the other.

Cloudflare also warns that its parent zone’s CDN and security services do not automatically apply to externally delegated subdomains. Agree which provider will serve HTTPS, apply access controls, and monitor the application after delegation.

Verify authority before investigating the application

Ask the child provider for evidence that its servers answer the expected zone and records. Then inspect the public delegation. On a machine with dig, these read-only queries are a useful starting point:

dig app.example.com NS
dig app.example.com A
dig api.app.example.com A
dig app.example.com +trace

Replace the example names with your own. If the trace reaches the wrong provider, investigate the delegation. If it reaches the right provider but returns no useful answer, investigate the child zone. If DNS is correct but the browser fails, investigate the destination application and certificate.

Keep an owner and removal plan for every delegated branch. When a vendor relationship ends, recover or remove the delegation deliberately. A forgotten NS record can continue giving another service authority over a name your customers still trust.