DNS Delegation for DNScale Regions

When you create a zone in DNScale, you must point your domain's delegation at the registrar to the nameservers for the selected region. This process, called nameserver delegation, tells the global DNS infrastructure which authoritative servers are responsible for answering queries about your domain.

How DNS Delegation Works

Delegation is the mechanism that makes the DNS hierarchy function. When a recursive resolver needs to find the A record for example.com, it follows a delegation chain:

1. The root servers direct the resolver to the .com TLD servers
2. The TLD servers look up the NS records registered for example.com and direct the resolver to those nameservers
3. The authoritative nameservers (e.g., DNScale) answer with the requested record

The NS records at the TLD level come from your registrar. When you update nameservers at your registrar, you are updating this delegation — telling the entire internet where to find authoritative answers for your domain.

# Trace the full delegation chain for a domain
dig +trace example.com
 
# See just the NS delegation at the TLD level
dig NS example.com +short
ns1.dnscale.eu.
ns2.dnscale.eu.

Tip: The delegation at your registrar and the NS records in your zone should match. If they disagree, resolvers may get inconsistent answers. DNScale automatically sets the correct NS records in your zone when you create it.

Nameserver Sets by Region

DNScale operates nameservers across multiple regions. Each nameserver is deployed on an anycast network, meaning queries are routed by BGP toward a topologically preferred available point of presence.

EU Region

Best for domains primarily serving European audiences. Nameservers are located across multiple European points of presence.

• ns1.dnscale.eu
• ns2.dnscale.eu

GLOBAL Region

Best for domains serving a worldwide audience. Nameservers are located across points of presence in Europe, North America, and Asia.

• ns1.dnscale.com
• ns2.dnscale.com

EU_GLOBAL Region

Best for domains that need comprehensive global coverage with strong European presence. Uses nameservers from both regions for maximum geographic diversity and redundancy.

• ns1.dnscale.eu
• ns1.dnscale.com
• ns2.dnscale.eu
• ns2.dnscale.com

Tip: Use exactly the names above. Remove old nameservers when switching regions to avoid "mixed delegation" and inconsistent responses.

Choosing the Right Region

Your choice of region affects DNS resolution latency for your users. Consider where your audience is located:

For a detailed explanation of how DNScale distributes queries geographically, see Global DNS Resolution Balancing.

How Anycast Improves Delegation

Each DNScale nameserver hostname (e.g., ns1.dnscale.eu) resolves to an anycast IP address that is announced from multiple physical locations. When a resolver queries ns1.dnscale.eu, BGP routes the query to a preferred DNScale point of presence based on network policy and topology. This means:

• Lower latency — queries are answered by the geographically closest server
• Routing-level failover — if one location withdraws its route, traffic normally reconverges toward another available location
• DDoS resilience — attack traffic is distributed across all locations rather than hitting a single server
• No single point of failure — even with only two nameserver hostnames, the underlying infrastructure is distributed

You can verify the anycast behavior by checking which server responds to your queries:

# Check the A and AAAA records for DNScale nameservers
dig A ns1.dnscale.eu +short
dig AAAA ns1.dnscale.eu +short
 
dig A ns1.dnscale.com +short
dig AAAA ns1.dnscale.com +short

Registrar Update Steps (General)

Use the correct set of nameservers for your zone's region, then replace all existing NS records at the registrar level:

1. Sign in to your domain registrar and open the domain's DNS or Nameservers section
2. Choose Custom nameservers (or similar)
3. Delete all existing nameserver entries
4. Add the DNScale nameservers for your zone's region (see above)
5. Save/apply. If prompted to confirm glue/hostnames, accept the provided hostnames
6. Wait for propagation (typically minutes to a few hours); you can verify with dig NS example.com

Tip: Always replace all nameservers in a single change. A partial swap where some nameservers point to the old host and some to DNScale will cause intermittent resolution failures.

Registrar-Specific Notes

Cloudflare Registrar

In the "Domain Registration" tab, switch to "Custom nameservers," remove the two Cloudflare defaults, add the DNScale nameservers, and save. Cloudflare will show a confirmation banner while propagating.

GoDaddy

Under Domain > Manage DNS > Nameservers > Change > Enter my own nameservers, replace all existing entries with the DNScale set, and save. Approve any confirmation dialogs.

Namecheap

