The DNS architecture decision record: why the TTL model you chose determines your failover speed ceiling and your cache propagation floor

Published 2026-07-17 · WhyChose

DNS decisions are made when a domain is registered, when a CDN or load balancer is introduced in front of the origin server, and when an infrastructure failure forces an emergency record update during an outage. The AI session that handles initial DNS setup is practically oriented and reaches a working state quickly: it walks through the DNS provider's control panel, adds the A record pointing the apex domain to the server IP, adds the CNAME for www, configures MX records for email delivery, adds the required TXT records for SPF, DKIM, and domain verification, points the nameservers to the DNS provider, and verifies that dig returns the correct records and that the service is reachable over HTTPS. The session succeeds when the domain resolves and the product is live. The domain setup is complete. The session closes.

What the AI session does not produce is the second half of the DNS decision. The session answers "how do I get the domain pointing at the server?" and delivers working DNS records. It does not ask: what is the TTL for each record type — the A record TTL determines the maximum propagation delay for any future IP change, the minimum achievable failover speed during an outage, and the effective ceiling on how quickly a CDN migration or server replacement can complete without a planned pre-migration TTL reduction; what is the TTL reduction procedure before a planned migration — if the A record TTL is 3600 seconds, reducing it must happen 3600 seconds before the planned change, which means at least one hour in advance with no benefit from reducing it later, but the actual safe practice is to reduce it 24 to 48 hours before a planned migration so that all resolvers in the global cache infrastructure have had time to expire their cached copy and re-query the authoritative nameserver with the new lower TTL; what is the automated failover model — whether DNS failover during an outage requires manual intervention (someone logs into Cloudflare at 2am and changes the A record) or is handled by health check pools that automatically reroute traffic when a health check fails, what the expected time from server failure to traffic rerouting is, and what percentage of users will experience a service interruption during the failover window based on the TTL and health check configuration chosen; what is the DNSSEC rationale — whether DNSSEC is enabled or deliberately left disabled and why, what the DS record propagation implications are if you need to change the DNSSEC configuration later, whether the CDN providers and load balancer services you use are compatible with DNSSEC-signed delegation chains, and what the monitoring strategy is for DNSSEC validation failures that cause intermittent resolution failures for users behind validating resolvers; what is the split-horizon DNS model — whether internal service names resolve differently than external names, which resolver handles internal names, and how the two zones are kept consistent during infrastructure changes and disaster recovery scenarios. Each of these questions has an answer that is not derivable from "the domain resolves and the HTTPS certificate is active" as the result of the DNS setup session. Each answer determines whether a 3am primary server failure results in automatic failover completing in 90 seconds or in a 60-minute window where 40% of users cannot reach the service, whether a CDN migration that takes 20 minutes in staging takes 4 hours in production because the production TTL was never reduced in advance, whether enabling DNSSEC during the security hardening session creates a latent 48-hour propagation dependency that surfaces during a CDN migration emergency, and whether internal service discovery fails during a disaster recovery event because the internal DNS resolver is hosted on the same infrastructure that the disaster recovery plan was designed to recover from. The answers are in the AI sessions. They are the rationale behind the TTL values, the record structure, and the provider configuration. They are almost never written down.

Two ways DNS decisions produce the wrong outcome in production

The 3600-second TTL and the 45-minute failover window

A developer-tools startup launches on a single VPS behind Cloudflare. The founding engineer sets up DNS in a late-night ChatGPT session: adds the A record for the apex domain pointing to the VPS IP, sets the Cloudflare proxy status to DNS-only (orange cloud off) for the initial setup to avoid Cloudflare IP conflicts with the SSH key setup, verifies the record resolves, enables the Cloudflare proxy (orange cloud on), confirms HTTPS works. The DNS setup session takes 40 minutes and the TTL is never discussed explicitly — Cloudflare's default TTL for proxied records is auto, which Cloudflare manages and which resolves to 300 seconds for external resolvers. For DNS-only records, the Cloudflare default is 3600 seconds. The session enabled and disabled the Cloudflare proxy during setup; the final state has the proxy enabled, and the effective TTL that external resolvers see for proxied records is the Cloudflare-controlled 300 seconds. The engineer does not know this — the session established working DNS, not a DNS TTL model.

Eight months later, the team decides to add a second VPS in a different region as a hot standby, to reduce the downtime risk from a single-server outage. The engineer creates the VPS, deploys the application, verifies it works via direct IP access. The plan is to configure Cloudflare health checks on the primary VPS's IP and configure a failover origin pool pointing to the standby. The configuration session starts, and the engineer opens the Cloudflare Load Balancing panel. Cloudflare Load Balancing requires a paid plan tier (at minimum the Pro plan, which was not the tier the startup was on). The session ends without completing the health check configuration. The engineer notes in a Notion document that "Cloudflare health checks need to be set up — requires paid plan." The Notion document is not read again.

