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 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 Records

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)
• 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.

Apex NS Records

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.

If apex NS records could be freely modified, users could accidentally:

• Remove all NS records — making the zone unresolvable
• Point to non-existent nameservers — causing lame delegations
• Create mismatches with the registrar — leading to unpredictable resolution behavior

DNScale sets apex NS records to your assigned nameservers (ns1.dnscale.eu, ns2.dnscale.eu, etc.) and keeps them in sync with the platform's infrastructure.

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
• Unpredictable behavior — different resolver implementations handle mismatches differently, leading to inconsistent results across networks

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)

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.

What Happens If You Try to Modify a System Record

In the Dashboard

The DNScale dashboard prevents you from creating or modifying SOA records or apex NS records. If you select NS as the record type and enter @ or leave the name blank, a warning explains that apex NS records are managed automatically.

Via the API

The API returns a 403 Forbidden response with a descriptive error:

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

For SOA records:

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

How Other Records Differ

All other record types (A, AAAA, CNAME, MX, TXT, SRV, CAA, etc.) are fully under your control. You can create, update, and delete them freely through the dashboard or API. The only restrictions are standard DNS rules — for example, a CNAME cannot coexist with other record types at the same name.

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)