Definitions

A child zone is a separate, fully functional zone that is technically a subdomain of another zone. For example, it is possible to have domain.com and sub.domain.com as individual zone objects, each with their own SOA records. Most commonly, this separation allows you to delegate a subdomain to another provider. Child zones also allow you to give control of a subdomain to another Dyn account.

The original “base” zone is referred to as the parent zone, e.g. domain.com; the separated subdomain is referred to as child zone or cut node, e.g. sub.domain.com. For more technical detail, please see RFC 1035.

Learn more about DNS Zones »

Creating a cut node

There are several ways to create a child zone, depending on your organizational needs. At its most basic, you can simply add NS records to a subdomain to assign it to another provider:

At OtherDomain LLC, you would create a new, full zone called sub.domain.com, and populate it with records as normal. Requests for records for domain.com would still be answered by Dyn, while requests for sub.domain.com and its own child nodes (e.g. hello.sub.domain.com) would be answered by ns1/ns2.otherdomain.com.

Put another way, a request for records at sub.domain.com would be answered like so:

root nameservers -> .com nameservers -> domain.com nameservers (Dyn) -> sub.domain.com nameservers (OtherDomain) -> SOA record

There are some caveats, however. Before you can add NS records and delegate the subdomain elsewhere, the child node cannot contain any other records or subdomains itself (e.g. www.sub.domain.com). If you are creating a brand new child node, this isn’t an issue; if you are delegating an existing subdomain, some coordination with our client services is required.

Please review the following options to see which method suits your needs:

• Delegating from Dyn to another DNS provider
• Delegating from Dyn to another DNS provider, with in-zone/in-parent glue
• Delegating from another DNS provider to Dyn
• Transferring to another Dyn account

Delegating from Dyn to another DNS provider

If the node exists and has records, but no subdomains:

1. Create the child zone with the new provider. Populate the new zone with the desired records, and make sure the zone is live and published. You can use utilities like dig to check the resolution against your new nameservers, e.g. _dig sub.domain.com @ns1.otherguy.com soa_.
2. Reduce the TTLs for the subdomain and all records beneath it to 30 seconds or less. Keep track of the highest TTL for any record in the subdomain; you will need to wait at least that amount of time for cached records to expire with all DNS resolvers.
3. When you are ready to cut over to the new provider, perform the following steps:
   1. In the DynECT interface, navigate to the node, and click “Delete Node” on the righthand side. Accept the warning, but do not publish.
   2. Navigate back to the node, and add NS records for the new provider.
   3. Publish the changes.

This will atomically swap the old records with the new NS records; new queries will now be answered by the new provider. The resolution for the rest of the parent domain will be unaffected.

If the node exists and has subdomains:

Follow steps 1 and 2 above, then contact client services. To prevent zones from being accidentally placed in a broken state, safeguards in the Dyn interface disallow the creation of NS records at any node with children. The client services team will be able to replace the node atomically without causing resolution loss.

Delegating from Dyn to another DNS provider, with in-zone/in-parent glue

Some configurations require in-zone/in-parent glue records. In this scenario, A records for the new provider’s nameservers are added to the parent zone beneath the cut node, like so:

With this configuration, the NS records for sub.domain.com direct visitors to query ns1/ns2.sub.domain.com, which already hold the IP addresses for the destination nameservers. Further queries will be directed to these machines.

If the node does not already exist:

1. Create the child zone with the new provider. Populate the new zone with the desired records, and make sure the zone is live and published. You can use utilities like dig to check the resolution against your new nameservers, e.g. _dig sub.domain.com @ns1.otherguy.com soa_.
2. In the Dyn interface, create the new node.
3. Under the new node, create the new subdomains, e.g. ns1.sub.domain.com, and populate them with the desired A records. Do not publish it yet.
4. When you have added all of the nameserver IP addresses, add NS records for them to the original child node, e.g. sub.domain.com.
5. Publish the zone. This will create both the NS records and A records simultaneously.

If the node does already exist:

1. Follow step 1 above.
2. Reduce the TTLs for the subdomain and all records beneath it to 30 seconds or less. Keep track of the highest TTL for any record in the subdomain; you will need to wait at least that amount of time for cached records to expire with all DNS resolvers.
3. Contact client services. To prevent zones from being accidentally placed in a broken state, safeguards in the user interface disallow the creation of NS records at any node with children. The client services team will be able to replace the node atomically without causing resolution loss.

Delegating from another DNS provider to Dyn

This method is essentially the reverse of the previous two delegation types: you have a parent zone elsewhere, and would like to delegate a single child node to Dyn.

1. Create the child zone in Managed DNS. Child zone creation works just like any other zone, because it is just another standard DNS zone; here, you’ll just be creating the domain at a lower level, e.g. sub.domain.com.
2. As advised above, lower the TTLs of the child node with your current DNS provider to 30 seconds or less. Keep track of the highest TTL for any record in the subdomain; you will need to wait at least that amount of time for cached records to expire with all DNS resolvers. (Do not lower TTLs to zero, as some DNS implementations may consider this to mean “keep this record permanently”.)
3. When you are ready to delegate, you will need to atomically replace the existing records with your new NS records, where XX is your pool number:

To avoid downtime, please ensure the records are swapped atomically; that is, the old records are deleted and the new records are added in a single publish action. If your current DNS provider’s user interface does not allow you to do this, please contact the provider’s support team for further assistance in avoiding resolution issues.

Transferring to another Dyn account

This method is a little different, as you will need consent and coordination between both the “giving” party (the current owning account for the parent zone) and the “receiving” party (the destination account for the child zone). You will need to contact our client services team for assistance in vetting and performing the child zone transfer between accounts.

Please note: Certain advanced services cannot be transferred between accounts. If the child node or its children utilize advanced services, e.g. Traffic Management, please inform the client services team when requesting the transfer so they can properly assist you.

If the child node does not exist:

1. In the parent account, create the desired child zone. Child zone creation works just like any other zone, because it is just another standard DNS zone; here, you’ll just be creating the domain at a lower level, e.g. sub.domain.com. Populate it with the desired records and nodes, then publish the zone.
2. Contact the client services team for further instructions. They may request that the owning account create certain records in the parent domain to prove ownership or may request certain documentation.Once validated, the child zone will be moved to the new receiving account, while NS records are placed in the parent zone. The receiving account may now utilize the child zone as desired, while the remainder of the parent zone is still controlled by the giving account.If the child node already exists:
   • Please contact the client services team. They will be able to separate the child node into a full zone and transfer it to the “gaining” account.

Frequently Asked Questions

• I want to create a child zone, but the parent zone belongs to another account. Do I need to contact client services?

Yes. For security purposes, we do not allow customers to create child zones for existing parent zones without proper authorization. Please see “Transferring to another Dyn account” above.

• I’m trying to add NS records to a node, but they’re not listed in the dropdown, or I get the error “Cannot add a NS at a node with children”.

To prevent zones from being accidentally placed in a broken state, safeguards in the user interface disallow the creation of NS records at any node with children. The client services team will be able to assist you in replacing the node atomically, without causing resolution loss.

<< DNS Knowledge Base