Six months after that, the primary VPS experiences a kernel panic at 3:14am. The application returns 502 errors. The on-call engineer receives a PagerDuty alert at 3:17am, wakes up, and attempts to SSH into the primary VPS — no response. The engineer logs into the VPS provider control panel and initiates a hard restart. The restart completes at 3:31am. Application monitoring shows the service returning 200 responses again. The incident post-mortem notes 14 minutes of downtime. Three weeks after the incident, a customer emails to say they experienced 45 minutes of downtime during the incident — much longer than the 14 minutes in the post-mortem. Investigation reveals that the customer's ISP's recursive resolver is not Cloudflare's 1.1.1.1 or Google's 8.8.8.8 — it is the ISP's own resolver, which had cached the Cloudflare proxy IP with a 300-second TTL. When Cloudflare detected the proxied origin was unhealthy (3:18am, 4 minutes after the kernel panic started causing 502 errors), Cloudflare served 521 error pages for requests routed to the origin. But because the ISP's resolver had cached the Cloudflare proxy IP from a query made at 3:10am with a 300-second TTL, queries from the ISP's resolver continued going to the cached Cloudflare proxy IP until the TTL expired at 3:15am — and then re-cached it again at 3:16am (because the A record the resolver queries is the Cloudflare proxy IP, which did not change during the incident), re-querying every 300 seconds with the same result. The customer's DNS resolution was working correctly — the domain was resolving to Cloudflare's proxy IP — but Cloudflare was returning 521 because the origin was down. The 45-minute window was not caused by a DNS propagation delay at all; it was caused by the Cloudflare origin health check behavior under a paid plan that the startup did not have. The founding DNS setup session did not document whether Cloudflare Load Balancing was in scope, what tier it required, or what the fallback failover mechanism was for the plan tier the startup was actually on. The Notion note from the health check configuration session was the only record of the gap, and it had not been acted on.

The DNSSEC enablement and the CDN migration incident

A fintech startup processes card payments through an API hosted on AWS. During the initial security hardening session, a security-conscious engineer runs through a CIS benchmark checklist for new AWS deployments. The checklist includes "Enable DNSSEC for the domain." The engineer enables DNSSEC through the domain registrar's control panel, waits for the DS record to propagate to the TLD zone (Route 53's hosted zone is updated with the DNSKEY records, the registrar creates the DS record at the .com TLD zone), and verifies DNSSEC with dnssec-analyzer.tnetconsulting.net. The verification shows "Secure — all signatures valid." The security session closes. DNSSEC is now enabled. The rationale — why DNSSEC was enabled (checklist compliance, specific threat model concern, or regulatory requirement), whether the CDN and third-party services used by the startup are DNSSEC-compatible, and what the procedure is to disable DNSSEC if it creates problems later — is not documented.

Eight months later, the startup migrates its API from CloudFront to Fastly for better global latency and a more flexible WAF configuration. The migration plan is to update the CNAME record for api.example.com from the CloudFront distribution domain to the Fastly service domain, then verify that the API is reachable through the new CDN. The engineer updates the CNAME in Route 53, verifies from their workstation that dig api.example.com returns the Fastly domain, tests three API endpoints via curl — all return 200. The deployment is marked complete at 2:30pm on a Tuesday.

At 8:47pm the same day, the on-call engineer receives a customer report that the API is intermittently failing for some of their users. The monitoring dashboard shows overall API request success rate at 94% — lower than usual but not triggering the 90% alert threshold. Error log analysis shows HTTP 504 timeouts from specific source IP ranges but normal responses from others. The on-call engineer checks CloudFront — the old distribution is still serving the domain for some requests, which does not make sense given the CNAME was updated six hours ago. At 11:15pm, a second engineer joins and runs DNSSEC validation checks. dnssec-analyzer shows: "Bogus — RRSIG validation failed for api.example.com CNAME." Fastly's service domain does not have the DNSSEC signing infrastructure compatible with Route 53's DNSSEC signing chain: the CNAME record at api.example.com is signed by Route 53's Zone Signing Key, but the Fastly domain the CNAME points to does not serve DNSSEC-signed records, causing the validation chain to break at the CNAME target. Resolvers operated by Google (8.8.8.8), Cloudflare (1.1.1.1), and several ISPs that perform DNSSEC validation are returning SERVFAIL for api.example.com queries — not 404, not a connection refusal, but a complete failure to resolve. Users behind non-validating resolvers are reaching the API successfully through Fastly. Users behind validating resolvers are receiving DNS resolution failures and falling back to whatever the application does when the API is unreachable.

