| name | dns-cutover-runbook |
| enabled | true |
| description | Use when performing dns cutover runbook — dNS cutover procedure covering
pre-checks, TTL reduction, cutover execution, validation, and rollback. Use
for domain migrations, CDN changes, load balancer swaps, or any DNS-dependent
infrastructure transition.
|
| required_connections | [{"prefix":"aws","label":"AWS Route53 (or DNS provider)"}] |
| config_fields | [{"key":"domain","label":"Domain / Record","required":true,"placeholder":"e.g., api.example.com"},{"key":"old_target","label":"Current Target","required":true,"placeholder":"e.g., old-alb-1234.us-east-1.elb.amazonaws.com"},{"key":"new_target","label":"New Target","required":true,"placeholder":"e.g., new-alb-5678.us-east-1.elb.amazonaws.com"},{"key":"record_type","label":"Record Type","required":false,"placeholder":"e.g., A, CNAME, ALIAS"}] |
| features | ["DEPLOYMENT","NETWORKING"] |
DNS Cutover Runbook Skill
Execute DNS cutover for {{ domain }} from {{ old_target }} to {{ new_target }}.
Workflow
Step 1 — Pre-Cutover Checklist
PRE-CUTOVER CHECKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RECORD DETAILS
Domain: {{ domain }}
Type: {{ record_type | "CNAME" }}
Current target: {{ old_target }}
New target: {{ new_target }}
Current TTL: ___ seconds
NEW TARGET VALIDATION
[ ] New target is reachable and responding
[ ] Health checks passing on new target
[ ] SSL certificate valid for {{ domain }} on new target
[ ] Application responses correct (test with Host header override)
[ ] Performance baseline captured on new target
[ ] Load test completed against new target (if applicable)
DEPENDENCIES
[ ] All services pointing to {{ domain }} identified
[ ] Internal DNS caches / hard-coded references audited
[ ] CDN or proxy configurations reviewed
[ ] Third-party integrations using {{ domain }} notified
[ ] Monitoring configured for both old and new targets
Step 2 — TTL Reduction (T-24h to T-48h)
TTL REDUCTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Reduce TTL to 60 seconds (from current value)
[ ] Wait for old TTL to expire (at least 1x old TTL duration)
[ ] Verify low TTL is propagated:
- dig {{ domain }} (check TTL in response)
- Test from multiple DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1)
[ ] Confirm TTL reduction has been live for ≥ old TTL duration
[ ] Document original TTL for restoration: ___ seconds
Step 3 — Cutover Execution
CUTOVER (T-0)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PRE-FLIGHT
[ ] Confirm change window with stakeholders
[ ] On-call engineer standing by
[ ] Monitoring dashboards open (both targets)
[ ] Rollback command prepared and ready
EXECUTE
[ ] Update DNS record: {{ domain }} -> {{ new_target }}
[ ] Record exact timestamp of change: ___
[ ] Verify change in DNS provider console
PROPAGATION MONITORING
[ ] Verify via dig (authoritative nameserver): ___
[ ] Verify via Google DNS (8.8.8.8): ___
[ ] Verify via Cloudflare DNS (1.1.1.1): ___
[ ] Verify via local resolver: ___
[ ] Full propagation confirmed at: ___
Step 4 — Post-Cutover Validation
POST-CUTOVER VALIDATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HEALTH (check at T+5min, T+15min, T+1h)
[ ] Application responding correctly via {{ domain }}
[ ] SSL certificate valid (no mixed content or cert errors)
[ ] HTTP status codes normal (no increase in 4xx/5xx)
[ ] Response times within baseline
[ ] No increase in error rates
TRAFFIC
[ ] Traffic arriving at new target (visible in metrics)
[ ] Traffic draining from old target
[ ] No split-brain (requests not bouncing between targets)
FUNCTIONALITY
[ ] Key user journeys tested (login, checkout, API calls)
[ ] Webhooks and callbacks resolving to new target
[ ] Email deliverability unaffected (MX records if changed)
Step 5 — Rollback Procedure
ROLLBACK (if issues detected)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trigger: [error rate >X%, latency >Xms, functionality broken]
Window: Rollback effective within ~60 seconds (low TTL)
Steps:
1. [ ] Revert DNS record: {{ domain }} -> {{ old_target }}
2. [ ] Verify revert in DNS provider console
3. [ ] Confirm propagation via dig queries
4. [ ] Verify traffic returning to old target
5. [ ] Confirm application health on old target
6. [ ] Notify stakeholders of rollback
7. [ ] Document failure reason for retry planning
Step 6 — Stabilization & Cleanup
STABILIZATION (T+1h to T+48h)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Monitor for 24-48 hours for late-propagating DNS caches
[ ] Increase TTL back to original value: ___ seconds
[ ] Verify no traffic reaching old target (after 48h)
[ ] Decommission old target (or schedule decommission)
[ ] Update documentation with new target details
[ ] Remove temporary monitoring for old target
[ ] Update infrastructure-as-code with new DNS records
[ ] Close change management ticket
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Produce a DNS cutover execution report with:
- Cutover summary (domain, old target, new target, timestamps)
- Pre-cutover validation results
- Propagation tracking with resolver-by-resolver confirmation
- Post-cutover health metrics comparison
- Issues and resolution (or rollback details if rolled back)
