System Records: Why Some DNS Records Are Protected

Every DNS zone contains records that are critical to its operation — records that define the zone's authority and delegation. These are commonly called system records, and DNS providers protect them from direct modification to prevent accidental breakage.

What Are System Records?

System records are DNS records that the platform creates and manages automatically when you add a zone. They define how the zone functions at a fundamental level:

These records exist at the zone apex (the bare domain, like example.com) and are essential for DNS resolution to work. Without them, resolvers cannot find your zone or determine which DNS servers are authoritative for it.

System records are sometimes called "protected records", "managed records", or "infrastructure records" depending on the DNS provider.

Why Are System Records Protected?

SOA Record Protection

The SOA (Start of Authority) record controls zone transfers, negative caching, and serial number tracking. If the SOA were deleted or misconfigured:

• Secondary nameservers would stop synchronizing
• NXDOMAIN responses could be cached for too long (or not at all) — see TTL best practices for how the SOA minimum field controls this
• Zone transfer mechanisms would break
• The zone would violate the DNS specification (every zone must have exactly one SOA)

DNScale manages SOA records automatically — incrementing the serial number on every change and setting timing parameters optimized for reliability.

What the SOA Controls

The SOA record contains several fields that directly affect zone behavior:

If any of these fields were set incorrectly, the consequences would ripple across the entire zone. An MNAME pointing to a non-existent server would break NOTIFY-based updates. A serial number that was accidentally decreased would cause secondaries to ignore all subsequent changes.

Apex NS Record Protection

NS records at the zone apex declare which nameservers are authoritative for your domain. They work together with the delegation NS records at the parent zone (set at your registrar) to form the chain of trust in DNS.

DNScale's own NS records (ns1.dnscale.eu, ns2.dnscale.eu, etc.) are protected and cannot be removed or modified — they keep the zone connected to the anycast infrastructure.

However, you can add additional NS records at the apex for multi-provider DNS setups. For example, if you use both DNScale and another provider, you can add that provider's nameservers alongside DNScale's:

example.com.  NS  ns1.dnscale.eu.     ← protected (cannot be removed)
example.com.  NS  ns2.dnscale.eu.     ← protected (cannot be removed)
example.com.  NS  hydrogen.ns.hetzner.com.  ← user-added (can be removed)
example.com.  NS  oxygen.ns.hetzner.com.    ← user-added (can be removed)

This ensures the zone's apex NS records match your registrar delegation when using multiple providers.

Apex NS Records and Registrar Delegation

A common question is why apex NS records need to match the nameservers configured at your registrar. Understanding the relationship requires knowing how DNS delegation works.

The Two-Level NS System

When a resolver looks up your domain, two sets of NS records are involved:

1. Parent zone NS records (at the registrar/TLD) — non-authoritative "hints" that bootstrap the lookup by telling resolvers where to find your zone
2. Child zone NS records (at the apex) — the authoritative declaration of which servers serve your zone

Per RFC 2181 Section 6, the child zone's NS records are authoritative and take precedence in resolver caches, while the parent's delegation records are non-authoritative hints used only for bootstrapping.

What Happens When They Diverge

When the parent and child NS records don't match, DNS resolution doesn't break outright — but mismatches cause real problems:

• Lame delegations — the parent points to a server that doesn't serve the zone, causing timeouts and SERVFAIL responses
• Increased latency — resolvers retry against non-responsive servers before finding one that works
• Reduced resilience — fewer effective nameservers means less redundancy during outages or DDoS attacks
• Unpredictable behavior — different resolver implementations handle mismatches differently, leading to inconsistent results across networks
• DNSSEC failures — if the child NS set includes servers that don't serve DNSSEC-signed responses, some resolvers may get validation failures

Apex NS records should match your registrar's delegation. The child zone's NS set is authoritative (RFC 2181) and takes precedence in resolver caches, while the parent's delegation NS records are non-authoritative hints used for bootstrapping. When they diverge, mismatches can cause lame delegations, increased latency, and unpredictable behavior across resolver implementations.

Changing Your Nameservers

To change the nameservers for your domain, update them at your domain registrar — not in your DNS zone. The registrar updates the parent zone (e.g., .com, .eu), and your DNS provider updates the apex NS records to match.

If you're migrating to DNScale from another provider:

1. Note the DNScale nameservers assigned to your zone (shown in the dashboard)
2. Update the nameservers at your registrar
3. Wait for propagation (typically 24-48 hours for NS changes)

When migrating, you can use zone import to bring your existing records into DNScale before switching nameservers. This lowers disruption risk when both providers serve matching data and the old provider stays active during the transition.

What Other Records Are Protected?

Beyond SOA and apex NS records, there are additional records that DNS providers may manage or restrict:

DNSSEC Records

DNSSEC introduces additional record types that are auto-managed:

• DNSKEY — contains the public keys used to verify signatures
• RRSIG — contains the actual signatures for each record set
• NSEC/NSEC3 — proves the non-existence of records (used for authenticated denial)

These records are generated and rotated automatically by the signing infrastructure. Manually modifying them would break DNSSEC validation across the entire zone.

Records That Are NOT Protected

All other record types are fully under your control:

The only restriction on user-managed records is standard DNS rules — for example, a CNAME cannot coexist with other record types at the same name.

Subdomain NS Records Are Not Protected

While apex NS records are system records, subdomain NS records are fully user-managed. You can create, update, and delete NS records on any subdomain to delegate it to a different provider:

# Delegate a subdomain to AWS Route 53
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "aws",
    "type": "NS",
    "content": "ns-123.awsdns-12.com",
    "ttl": 3600
  }'

This is a standard DNS operation called subdomain delegation — see the NS record guide for more examples. Subdomain delegation is commonly used in multi-provider DNS deployments and DNS delegation by region.

What Happens If You Try to Modify a System Record

Adding Third-Party NS Records (Multi-Provider)

You can add additional NS records at the apex to support multi-provider DNS. This is useful when you want resolvers to query both DNScale and another provider for redundancy. Add the other provider's nameservers via the API or dashboard, and update your registrar delegation to include all nameservers.

Deleting DNScale NS Records

If you try to delete DNScale's own nameservers, the API returns a 403 Forbidden response:

{
  "status": "error",
  "error": {
    "code": "PROTECTED_RECORD",
    "message": "protected record type cannot be modified: DNScale nameservers (ns1/ns2.dnscale.eu, ns1/ns2.dnscale.com) cannot be removed"
  }
}

User-added NS records (e.g. a second provider's nameservers) can be deleted normally.

SOA Records

SOA records are fully protected — create, update, and delete operations all return 403 Forbidden:

{
  "status": "error",
  "error": {
    "code": "PROTECTED_RECORD",
    "message": "protected record type cannot be modified: SOA records are managed automatically and cannot be modified"
  }
}

Via Infrastructure as Code Tools

If you use Terraform or DNSControl, you can manage third-party NS records at the apex alongside your other records. DNScale's own NS records are excluded from the sync process.

Summary

System records exist to keep your zone functional and correctly delegated. DNScale manages them so you can focus on the records that matter to your applications — A, AAAA, CNAME, MX, TXT, and everything else.

Related Topics

• What Is an NS Record — how NS records and delegation work
• What Is an SOA Record — SOA fields and zone authority
• What Is a DNS Zone — understanding zones and their structure
• DNSSEC Key Management — another category of auto-managed records (DNSKEY, RRSIG)
• DNS Record Types — the full list of user-managed record types
• Domain Registrar vs DNS Hosting — understanding the registrar's role in NS delegation