Domain Delegation Explained: A Complete Guide to DNS Authority and Subdomain Management

Whether you're launching a new website, scaling a complex infrastructure, or simply trying to understand how the internet resolves domain names, domain delegation is a concept you cannot afford to overlook. It sits at the very heart of the Domain Name System (DNS) and determines how authority over domain names is distributed across the internet.

This guide breaks down everything you need to know about domain delegation — what it is, how it works, its key components, and the best practices that keep your DNS infrastructure reliable and performant.

What Is Domain Delegation?

Domain delegation is the process of transferring authoritative control over a specific domain or subdomain to a designated set of name servers. In practical terms, it means telling the internet: *"For questions about this domain or subdomain, ask these name servers — they're in charge."*

When a DNS query is made for a domain, resolvers follow a chain of authority. Domain delegation defines that chain. Without it, the DNS system — which handles billions of queries every day — would have no structured way to distribute responsibility across millions of domains.

Domain delegation is not just a technical formality. It directly affects:

• Website availability — incorrect delegation leads to DNS resolution failures
• Email deliverability — MX records must be reachable through properly delegated name servers
• Security — misconfigured delegation can expose domains to hijacking or spoofing
• Performance — well-structured delegation reduces DNS lookup latency

If you're registering a new domain and need a reliable foundation to build on, Domain Registration with AlexHost gives you full control over your DNS settings from day one.

Key Components of Domain Delegation

Understanding domain delegation requires familiarity with its core building blocks. Each component plays a specific role in the DNS hierarchy.

1. The Parent Domain

The parent domain is the domain that sits above the delegated domain in the DNS hierarchy. It holds the NS (Name Server) records that point resolvers toward the authoritative name servers for the child domain.

Example: If you are delegating sub.example.com, the parent domain is example.com. The DNS zone for example.com contains the NS records that delegate authority for sub.example.com to a different set of name servers.

At the top of the hierarchy sit the root name servers, which delegate authority to Top-Level Domain (TLD) registries (such as .com, .net, or .org). Those TLD registries, in turn, delegate authority to your domain registrar's name servers.

2. The Child Domain

The child domain is the domain or subdomain that is being delegated — the entity receiving authority. In the example above, sub.example.com is the child domain.

Child domains can be:

• Subdomains (e.g., api.example.com, mail.example.com, shop.example.com)
• Entire second-level domains (e.g., example.com delegated from the .com TLD registry)

3. NS Records (Name Server Records)

NS records are the fundamental mechanism of delegation. They specify which name servers are authoritative for a given domain or subdomain. When a DNS resolver encounters an NS record during a lookup, it knows to query those name servers for further information.

; NS records in the example.com zone delegating sub.example.com
sub.example.com.    IN    NS    ns1.childnameserver.com.
sub.example.com.    IN    NS    ns2.childnameserver.com.

Best practice dictates having at least two NS records (primary and secondary) to ensure redundancy. If one name server becomes unavailable, the other continues to serve DNS responses.

4. Glue Records

Glue records are a special type of DNS record that resolve a common circular dependency problem. Consider this scenario:

• You want to delegate sub.example.com to ns1.sub.example.com
• But to find ns1.sub.example.com, a resolver must first query sub.example.com
• This creates an infinite loop

Glue records solve this by including the IP address of the name server directly in the parent zone, bypassing the circular lookup.

; Glue records in the example.com zone
ns1.sub.example.com.    IN    A    203.0.113.10
ns2.sub.example.com.    IN    A    203.0.113.11

Glue records are mandatory when the name servers for a child domain are themselves subdomains of that child domain. They are stored at the domain registrar level and served by the TLD registry.

5. SOA Record (Start of Authority)

Every delegated zone should have a SOA record that defines administrative information about the zone, including:

• The primary name server
• The responsible party's email address
• Serial number (used for zone transfer versioning)
• Refresh, retry, expire, and minimum TTL values

The SOA record signals that a zone is properly configured and authoritative.

How Domain Delegation Works: Step-by-Step DNS Resolution

When a user types sub.example.com into their browser, a sophisticated resolution process unfolds behind the scenes. Here is exactly what happens:

Step 1: Recursive Resolver Query

The user's device sends a DNS query to a recursive resolver — typically operated by their ISP or a public DNS provider like Google (8.8.8.8) or Cloudflare (1.1.1.1). The resolver's job is to find the answer by querying the DNS hierarchy.

Step 2: Root Name Server Lookup

If the resolver doesn't have the answer cached, it queries one of the 13 root name server clusters. The root servers don't know the IP address of sub.example.com, but they know which name servers are authoritative for the .com TLD.

Root Server Response:
.com is handled by:
a.gtld-servers.net.
b.gtld-servers.net.
[...etc]

Step 3: TLD Name Server Lookup

The resolver queries the .com TLD name servers. These servers know which name servers are authoritative for example.com (as registered through your domain registrar).

TLD Server Response:
example.com is handled by:
ns1.registrar.com.
ns2.registrar.com.

Step 4: Parent Domain Name Server Lookup

