/// article

Building A Runtime Snapshot For Fast Authoritative DNS Decisions

By lordfrancs3

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. Area Database Runtime Snapshot Main purpose Store source data Serve live DNS decisions Contains history Usually yes Usually no Contains inactive data Often yes Avoid when possible Used by control plane Yes Created by control plane Used by data plane Avoid per-query use Yes Query-time speed Depends on database Should be fast Validation Stores data, may enforce rules Should contain only valid state Versioning Stores many versions Loads selected active version 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