Domain List > Manage > Nameservers > Custom DNS. Remove old entries, add DNScale nameservers, and click the checkmark to save.

Gandi

Domain > Nameservers > "Change" > Custom. Replace existing nameservers with the DNScale set and validate.

Squarespace Domains

Use the registrar's custom nameserver settings. Remove the default nameservers, add the DNScale nameservers, and save the change.

Route 53 Domains

In the Registered Domains console, edit the NS records and replace with DNScale nameservers (Route 53 allows four entries).

Pre-Migration Checklist

Before updating nameservers, confirm your DNScale zone is fully configured. This reduces disruption risk during the propagation period when resolvers start querying DNScale:

1. Create the zone in DNScale with the correct region
2. Add all records — verify every A, AAAA, CNAME, MX, TXT record exists. Use zone import to migrate records from your previous provider
3. Verify email records — confirm SPF, DKIM, and DMARC records are present to avoid email delivery issues
4. Check CAA records — if you use CAA, ensure they are configured in the new zone so TLS certificate issuance continues to work
5. Lower TTL at the old provider — reduce TTL on all records to 300 seconds at least 24 hours before the switch
6. Test the new zone by querying DNScale nameservers directly (see Verification below)

Verification

After updating nameservers at your registrar, verify the delegation is correct:

# NS records should return only DNScale nameservers for the chosen region
dig NS yourdomain.com
;; ANSWER SECTION:
yourdomain.com.  86400  IN  NS  ns1.dnscale.eu.
yourdomain.com.  86400  IN  NS  ns2.dnscale.eu.
 
# SOA record should show a DNScale nameserver in the MNAME field
dig SOA yourdomain.com @ns1.dnscale.eu
;; ANSWER SECTION:
yourdomain.com.  3600  IN  SOA  ns1.dnscale.eu. ...
 
# Verify A record is served correctly
dig A yourdomain.com @ns1.dnscale.eu +short
192.0.2.1
 
# Compare with a public resolver
dig A yourdomain.com @8.8.8.8 +short
192.0.2.1
 
# Check propagation across multiple resolvers
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "$ns: $(dig +short NS yourdomain.com @$ns)"
done

Troubleshooting Delegation Issues

Nameservers Not Updating

TLD-level NS record changes can take up to 48 hours to propagate. The TTL on TLD NS records is typically 24-48 hours, so resolvers that recently cached the old delegation will continue using the old nameservers until their cache expires.

# Check what the TLD servers say (bypass resolver cache)
dig NS yourdomain.com +trace

Lame Delegation

A lame delegation occurs when the nameservers listed at the registrar do not actually serve the zone. This results in SERVFAIL responses. Ensure the zone exists in DNScale and that the nameserver hostnames match exactly.

Mixed Delegation

If some NS records point to DNScale and others point to a different provider, resolvers may get different answers depending on which nameserver they query. This causes intermittent failures. Always replace all nameservers in a single change.

DNSSEC Issues After Migration

If DNSSEC was enabled at your previous DNS host, the DS records at the registrar may still reference the old DNSSEC keys. This causes validation failures. Either remove the DS records at the registrar before switching, or coordinate the DNSSEC migration.

Zone Not Resolving After Delegation

If your domain stops resolving after changing nameservers:

1. Verify the zone exists in DNScale and contains the expected records
2. Query DNScale nameservers directly: dig A yourdomain.com @ns1.dnscale.eu
3. If the direct query works but public resolvers fail, propagation is still in progress
4. If the direct query fails, check that the zone is active and records are configured correctly
5. Flush your local DNS cache to see the latest delegation

Managing Delegation with Infrastructure as Code

If you manage your DNS through automation, you can configure delegation alongside your records:

• Terraform — the DNScale Terraform provider manages zones and records programmatically
• DNSControl — supports DNScale as a provider for declaring DNS configuration as code

Both tools let you define your zone, records, and region in version-controlled configuration files, ensuring your DNS setup is reproducible and auditable.

Conclusion

Correct nameserver delegation is the foundation of working DNS. Without it, no resolver can find your zone or its records. By choosing the right DNScale region, following the delegation process carefully, and verifying with dig, you help keep your domain reliably served from DNScale's anycast infrastructure. Avoid partial swaps — replace all nameservers in one planned change to reduce resolution splits.