The fix is to disable DNSSEC for the domain. Disabling DNSSEC requires removing the DS record from the TLD zone. The engineer logs into the domain registrar to remove the DS record. The registrar's control panel allows disabling DNSSEC, which initiates the DS record removal request. The TLD registry propagates DS record removals on a schedule — the .com TLD propagates DS record changes every 15 minutes to an hour, but the change must then propagate through the global resolver infrastructure. DNSSEC-validating resolvers that have cached the DS record will continue attempting validation for the DS record's TTL (which varies by TLD but is commonly 86400 seconds — 24 hours — for DS records in the .com zone). The DS record removal begins propagating at 11:45pm. At 1:00am, DNSSEC validation errors begin decreasing as resolvers pick up the DS record removal. By 6:00am the following morning, DNSSEC validation failures have dropped to zero. The total incident duration from CDN migration completion at 2:30pm to full DNSSEC validation failure resolution at 6:00am is 15.5 hours. The DNSSEC enablement decision made during the security hardening session had one line in the checklist: "Enable DNSSEC ✓." The CDN migration plan had no pre-migration step to verify that Fastly's service domain was compatible with the existing DNSSEC signing chain. Both gaps trace to the same cause: the DNSSEC enablement session documented the completion ("DNSSEC enabled, verification shows secure") but not the operational constraints the enablement created for future infrastructure changes.

Three structural properties that DNS decisions determine

The TTL model per record type and the propagation ceiling

The TTL model is the specification of the time-to-live value for each DNS record type, the rationale for each value, and the operational procedure for changing a record in the future given the current TTL. Without this model, every DNS change is a free-form operation: the engineer updates the record, observes that it resolves on their workstation, and considers the change complete — unaware that resolvers that cached the record 30 seconds before the change will continue returning the old value for up to TTL seconds, and that the fraction of users affected depends on how recently each user's resolver last queried the record relative to the TTL expiry. The TTL model must specify four properties per record type. First, the value and its justification: the A record TTL is 300 seconds because the service uses a single-origin deployment where planned IP changes require a migration window and unplanned failures are addressed through automated health check failover (which operates within the Cloudflare proxy TTL that resolvers see for proxied records, not the configured A record TTL); the MX record TTL is 3600 seconds because email delivery tolerates longer propagation delays and the mail server IP changes rarely; the TXT records for SPF and DKIM have TTLs of 3600 seconds because they change only when email sending infrastructure changes, which is planned in advance; CNAME records for subdomains pointing to CDN or third-party services have TTLs of 300 seconds because CDN provider migrations are a planned operational event requiring a pre-migration TTL reduction. Second, the pre-migration TTL reduction procedure: before any planned change to an A record, CNAME, or other record that routes production traffic, the TTL must be reduced to 60 seconds at a minimum of TTL-current seconds before the planned migration (if the current TTL is 3600 seconds, the reduction must be made 3600 seconds — 60 minutes — before the planned change, but the safe practice is to reduce 24 to 48 hours before the change so that all global resolvers have had time to expire their cached copy and re-query the nameserver with the new lower TTL). The procedure must be a checklist item in the infrastructure change runbook: "Verify TTL is 60 seconds or less and that 24 hours have elapsed since the TTL reduction before proceeding." Third, the resolution time measurement: the time to complete a DNS propagation check after a record change is measured using a multi-resolver query (querying Google 8.8.8.8, Cloudflare 1.1.1.1, and a geographically distributed set of resolvers) to confirm that the new value is returned from all test resolvers before announcing the migration complete. A change that resolves correctly from the engineer's workstation but has not propagated to all resolvers globally is a partial migration, not a completed migration. Fourth, the record-specific propagation monitoring: for high-traffic records like the apex A record or the API CNAME, propagation monitoring must be part of the migration runbook, not an optional sanity check. The CDN decision record specifies which CDN provider's domain the CNAME points to and whether the CDN provider has DNSSEC-signing compatibility requirements; the TTL model must account for the pre-migration TTL reduction procedure specific to CNAME changes where the target domain is changing, not just the record value.

The automated failover model and the health check recovery surface

