Delegating a subdomain lets another DNS service manage a branch such as shop.example.com while the main domain stays with its current provider. This is an NS delegation, not merely a CNAME to the new provider's control panel.
IN THIS ARTICLE
What you need before you begin
Obtain the exact authoritative nameservers allocated for the child zone. Inventory records at and below the proposed boundary, including mail and verification entries. Arrange access to both parent and child providers before changing public delegation.
01 Delegate a subdomain to another authoritative DNS provider
- Create the child zone at the destination provider and populate its required records. Its apex is shop.example.com, so record-name fields may be relative to that child name.
- Query every new child nameserver directly and confirm it answers authoritatively for the child zone. Check both SOA and an intended application record.
- At the parent DNS provider, add the supplied NS records at the child name. Preserve unrelated parent records. Avoid conflicting CNAME data at the delegation point.
- If a child nameserver's own name is inside that child zone, arrange the necessary parent glue address records. Merely adding an address inside an unreachable child zone will not break the circular dependency.
- For a signed child, publish the correct DS in the parent only after child signing is verified. Follow a planned DNSSEC transition if an existing signed delegation is moving.
02 Example: delegate a child zone to another DNS provider
Suppose the provider hosting shop.example.com assigns ns1.provider.example and ns2.provider.example. Add the delegation to the authoritative parent zone for example.com, using the actual assigned hostnames. The following is BIND notation for the parent-side records.
shop.example.com. 3600 IN NS ns1.provider.example.
shop.example.com. 3600 IN NS ns2.provider.example.
Read the result: The parent directs queries below shop.example.com to the child's authorities. Those servers must already host a complete shop.example.com zone and answer its SOA query. Adding the parent NS records does not copy existing child A, TXT or mail records into the new service.
Check for conflicting records at the delegation point and plan any DNSSEC DS records with the child provider. These nameservers are outside the child zone, so the example does not require child-internal glue. Other designs can require glue and should be reviewed separately.
Verify the authoritative DNS result
Trace resolution through the parent to the child. Confirm the child NS set, authoritative answers and public website or mail behaviour. Allow existing cached delegation data to expire.
Troubleshoot unexpected results
If the parent lists the new nameservers but they answer REFUSED or lack the child zone, finish the provider configuration or restore the recorded delegation. Editing ordinary records in the parent will not repair the child service.
A common question
Do I change the registrar nameservers to delegate only shop.example.com?
Usually no. Registrar nameserver settings delegate the registered domain. A normal child-zone delegation is added inside the authoritative parent zone. Registry-specific arrangements are separate and should follow the actual domain's provider instructions.