The resolver queries ns1.registrar.com (the authoritative name server for example.com). This server holds the NS records for the delegation of sub.example.com.

Parent Domain Response:
sub.example.com is delegated to:
ns1.childnameserver.com.
ns2.childnameserver.com.

Step 5: Child Domain Name Server Lookup

The resolver now queries ns1.childnameserver.com — the authoritative name server for sub.example.com. This server returns the actual DNS records requested, such as an A record (IP address) or MX record (mail server).

Child Name Server Response:
sub.example.com.    IN    A    198.51.100.42

Step 6: Response Delivered

The recursive resolver returns the IP address to the user's browser, which then establishes a connection to the web server at that address. The entire process typically completes in milliseconds.

Each step in this chain represents a delegation of authority — from root to TLD to registrar to your hosting provider's name servers.

How to Delegate a Domain or Subdomain: Practical Steps

Whether you're delegating an entire domain to a new hosting provider or splitting off a subdomain to a separate DNS zone, the process follows a consistent pattern.

Step 1: Identify the Target Name Servers

Determine which name servers will be authoritative for the child domain. This is typically provided by:

• Your hosting provider (e.g., ns1.alexhost.com, ns2.alexhost.com)
• A dedicated DNS management service
• Your own self-hosted DNS infrastructure

If you're running your own servers and need full control over your DNS environment, VPS Hosting from AlexHost provides the root access and network reliability required to operate authoritative name servers.

Step 2: Add NS Records in the Parent Zone

Log in to your domain registrar's control panel and navigate to the DNS management section for the parent domain. Add NS records pointing to the delegated name servers.

Example — Delegating shop.example.com to a separate hosting environment:

shop.example.com.    3600    IN    NS    ns1.shophosting.com.
shop.example.com.    3600    IN    NS    ns2.shophosting.com.

Important: Set a reasonable TTL (Time to Live). A TTL of 3600 seconds (1 hour) is common. Lower TTLs allow faster propagation of changes but increase DNS query load.

Step 3: Add Glue Records If Necessary

If your child domain's name servers are subdomains of the child domain itself, contact your registrar to add glue records. This is done at the registrar level, not in your DNS zone file.

Step 4: Configure the Child Zone

On the delegated name servers, create the DNS zone for the child domain and add all necessary records:

; Zone file for shop.example.com
$ORIGIN shop.example.com.
$TTL 3600

@    IN    SOA    ns1.shophosting.com. admin.example.com. (
                  2024010101 ; Serial
                  3600       ; Refresh
                  900        ; Retry
                  604800     ; Expire
                  300 )      ; Minimum TTL

@    IN    NS     ns1.shophosting.com.
@    IN    NS     ns2.shophosting.com.
@    IN    A      198.51.100.42
www  IN    A      198.51.100.42
@    IN    MX  10 mail.shophosting.com.

Step 5: Verify Propagation

DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, depending on TTL values and caching behavior. Use tools like:

• dig (Linux/macOS): dig NS shop.example.com @8.8.8.8
• nslookup (Windows): nslookup -type=NS shop.example.com
• Online tools: dnschecker.org or whatsmydns.net

Domain Delegation vs. DNS Hosting: Understanding the Difference

These two concepts are closely related but distinct:

You can register a domain with one provider and delegate it to name servers operated by a completely different provider. This is extremely common — for example, registering a domain with a budget registrar but hosting DNS with a provider that offers superior performance or advanced features.

For businesses that need professional email alongside their web presence, Email Hosting from AlexHost integrates seamlessly with your DNS configuration, ensuring correct MX record setup and reliable mail delivery.

Common Domain Delegation Scenarios

Scenario 1: Moving a Domain to a New Hosting Provider

When migrating from one host to another, you update the NS records at your registrar to point to the new provider's name servers. The new provider's DNS servers then become authoritative for your domain.

Key tip: Configure all DNS records on the new name servers *before* changing the NS records at the registrar. This minimizes downtime during the transition.

Scenario 2: Delegating a Subdomain to a SaaS Platform

Many SaaS platforms (e.g., e-commerce platforms, CDN providers) require you to delegate a subdomain to their name servers. For example, delegating shop.yourdomain.com to a hosted e-commerce platform while keeping www.yourdomain.com on your main hosting.

Scenario 3: Splitting Infrastructure Across Multiple Providers

Large organizations often delegate different subdomains to different infrastructure providers:

• api.example.com → Cloud provider A
• cdn.example.com → CDN provider B
• mail.example.com → Dedicated email infrastructure

This architecture requires careful DNS management but enables best-of-breed infrastructure choices. A Dedicated Server can serve as a reliable anchor for your primary DNS zone while subdomains are delegated to specialized providers.

Scenario 4: Internal DNS Delegation

In enterprise environments, internal domains (e.g., corp.internal) are often delegated to internal DNS servers that are not publicly accessible. This allows organizations to manage internal resources (intranet sites, internal APIs, printers) through the same DNS infrastructure as their public domains.

Security Considerations in Domain Delegation