The automated failover model determines whether traffic is automatically rerouted when a primary server or region becomes unhealthy, what the expected time from failure detection to traffic rerouting is, and what percentage of users experience service interruption during the failover window. Without a documented failover model, the de facto failover model is manual: an engineer receives an alert, logs into the DNS provider, changes the A record to the standby IP, and waits for propagation. The manual failover time is the sum of the alert latency (time from failure to alert, commonly 1 to 5 minutes), the response time (time from alert to engineer logged into the DNS provider, commonly 5 to 30 minutes for on-call engineers who may be asleep), the manual change time (1 to 5 minutes to navigate the DNS provider interface and update the record), and the propagation time (bounded by the A record TTL). A 300-second TTL with a 15-minute mean response time produces a median manual failover time of 20 minutes. An automated health check failover with a 30-second check interval, a 2-failure threshold, and a 30-second TTL produces a worst-case automated failover time of 90 seconds. The difference between 20 minutes and 90 seconds is not a technical accident — it is the consequence of whether the founding DNS setup session established an automated failover configuration or left failover as a manual procedure. The automated failover model must document five properties. First, the health check protocol and endpoint: an HTTP health check to /health is preferable to / because the root path may redirect to an authentication page, may be cached by the CDN, or may return 200 from a cache even when the origin is down; the /health endpoint should return 200 if and only if the application can process requests, including database connectivity and dependency checks. Second, the health check interval and failure threshold: the interval (30, 60, or 120 seconds) multiplied by the failure threshold (2 or 3 consecutive failures before marking unhealthy) determines the minimum time from a server failure to the DNS provider marking the origin unhealthy; a 30-second interval with a 2-failure threshold detects failures in 60 to 90 seconds; a 60-second interval with a 3-failure threshold takes 3 to 4 minutes. Third, the pool configuration and failover behavior: which origins are in the primary pool, which origins are in the fallback pool, and what happens when the entire primary pool is unhealthy (route to fallback pool, or return an error page configured at the DNS provider level). Fourth, the failover TTL: the TTL of the DNS record served to resolvers when the DNS provider is managing health check failover — this is often separate from the standard record TTL and is set lower specifically to enable fast re-routing. Fifth, the failover verification procedure: how the team confirms that the automated failover functioned correctly during a real outage, including reviewing the DNS provider's health check logs to confirm that the primary was marked unhealthy, that the failover origin began receiving traffic, and that the failover TTL change propagated to external resolvers within the expected window. The load balancer decision record specifies whether there is a layer-7 load balancer in front of the origin servers; DNS health check failover and load balancer health checks interact — if the load balancer itself is healthy but the upstream origins it serves are all failing, a DNS health check that probes the load balancer's IP will see a 502 response from the load balancer and correctly mark the origin pool unhealthy; a DNS health check that probes the load balancer's /health endpoint (which may return 200 even when upstreams are down if the health check is not wired to upstream status) will incorrectly mark the pool healthy while users receive 502 responses.

The DNSSEC configuration and the DS record propagation blast radius

The DNSSEC configuration rationale is the explanation of whether DNSSEC is enabled or disabled and why, what operational constraints the DNSSEC configuration creates for future DNS changes, and what the recovery procedure is if the DNSSEC signing chain becomes invalid. The rationale must address three properties. First, the enablement decision and its scope: DNSSEC is enabled with a specific threat model in mind — cache poisoning prevention (where an attacker on the network path between a user and a recursive resolver can inject forged DNS responses redirecting the domain to a malicious IP), DANE support (where DNSSEC-signed TLSA records pin the TLS certificate to the DNS record, enabling verification without a certificate authority), or compliance requirement (where a security framework checklist or regulatory control requires DNSSEC as a configuration item). If DNSSEC is enabled for checklist compliance without an underlying threat model, this must be noted explicitly — because DNSSEC creates operational risk (DNSSEC validation failures during infrastructure changes, DS record propagation delays during DNSSEC modifications, compatibility requirements for CDN and third-party providers) that must be weighed against the security benefit for the specific deployment. If DNSSEC is disabled, the rationale must state why — commonly that the CDN or third-party services in use are not DNSSEC-compatible, that the operational overhead is not justified by the threat model, or that the service will operate entirely behind a DNSSEC-validating CDN that provides its own signing chain. Second, the CDN and third-party compatibility audit: before enabling DNSSEC, every CNAME record that points to a CDN, SaaS service, or third-party provider domain must be audited for DNSSEC compatibility — specifically, whether the CNAME target domain serves DNSSEC-signed responses, and whether the CDN or provider's edge infrastructure is compatible with the signing chain established by the DNS provider. CDN providers including Fastly, some Cloudflare configurations, some Akamai configurations, and most small CDN providers do not support DNSSEC-signed CNAME chains; enabling DNSSEC with an active CNAME pointing to a non-DNSSEC-compatible target creates an immediate or latent validation failure depending on whether DNSSEC-validating resolvers in the user base are common. Third, the DNSSEC modification and recovery procedure: if the DNSSEC configuration must be changed — because a CDN migration introduces an incompatible CNAME target, because the signing key must be rotated, or because DNSSEC must be disabled — the procedure must account for the DS record propagation time at the TLD level. Disabling DNSSEC must be performed at least 24 to 48 hours before a planned CDN migration that would break the DNSSEC signing chain; the procedure is to remove the DS record at the TLD, wait for propagation (typically 24 to 48 hours for .com), confirm via dnssec-analyzer or Verisign's DNSSEC debugger that resolvers are no longer attempting DNSSEC validation for the domain, and then proceed with the CDN migration. A CDN migration that breaks the DNSSEC chain cannot be fixed by reverting the CNAME — the CNAME reversion will return the CDN traffic to the previous provider, but DNSSEC-validating resolvers may have cached the SERVFAIL response and will continue refusing to resolve the domain for the CNAME TTL period. The security threat model and compliance decision record specifies the threat model for the deployment, including whether DNS-based attacks (cache poisoning, BGP route hijacking, DNS amplification) are in scope; the DNSSEC configuration rationale should reference the threat model decision record so that a future security review can evaluate whether the DNSSEC configuration is still appropriate given the current threat model, CDN configuration, and compliance requirements.

