Building A Runtime Snapshot For Fast Authoritative DNS Decisions

Authoritative DNS must answer quickly.

When a recursive resolver asks for a DNS record, the authoritative DNS server should not perform heavy work before replying. It should not rebuild routing policy during the query. It should not call several external systems before returning an answer.

DNS steering can involve many inputs:

Requested name
Record type
Requester IP
EDNS Client Subnet
Country
ASN
Network prefix
Routing policy
Endpoint pool
Endpoint health
Fallback rule
TTL

If the DNS server processes all of this from raw data on every query, DNS answers can become slow and fragile.

That is why production DNS steering systems often need a runtime snapshot.

A runtime snapshot is a prepared copy of the data needed to answer DNS queries quickly.

It is built before the query arrives.

It is validated before it is used.

It is loaded by the authoritative DNS data plane.

Then the data plane can answer queries using local prepared state.

The main idea is simple:

Do heavy preparation before the query.
Do fast lookup during the query.

What Is A Runtime Snapshot?

A runtime snapshot is a versioned, ready-to-use view of DNS steering state.

It contains the data needed by the authoritative DNS layer to answer live queries.

It may include:

Active zones
Active records
Supported record types
Routing policies
Requester classification rules
GeoIP mappings
ASN mappings
Network prefix indexes
Endpoint pools
Endpoint health state
Fallback chains
TTL values
Default answers
Policy version
Snapshot version

The snapshot should not be a random dump of every database table.

It should be a prepared structure made for fast DNS decisions.

The authoritative DNS data plane should be able to read it quickly and answer:

What name was requested?
What record type was requested?
What requester signal is available?
Which policy matches?
Which endpoint is healthy?
Which answer should be returned?
What TTL should be used?

Why Runtime Snapshots Matter

DNS steering needs speed and safety.

The data plane must answer queries while recursive resolvers are waiting.

If each query depends on slow systems, the DNS path becomes risky.

Bad query-time design:

DNS query arrives.
Query database.
Load policy.
Check endpoint table.
Call health service.
Look up GeoIP data.
Look up ASN data.
Build answer.
Return response.

This design can fail in many places.

Better design:

DNS query arrives.
Read prepared runtime snapshot.
Match policy.
Return answer.

The control plane can do the heavy work earlier.

The data plane can keep live DNS answering small and fast.

This follows the principle discussed in Article 2:

The control plane prepares the decision.
The data plane returns the answer.

DNS Answering Should Avoid Slow Dependencies

A DNS steering data plane should avoid depending on these systems during every query:

Primary database
External health check API
GeoIP file parser
Remote object storage
Policy editor service
Control plane API
Large raw network dataset

These systems may still be important.

But they should be used before the live query path.

If the database becomes slow, DNS answering should not automatically become slow.

If the health system is delayed, the data plane should still have a prepared health state to use.

If the control plane is unavailable, the data plane should continue answering from the last valid snapshot for as long as the design allows.

This keeps DNS answering more predictable.

What The Snapshot Should Contain

A runtime snapshot should contain only what the data plane needs to answer queries.

1. Active DNS Names

The snapshot should include managed names.

Example:

www.example.com
api.example.com
video.example.com
download.example.com

Each name should map to the policy or record set needed for answering.

2. Record Types

The snapshot should include supported record types.

Example:

A
AAAA
CNAME
TXT
MX

For DNS steering, A and AAAA records are often the most important because they return IPv4 and IPv6 addresses.

DNS record behavior is defined in DNS standards such as RFC 1034 and RFC 1035.

Sources:

https://www.rfc-editor.org/rfc/rfc1034
https://www.rfc-editor.org/rfc/rfc1035

3. Routing Policies

The snapshot should include prepared routing policy.

Example:

If country is PH, use Manila pool.
If country is SG, use Singapore pool.
If ASN is 64501, use Manila pool.
If no rule matches, use global pool.

Policy should already be validated before reaching the data plane.

4. Endpoint Pools

The snapshot should include endpoint pools.

Example:

Manila pool:
203.0.113.10
203.0.113.11

Singapore pool:
198.51.100.20
198.51.100.21