Domain delegation introduces several security risks that administrators must actively mitigate.

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses are authentic and haven't been tampered with. When delegating a domain, DNSSEC requires:

1. Signing the child zone with a Zone Signing Key (ZSK) and Key Signing Key (KSK)
2. Adding DS (Delegation Signer) records to the parent zone
3. Establishing a chain of trust from the root down to your zone

DNSSEC is strongly recommended for any domain handling sensitive data or financial transactions. Pair DNSSEC with an SSL Certificate to provide both DNS-level and transport-level security for your domain.

Subdomain Takeover

Subdomain takeover occurs when a subdomain's DNS records point to a resource (e.g., a cloud service, CDN endpoint) that no longer exists, allowing an attacker to claim that resource and serve malicious content under your domain.

Prevention:

• Audit DNS records regularly and remove stale delegations
• Monitor for unclaimed resources associated with your subdomains
• Use DNS monitoring tools that alert on unexpected changes

Registrar Account Security

Since domain delegation is controlled at the registrar level, your registrar account is a high-value target. Protect it with:

• Strong, unique passwords
• Two-factor authentication (2FA)
• Registrar lock (also called domain lock or transfer lock) to prevent unauthorized transfers

DNS Cache Poisoning

Cache poisoning attacks attempt to inject fraudulent DNS records into resolvers' caches, redirecting users to malicious sites. DNSSEC is the primary defense against this attack vector.

Best Practices for Domain Delegation

Applying these best practices will keep your DNS infrastructure secure, reliable, and maintainable.

✅ Use Multiple Name Servers

Always configure at least two name servers for redundancy. Ideally, they should be geographically distributed and operated on separate network infrastructure to eliminate single points of failure.

✅ Set Appropriate TTL Values

• High TTL (86400 seconds / 24 hours): Reduces DNS query load and improves performance. Use for stable records.
• Low TTL (300–900 seconds): Allows faster propagation of changes. Use temporarily before planned migrations.

✅ Document All DNS Changes

Maintain a change log for every DNS modification, including:

• What was changed
• Why it was changed
• When it was changed
• Who made the change

This documentation is invaluable during incident response and audits.

✅ Monitor DNS Health Continuously

Implement monitoring that alerts you to:

• Unexpected NS record changes
• DNS resolution failures
• Unusual query patterns (potential DDoS or reconnaissance)
• Certificate expiration (relevant to DNSSEC and SSL)

✅ Test Before Propagation

Use dig or nslookup to query your new name servers directly before updating NS records at the registrar. This confirms the zone is correctly configured before the delegation goes live.

# Query the new name server directly before delegation
dig A sub.example.com @ns1.childnameserver.com

✅ Implement DNSSEC

Enable DNSSEC on all public-facing domains, especially those handling authentication, payments, or sensitive user data.

✅ Audit Delegations Periodically

Review all NS delegations quarterly. Remove delegations for decommissioned subdomains and verify that active delegations still point to the correct, operational name servers.

Troubleshooting Common Domain Delegation Issues

Issue: DNS Not Resolving After Delegation Change

Cause: Old TTL values causing cached responses to persist.

Solution: Wait for the previous TTL to expire. In future, lower TTL values before making changes.

Issue: Circular Dependency / Glue Record Missing

Cause: Name servers are subdomains of the delegated domain, but glue records weren't added.

Solution: Contact your registrar and request glue records for the name server IP addresses.

Issue: Partial Resolution (Works in Some Locations, Not Others)

Cause: DNS propagation is still in progress, or some resolvers are caching old records.

Solution: Wait for full propagation (up to 48 hours). Use dnschecker.org to monitor global propagation status.

Issue: Email Stops Working After Delegation

Cause: MX records not configured in the new zone, or the new name servers aren't authoritative yet.

Solution: Verify MX records are present in the child zone. Confirm NS delegation is complete before decommissioning old DNS.

Issue: DNSSEC Validation Failures

Cause: DS records in the parent zone don't match the DNSKEY records in the child zone, or keys have been rotated without updating the parent.

Solution: Regenerate and re-publish DS records in the parent zone. Follow proper key rollover procedures.

Conclusion

Domain delegation is one of the foundational mechanisms that makes the internet's DNS system scalable, distributed, and manageable. By understanding how authority flows from root servers down through TLD registries, registrars, and hosting providers to your specific name servers, you gain the knowledge needed to architect reliable, secure, and performant domain infrastructure.

Whether you're delegating a single subdomain to a SaaS platform, migrating an entire domain to a new hosting provider, or building a complex multi-provider DNS architecture, the principles remain consistent: configure NS records correctly, add glue records where needed, verify your zone configuration before going live, and monitor continuously.

For a solid foundation to build your online presence, explore AlexHost's Shared Web Hosting for straightforward websites, VPS Hosting for environments requiring full DNS control, or Dedicated Servers for enterprise-grade infrastructure — all backed by the network reliability your DNS configuration depends on.

*Have questions about configuring DNS delegation for your AlexHost-hosted domain? Contact our support team — we're here to help you get it right.*