Three AI session types that embed DNS decisions without documenting them

The domain registration and DNS setup session is where the TTL model is implicitly set but never described as a choice. The session is driven by a practical goal — getting the domain pointing at the server, email configured, and HTTPS working — and the TTL values that result from the setup are whatever the DNS provider's defaults are for the record types configured. Cloudflare's default TTL for DNS-only A records is 3600 seconds; for proxied records, Cloudflare controls the TTL that external resolvers see and sets it to 300 seconds automatically. Route 53's default TTL for new records is 300 seconds. Porkbun's default TTL for new records is 300 seconds. The default is not wrong — 300 seconds is a reasonable TTL for most A records. What is missing from the setup session is the explanation of what the TTL means for future operations: that a 300-second TTL means any unplanned IP change will affect some users for up to 300 seconds after the change, that a planned migration requires reducing the TTL to 60 seconds at least 300 seconds before the change to avoid propagation lag for resolvers that cache the 300-second value, and that the pre-migration TTL reduction is a two-step operation (reduce, wait, then change) that must be planned as a 24-to-48-hour sequence, not a same-day operation. The session also does not evaluate whether the DNS provider chosen in the setup session supports health check failover and at what plan tier, what the fallback is if automatic failover is not available, or whether DNSSEC is recommended given the CDN and third-party services the domain will use for CNAME records. These are setup-time decisions that have no visible effect at setup time — they only manifest when there is an outage, a migration, or a security incident. None of them are captured by "the domain resolves and HTTPS is green" as the session completion criterion.

The CDN or load balancer migration session embeds DNS decisions as a sequence of record changes without a pre-migration TTL reduction step and without a DNSSEC compatibility check. The session is focused on getting the CDN configured and traffic routed through it: it creates the CDN distribution, configures the origin, updates the DNS record (CNAME for api.example.com to the CDN distribution domain, or A record change if using CDN Anycast IPs), verifies that a curl to the domain returns 200 through the CDN, and marks the migration complete. The pre-migration TTL reduction is a step that must be performed 24 to 48 hours before the migration and is not prompted by the session's immediate goal of "get the CDN working." If the current TTL is 300 seconds, the practical impact of skipping the reduction is small — some resolvers carry stale records for up to 5 minutes. But if the current TTL is 3600 seconds (because the record was set with a DNS-only configuration before the Cloudflare proxy was enabled, or because the DNS provider's default was higher than 300 seconds), the migration session will update the CNAME and then see partial resolution — some users going through the new CDN, others still hitting the old origin for up to 60 minutes. The CDN migration session also does not verify DNSSEC compatibility: it confirms that the new CDN distribution domain resolves (it will, because the CNAME target is a valid domain), but does not check whether the new CDN provider's edge infrastructure serves DNSSEC-signed responses compatible with the signing chain of the authoritative zone. The DNSSEC compatibility failure is not detectable from the session engineer's workstation unless that workstation's resolver is a DNSSEC-validating resolver — most development machines use the local network's resolver (often not DNSSEC-validating) or 8.8.8.8 (which does validate DNSSEC and would show a failure, but the engineer may attribute the failure to a network condition rather than DNSSEC). The multi-region deployment decision record specifies whether traffic is distributed across multiple regions using DNS-based routing (latency-based routing, geolocation routing, or weighted routing); a CDN migration in a multi-region deployment requires updating DNS routing policies across all regions, not just updating the CNAME for a single distribution domain, and the TTL model must account for the propagation time across each region's DNS entries independently.