Global pool:
192.0.2.30

The data plane should not need to query a database to know which endpoints belong to each pool.

5. Health State

The snapshot should include prepared health state.

Example:

203.0.113.10 healthy
203.0.113.11 unhealthy
198.51.100.20 healthy
198.51.100.21 healthy

The data plane should not run heavy health checks during each DNS query.

It should use the latest prepared health state.

6. Fallback Rules

The snapshot should include fallback paths.

Example:

Manila fallback:
Singapore

Singapore fallback:
Tokyo

Unknown requester fallback:
Global pool

Fallback paths should already be checked for loops and missing targets.

7. GeoIP And ASN Indexes

The snapshot may include prepared network indexes.

Example:

IP prefix to country
IP prefix to ASN
Known resolver groups
Known network exceptions

These indexes should be built for fast lookup.

The data plane should not parse a large raw GeoIP file during live query handling.

8. EDNS Client Subnet Handling Rules

If the system supports EDNS Client Subnet, the snapshot should include how ECS is handled.

Example:

Use valid ECS when present.
Use resolver IP when ECS is missing.
Ignore ECS with invalid prefix length.
Use default policy if requester cannot be classified.

ECS is defined in RFC 7871, while EDNS0 is defined in RFC 6891.

Sources:

https://www.rfc-editor.org/rfc/rfc7871
https://www.rfc-editor.org/rfc/rfc6891

9. TTL Values

The snapshot should include TTL values.

Example:

Normal answer TTL:
300 seconds

Fallback answer TTL:
60 seconds

Emergency answer TTL:
30 seconds

TTL should be part of policy.

It should not be guessed during query time.

10. Version Information

The snapshot should include version details.

Example:

Policy version:
42

Snapshot version:
2026-07-03-1005

Build time:
2026-07-03 10:05:00

Published by:
control plane

Versioning helps operators explain answers later.

What The Snapshot Should Not Contain

A runtime snapshot should not contain everything.

Avoid loading data that is not needed for live DNS answering.

Bad snapshot design:

All historical policy versions
All audit logs
All inactive zones
All deleted records
All unused endpoint groups
All unused GeoIP fields
All raw network intelligence
All operator account data
All dashboard-only data

This increases memory use and makes the data plane harder to manage.

A runtime snapshot should be narrow.

It should contain the active decision state, not the entire management system.

Runtime Snapshot Versus Database

The database is usually the source of truth.

The runtime snapshot is the prepared serving view.

They are not the same thing.

The database is good for storage, editing, history, and reports.

The snapshot is good for fast answering.

Building The Snapshot

A safe snapshot build process may look like this:

1. Read active zones and policies.
2. Read active endpoint pools.
3. Read latest approved health state.
4. Read required GeoIP and ASN data.
5. Build requester classification indexes.
6. Build routing decision tables.
7. Validate fallback chains.
8. Validate TTL values.
9. Validate answer records.
10. Create snapshot version.
11. Test the snapshot.
12. Publish it to the data plane.

The data plane should not receive a snapshot until it passes validation.

Validation Before Publishing

Validation is one of the most important parts of snapshot building.

The control plane should reject bad snapshots.

Examples of invalid snapshot data:

Policy points to missing pool.
Pool has no endpoint.
Fallback target does not exist.
Fallback chain loops.
TTL is invalid.
Record type is unsupported.
Endpoint IP address is invalid.
Zone has no safe default.
Health state is too old.
ECS rule has invalid prefix length.

These problems should be caught before the data plane loads the snapshot.

A bad snapshot can cause wrong answers at high speed.

Fast bad answers are still bad answers.

Atomic Snapshot Loading

Snapshot loading should be atomic.

Atomic means the data plane should use either the old valid snapshot or the new valid snapshot.

It should not use a half-loaded version.

Bad loading behavior:

Some policies from new snapshot.
Some pools from old snapshot.
Some health state missing.
Some fallback rules incomplete.

This can create wrong DNS answers.

Better behavior:

Load new snapshot separately.
Validate it in memory.
Switch active pointer to new snapshot.
Keep old snapshot available for rollback.