The infrastructure failover session during an outage discovers the TTL model through its operational consequences rather than its documented specification. The session begins when monitoring alerts fire: the primary server is unhealthy, the service is returning errors, and the engineer must restore availability. The fastest path is to update the DNS record to point to the standby server. The engineer logs into the DNS provider, locates the A record for the domain, and changes the IP address to the standby server. The change is saved. The engineer verifies from their workstation that the domain now resolves to the standby IP. The service is restored from the engineer's perspective. What the session has not verified is how many users are still hitting the failed primary because their resolver cached the old IP before the change was made. If the TTL is 300 seconds, the propagation lag affects users who queried the record in the 5 minutes before the change — a significant fraction during a high-traffic incident. If the TTL is 3600 seconds, the propagation lag affects users who queried in the 60 minutes before the change. The incident post-mortem will note the time from alert to DNS change as the "downtime duration" and will not capture the tail of users still hitting the failed server after the DNS change was made, because those users do not appear as service errors in the application monitoring — they appear as connection timeouts or errors before the application layer is reached. The session also typically reduces the TTL "for next time" — setting it to 60 seconds immediately after the incident — without documenting that this is a temporary reduction that must be returned to the standard TTL after the standby is confirmed stable, or that the reduced TTL creates higher query load on the authoritative nameserver. The disaster recovery decision record specifies the RTO target for the service; the DNS failover procedure is the first step in the DR runbook, and if the TTL model was not documented, the on-call engineer discovering a 3600-second TTL during a 2am outage cannot know whether the RTO target can be met with a manual DNS change or whether the 60-minute propagation window exceeds the RTO by design.

The five sections of a DNS architecture decision record

The first section documents the DNS provider selection and nameserver configuration. The DNS provider choice (Cloudflare, Route 53, Porkbun, NS1, or a DNS service bundled with a registrar) determines the feature set available for health checks, failover pools, DNSSEC management, and programmatic record management via API. The decision record must specify the authoritative nameservers (the NS records delegated from the TLD zone), the rationale for the provider choice (API programmability for infrastructure-as-code DNS management, Anycast network coverage, health check failover capability, DNSSEC management tooling, or geographic latency optimization), whether there is a secondary authoritative DNS provider for redundancy (a primary and secondary nameserver that independently serve the zone, so that a primary provider outage does not make the domain unresolvable), and the API credentials model for programmatic DNS management (how the infrastructure-as-code tooling authenticates to the DNS provider API to manage records, where those credentials are stored, and what the rotation procedure is). The secrets management decision record specifies the vault or secrets store in use; DNS API credentials are infrastructure secrets with significant blast radius — an attacker with DNS API credentials can redirect the domain to a malicious IP, add TXT records for subdomain takeover, or disable DNSSEC while rerouting traffic — and they must be treated as high-criticality secrets with the same rotation cadence and access controls as database credentials. The decision record must also specify whether the domain registrar and the DNS provider are the same service (Cloudflare Registrar + Cloudflare DNS, Route 53 Registrar + Route 53 DNS) or different services, because the registrar controls the NS records at the TLD level and a registrar outage or account compromise affects the ability to change nameservers, which is a different failure mode from a DNS provider outage.

The second section documents the TTL model per record type. For each DNS record type in use, the TTL model states the value, the rationale, and the pre-migration procedure. The A record TTL and rationale: if the service uses Cloudflare's proxy (orange cloud), external resolvers see the Cloudflare-controlled TTL (300 seconds for most Cloudflare proxy configurations), and the effective propagation window for a failover event is the time for the health check to detect the failure plus the Cloudflare proxy TTL; if the service uses DNS-only (grey cloud), the TTL is explicitly configured and must be chosen based on the acceptable failover window and the query rate implications for the authoritative nameserver. The CNAME TTL for CDN-pointed subdomains: CDN migrations require a pre-migration TTL reduction, and the CNAME TTL determines the required lead time for the reduction. The MX record TTL: email delivery is tolerant of longer propagation delays (mail servers retry failed deliveries for up to 72 hours by default), so MX records with TTLs of 3600 to 86400 seconds are common and do not cause delivery problems during mail server migrations. The TXT record TTL: SPF, DKIM, DMARC, and domain verification TXT records change rarely and can have TTLs of 3600 to 86400 seconds; however, DKIM key rotation requires updating the TXT record for the new selector, and if the old selector TXT record is not retired promptly, the TXT lookup overhead for mail servers is increased. The pre-migration TTL reduction procedure must be a documented runbook step: 48 hours before a planned migration, reduce the TTL for the affected record to 60 seconds; 24 hours later, verify that the new TTL is being returned by external resolvers (dig @8.8.8.8 api.example.com shows TTL 60); proceed with the migration; after the migration is stable for 24 hours, restore the TTL to the standard value for the record type. The infrastructure decision record specifies the server IPs, load balancer IPs, and CDN origins; the TTL model must be revisited whenever a new IP is added to the infrastructure or when the traffic routing model changes, because TTL values that were appropriate for a single-origin deployment may be too long for a multi-region active-active deployment where failover speed is a product reliability requirement.

The third section documents the automated failover model. The specification must state whether DNS-based automated failover is configured (using Cloudflare Load Balancing, Route 53 health routing, NS1 monitor-based routing, or equivalent), the health check protocol, endpoint, interval, and failure threshold for each monitored origin, the pool configuration (primary pool members, fallback pool members, and fallback pool behavior when all pool members are unhealthy), the failover TTL (the TTL of the DNS response served when the DNS provider is managing health check routing), the expected failover time from the moment of origin failure to the moment that external resolvers receive the failover DNS response, and the monitoring and alerting for health check events (how the team is notified that a health check failover has occurred, and what the recovery procedure is to restore the primary origin to the pool after the failure is resolved). If automated failover is not configured — because it requires a paid DNS provider plan that the team has not purchased, or because the deployment is a single-server configuration without a standby origin — the decision record must state the manual failover procedure, the expected time to complete the manual procedure (including the engineer response time and the DNS propagation wait), and the RTO implication of the manual procedure relative to any published SLA. The decision record must also specify what happens when the failover pool is exhausted (all origins are unhealthy): whether the DNS provider serves an error page, returns the last known healthy origin, or returns SERVFAIL — because SERVFAIL for a failed-over domain means users cannot even reach an error page explaining the outage, which is a different user experience from a 503 served from the DNS provider's error page infrastructure. The multi-region deployment decision record specifies whether the standby region is active-passive (brought up only during a failover event) or active-active (serving traffic in the normal operating state); the DNS failover model interacts with the active-passive vs active-active distinction because an active-passive standby that is not running the application when failover is triggered requires application startup time before it can pass the health check, extending the effective failover time beyond what the DNS propagation model alone would predict.

The fourth section documents the DNSSEC configuration and key management model. The specification must state whether DNSSEC is enabled or disabled, the specific rationale for the configuration (threat model, compliance requirement, or operational constraint that determined the choice), the DNSSEC signing key type and algorithm in use (ECDSA P-256 with SHA-256 is the current recommended algorithm; RSA 2048 with SHA-256 is more widely compatible with older resolvers), the key signing key (KSK) and zone signing key (ZSK) rotation cadence and procedure (automatic rotation managed by the DNS provider, or manual rotation requiring DS record update at the TLD), the CDN and third-party compatibility audit results (which CNAME targets were verified as DNSSEC-compatible before DNSSEC was enabled), the DS record propagation procedure and expected duration for any future DNSSEC configuration change, and the monitoring for DNSSEC validation failures. The monitoring specification must include the tool and frequency (daily checks against dnssec-analyzer or Verisign's DNSSEC debugger, or a continuous monitoring service that alerts on DNSSEC validation failures), the alert response procedure (who receives the alert, what immediate action prevents user-facing failures while the root cause is diagnosed), and the distinction between a DNSSEC signing failure (the DNS provider's signing infrastructure is not producing valid signatures for the zone) and a DNSSEC validation failure at the client (a resolver is rejecting a valid signature because of a DS record mismatch or a compatibility issue with the CDN target). If DNSSEC is disabled, the decision record must state what alternative controls address the cache poisoning threat model that DNSSEC is designed to address — commonly the combination of DNS over HTTPS (DoH) or DNS over TLS (DoT) for resolver-to-client communication and Cloudflare's 1.1.1.1 or similar trusted resolver for origin DNS resolution, which prevents cache poisoning on the resolver-to-client path even without DNSSEC validation.