The switch should be clean.

At any moment, the data plane should know which snapshot is active.

Rollback

Rollback means returning to a previous known good snapshot.

This is important because a snapshot may pass basic validation but still cause unexpected behavior.

Example:

New policy passes validation.
But answer distribution changes too much.
Operators detect bad routing.
Rollback to previous snapshot.

A good system should keep recent known good snapshots.

Example:

Active snapshot:
Version 43

Previous snapshot:
Version 42

Rollback action:
Switch active snapshot from 43 to 42.

Rollback should be fast, controlled, and logged.

Last Known Good Snapshot

A last known good snapshot protects the data plane when new state cannot be built.

Example:

Control plane fails to build snapshot 44.
Snapshot 43 remains active.
DNS answering continues.
Alert is raised.

This is better than replacing working state with broken state.

A last known good snapshot should have age limits.

Example:

Snapshot age:
5 minutes, normal.

Snapshot age:
30 minutes, warning.

Snapshot age:
2 hours, critical.

Old state may become unsafe if endpoint health or routing policy changes.

Handling Stale Snapshot Data

A snapshot can become stale.

Example:

Snapshot built:
10:00 AM

Current time:
10:30 AM

Health state inside snapshot:
Too old

The system should define what happens when snapshot data becomes too old.

Possible rules:

Continue using last known good state for a limited time.
Use emergency fallback for affected services.
Lower TTL during stale state.
Raise alerts.
Stop accepting new risky answers.

Serving stale DNS data can improve resilience in some DNS designs. RFC 8767 discusses serving stale data to improve DNS resiliency.

Source:

https://www.rfc-editor.org/rfc/rfc8767

For DNS steering, stale data should be bounded and visible.

A slightly old safe answer may be better than no answer.

But very old state can become dangerous.

Snapshot Size Matters

A runtime snapshot should be bounded.

Bounded means its size should be controlled.

The data plane should not load unlimited data.

Important limits may include:

Number of active zones
Number of active records
Number of policy rules
Number of endpoint pools
Number of endpoint records
Number of network prefixes
Number of fallback chains
Memory used by indexes
Snapshot build time
Snapshot load time

A snapshot that grows without limit can harm DNS serving.

The goal is to keep the data plane fast and predictable.

Indexing For Fast Lookup

The snapshot should use lookup structures that help the data plane answer quickly.

Examples:

Name to policy map
Record type map
IP prefix lookup tree
ASN to policy map
Country to policy map
Pool to endpoint map
Endpoint health map
Fallback map

The exact implementation can vary.

The concept is what matters:

The snapshot should be shaped for fast DNS decisions, not raw storage.

Example: Query Using A Runtime Snapshot

Assume the data plane receives this query:

Requested name:
video.example.com

Record type:
A

Resolver IP:
203.0.113.50

ECS:
Missing

The data plane uses the active runtime snapshot.

Step 1:

Find video.example.com policy.

Step 2:

Classify resolver IP.
Country: PH
ASN: 64501

Step 3:

Match policy.
PH plus ASN 64501 uses Manila pool.

Step 4:

Check prepared health state.
Manila endpoint 203.0.113.10 is healthy.

Step 5:

Return answer.

DNS response:

video.example.com. 60 IN A 203.0.113.10

This should happen without database queries, health API calls, or raw file parsing.

Example: Snapshot Handles Fallback

Assume the same query:

Requested name:
video.example.com

Country:
PH

Preferred pool:
Manila

But snapshot health state says:

Manila:
Unhealthy

Singapore:
Healthy

Fallback rule inside snapshot:

If Manila is unhealthy, use Singapore.

DNS response:

video.example.com. 60 IN A 198.51.100.20

The data plane did not need to figure out a new fallback design.

It only applied prepared policy.

Example: Snapshot Rejects Bad Policy

Assume an operator creates this policy:

PH users use Manila pool.
Manila pool fallback is Singapore pool.
Singapore pool fallback is Manila pool.

If both pools are unhealthy, this can create a fallback loop.

The control plane should detect this before building or publishing the snapshot.

Validation result:

Snapshot rejected.
Reason: fallback loop detected.
Active snapshot remains unchanged.

The data plane keeps using the previous known good snapshot.

This protects live DNS answers.

Example: Snapshot With Missing Signal Defaults

A snapshot should include default behavior for missing signals.

Example:

If ECS is present and valid, use ECS.
If ECS is missing, use resolver IP.
If resolver IP country is unknown, use global endpoint.
If ASN is unknown, use country policy.

This makes query behavior predictable.

The data plane should not guess what to do with missing ECS, unknown ASN, or unknown country.

The snapshot should already contain the rule.

Publishing Snapshot Updates

Snapshot publishing should be controlled.

A simple publish flow:

Build snapshot.
Validate snapshot.
Write snapshot artifact.
Notify data plane.
Data plane loads snapshot.
Data plane validates snapshot locally.
Data plane switches active snapshot.
Data plane reports active version.

The data plane should report which version it is serving.

This helps operators confirm that all DNS nodes are using the expected state.

Multiple DNS Nodes

Many authoritative DNS deployments use more than one DNS node.

Each node should know which snapshot version it is serving.

Example:

DNS node 1:
Snapshot 42

DNS node 2:
Snapshot 42

DNS node 3:
Snapshot 41

This shows a problem.

One node is still serving the old version.

Operators should be able to detect this.

Useful metrics:

Active snapshot version per node
Snapshot load success
Snapshot load failure
Snapshot age
Snapshot memory use
Snapshot policy count
Snapshot endpoint count

Without this visibility, different DNS nodes may return different answers for reasons operators do not expect.

Snapshot Consistency

Consistency means the snapshot should describe one complete view of the system.

Example:

Policy version 42
Endpoint version 42
Health version 42
Geo index version 42
Fallback version 42

If the snapshot mixes unrelated versions, the data plane may make wrong decisions.

Example problem:

Policy points to a new pool.
Endpoint list is from an old version.
New pool does not exist in endpoint list.

A complete snapshot avoids this issue.

It packages related state together.

Snapshot Security

A runtime snapshot affects DNS answers.

It should be protected.

Practical controls:

Validate snapshot format.
Check snapshot version.
Use checksums to detect corruption.
Restrict who can publish snapshots.
Log publish events.
Keep rollback copies.
Reject malformed data.
Avoid loading untrusted files.

If the snapshot is corrupted or tampered with, DNS answers may be wrong.

Security should be part of snapshot design.

Snapshot And Memory Use

Runtime snapshots usually live in memory or in a fast local structure.

That means memory use matters.

A snapshot should not load unnecessary data.

Examples of waste:

Inactive zones
Unused countries
Unused city-level fields
Historical records
Archived policies
Old health events
Unused resolver lists
Dashboard-only data

Keep the snapshot focused on live DNS decisions.

This makes the data plane easier to run.

Snapshot And Query Logging

Every DNS decision should be traceable to a snapshot version.

Useful log fields:

Requested name
Record type
Resolver IP
ECS prefix, if present
Classified country
Classified ASN
Matched policy
Selected pool
Selected endpoint
Fallback reason
Health state used
Returned answer
TTL
Snapshot version
Policy version

These logs help answer:

Why did this query receive this answer?
Which policy version was active?
Was fallback used?
Was health state stale?
Did ECS affect classification?

Without snapshot version logging, troubleshooting becomes harder.

Snapshot Metrics

Operators should measure snapshot behavior.

Useful metrics:

Snapshot build time
Snapshot validation time
Snapshot size
Snapshot memory use
Snapshot load time
Snapshot load success rate
Snapshot load failure rate
Active snapshot version
Snapshot age
Policy count
Endpoint count
Pool count
Prefix count
Fallback chain count
Rejected snapshot count
Rollback count

These metrics show whether the runtime state remains healthy.

If snapshot build time grows too much, the control plane may fall behind.

If snapshot size grows too much, the data plane may use too much memory.

If rejected snapshots increase, policy quality may be declining.

Snapshot Testing

A snapshot should be tested before it is published.

Test cases may include:

Known country query
Unknown country query
Known ASN query
Unknown ASN query
ECS present
ECS missing
Preferred endpoint healthy
Preferred endpoint unhealthy
Fallback path used
Pool empty
Invalid record type
IPv4 answer
IPv6 answer
Default policy used
Emergency answer used

Each test should check:

Returned answer
TTL
Matched policy
Fallback reason
Health state used
Snapshot version

Snapshot testing helps catch problems before users see them.

Common Runtime Snapshot Mistakes

Mistake 1: Building The Snapshot During Query Time

The snapshot should be ready before the query arrives.

Do not build decision state inside the live DNS query path.

Mistake 2: Loading Too Much Data

The snapshot should contain active decision state.

It should not contain the entire control plane database.

Mistake 3: No Validation

A snapshot that is not validated can spread bad answers quickly.

Mistake 4: No Atomic Load

Half-loaded state can create unpredictable answers.

Load the new snapshot separately, then switch cleanly.

Mistake 5: No Rollback

If a new snapshot causes wrong answers, rollback should be ready.

Mistake 6: No Version Logging

Operators need to know which snapshot caused which answer.

Mistake 7: No Age Limits

A last known good snapshot is useful, but it should not be trusted forever without alerting.

Mistake 8: Data Plane Depends On The Database

If the data plane calls the database for each query, database issues can affect DNS answering.

Practical Snapshot Design Rules

A practical runtime snapshot should follow these rules:

Contain only active DNS decision state.
Be built outside the live query path.
Be validated before publishing.
Use clear versioning.
Include fallback rules.
Include prepared health state.
Include TTL policy.
Support atomic loading.
Keep previous known good versions.
Expose active version per DNS node.
Log snapshot version in DNS decisions.
Track snapshot age, size, and load status.

These rules help keep authoritative DNS decisions fast and safe.

The Main Design Principle

The main design principle is this:

A runtime snapshot should turn complex routing state into a fast, validated, local decision view for the authoritative DNS data plane.

This keeps the control plane and data plane separate.

The control plane can validate, build, test, and publish.

The data plane can answer quickly using prepared state.

How This Fits The Article Series

The earlier articles explained the foundation:

Article 1:
How authoritative DNS influences traffic direction.

Article 2:
The control plane and data plane of DNS steering.

Article 3:
Why DNS steering is not load balancing.

Article 4:
Why latency, geography, and network distance are different.

Article 5:
How requester classification works.

Article 6:
How EDNS Client Subnet can help or hurt DNS steering.

Article 7:
Why fallback logic is required.

Article 8:
How health checks become DNS answer policy.

This article explains how to prepare all of that information for fast DNS answering.

A runtime snapshot is the bridge between policy design and live authoritative DNS decisions.

Key Takeaways

A runtime snapshot is a prepared, validated, versioned copy of the data needed for live DNS decisions.

It allows the authoritative DNS data plane to answer quickly without calling slow systems per query.

A good snapshot contains active zones, records, policies, endpoint pools, health state, fallback rules, GeoIP and ASN indexes, TTL values, and version metadata.

A snapshot should not contain the entire control plane database.

Snapshots should be validated before publishing.

Snapshot loading should be atomic.

The system should keep previous known good snapshots for rollback.

Snapshot age, size, load status, and active version should be monitored.

Every DNS decision should be traceable to a snapshot version.

The best runtime snapshot is narrow, validated, fast to read, safe to roll back, and clear enough to explain.

In the next article, we will discuss Keeping DNS Answers Fast While Updating Routing Policy.

Sources

RFC 1034, Domain Names, Concepts and Facilities:
https://www.rfc-editor.org/rfc/rfc1034

RFC 1035, Domain Names, Implementation and Specification:
https://www.rfc-editor.org/rfc/rfc1035

RFC 6891, Extension Mechanisms for DNS:
https://www.rfc-editor.org/rfc/rfc6891

RFC 7871, Client Subnet in DNS Queries:
https://www.rfc-editor.org/rfc/rfc7871

RFC 8767, Serving Stale Data to Improve DNS Resiliency:
https://www.rfc-editor.org/rfc/rfc8767