The fifth section documents the split-horizon DNS model. The specification must state whether split-horizon DNS is in use (whether any DNS name resolves differently for internal clients than for external clients), the internal resolver mechanism (private Route 53 hosted zone, Kubernetes CoreDNS, dnsmasq on a VPN gateway, or an explicitly configured internal DNS server), which DNS names are split-horizon (the full list of names that have different internal vs external resolutions, with the internal IP and the external IP for each), the consistency maintenance procedure (how internal and external zone records are kept consistent when an IP changes — a change to the external A record for api.example.com must also be reflected in the internal override, or internal clients will continue routing to the old IP while external clients use the new IP), and the disaster recovery behavior of the internal resolver. The disaster recovery specification must address: whether the internal resolver is co-located with the infrastructure it serves (a private DNS server on the primary region's VPC fails when the primary region fails, preventing internal service discovery at the exact moment when disaster recovery coordination is most needed), what the fallback resolution behavior is when the internal resolver is unavailable (whether clients fall back to the public authoritative nameserver and receive external IPs — which may not be routable from within the private network — or fail to resolve entirely), and whether the disaster recovery runbook includes a step to verify internal DNS resolution after failover. The container orchestration decision record specifies whether Kubernetes is in use; Kubernetes CoreDNS is the standard internal DNS resolver for service discovery within a Kubernetes cluster, providing resolution for service names like my-service.my-namespace.svc.cluster.local; if the cluster also uses CoreDNS to provide split-horizon resolution for external names (so that api.example.com resolves to the cluster-internal IP of the API deployment rather than the external CDN IP, avoiding egress charges and CDN-to-cluster latency for internal service-to-service calls), the CoreDNS configuration constitutes the internal zone of a split-horizon setup, and the consistency maintenance procedure must include CoreDNS rewrite rules whenever the external DNS configuration changes for any name that has an internal override. The new CTO onboarding problem with DNS is that every record in the zone looks identical regardless of whether it was set thoughtfully or by default: the A record with TTL 3600 looks the same as the A record with TTL 300 in the DNS provider interface; the Cloudflare health check pool that was evaluated but not configured looks the same as the health check pool that was never considered; the DNSSEC enablement that was done because a checklist said to looks the same as the DNSSEC enablement done because the service uses DANE certificate pinning. The incoming technical leader inherits a DNS configuration they cannot audit from the DNS provider panel alone — the TTL model, the failover rationale, the DNSSEC compatibility constraints, and the split-horizon scope exist only in the session where each record was configured, the session where DNSSEC was enabled with a checklist link in the context, and the incident post-mortem where someone noted "we should lower the TTL" as an action item and then closed the ticket as complete after lowering it to 300 without documenting why 300 was chosen or what the pre-migration reduction procedure should be for the next planned migration. WhyChose's open-source extractor surfaces these domain registration sessions, CDN migration sessions, and failover sessions from AI chat history before the 45-minute propagation window and the 15-hour DNSSEC incident become the team's primary documentation of why the TTL model matters.

The domain registration session that set the A record TTL to 3600 seconds because that was the DNS provider's default, the CDN migration session that updated the CNAME without a pre-migration TTL reduction step or a DNSSEC compatibility check, and the 2am failover session that changed the A record manually and discovered the propagation window by counting the users still hitting the failed server — each produced DNS decisions whose operational consequences (a 45-minute propagation window during a single-server failure, a 15-hour DNSSEC incident during a planned CDN migration, an internal split-horizon zone that failed with the infrastructure it was designed to provide discovery for) exceed what a TTL model documenting the pre-migration reduction procedure, an automated failover configuration eliminating the 2am manual change, a DNSSEC compatibility audit before enablement, and a split-horizon consistency procedure would have cost to specify at the time the founding DNS decisions were made. The decisions are in the AI sessions: the TTL value accepted implicitly because the DNS provider default appeared in the form field, the DNSSEC checkbox enabled because the security hardening checklist item said to enable it, the health check pool deferred because the plan tier required an upgrade, the internal CoreDNS rewrite rule added for cost optimization without documenting that it constitutes a split-horizon configuration. WhyChose's open-source extractor surfaces these domain registration sessions, CDN migration sessions, and infrastructure failover sessions as structured decision records before an unplanned failover reveals that the TTL was set to 3600 seconds by default three years ago and has never been reviewed, before a CDN migration incident reveals that the DNSSEC configuration made for a security checklist is incompatible with the new CDN provider's edge infrastructure, and before a disaster recovery test reveals that the internal DNS resolver that provides service discovery for the entire microservices cluster is co-located with the primary region that the disaster recovery plan was designed to recover from. The decisions never written down in a DNS deployment are the TTL model per record type with the pre-migration reduction procedure that turns a 60-minute propagation surprise into a planned 24-hour sequence, the automated failover configuration that turns a 2am manual DNS change into a 90-second automatic rerouting, the DNSSEC configuration rationale with the CDN compatibility audit that prevents a 15-hour DNSSEC incident from being the first time the team learns that DNSSEC disablement requires 48 hours of DS record propagation, and the split-horizon model with the disaster recovery consistency procedure that ensures the internal resolver does not become the single point of failure for the recovery it was meant to outlast.

Further reading