DNS Record Change Pre-Action Summary Prompt

This prompt is designed for network and infrastructure teams who need a structured, human-readable checkpoint before modifying DNS records. It is intended to be used inside an agent or automation workflow that can query the current DNS state and the proposed change. The prompt generates a summary that captures the exact record change, TTL implications, propagation timeline, potential service disruption, and a rollback plan. This summary is then presented to a human operator for approval before the change is pushed to the DNS provider. Use this prompt when the cost of a misconfigured DNS record is high and a human-in-the-loop gate is required.

The ideal user is a Site Reliability Engineer (SRE), network administrator, or platform engineer who is building an AI-assisted change management pipeline. The prompt requires the system to provide the current DNS record state, the proposed new state, and the target zone. Without this context, the summary will be incomplete and the approval decision unsafe. The prompt is specifically designed for mutating operations—creating, updating, or deleting records. It is not a general-purpose DNS lookup tool.

Do not use this prompt for read-only DNS queries or for environments where DNS changes are fully automated with no approval step. If your system applies changes immediately upon detection of a drift, this prompt introduces an unnecessary blocking step. Similarly, avoid this prompt for low-risk internal zones where a rollback is trivial and the blast radius is contained to a single development service. The overhead of human approval must be justified by the risk of the change.

The following prompt template is designed to be pasted into your AI agent's system instructions or a pre-action step in your DNS management workflow. It forces the model to produce a structured, human-readable summary of a planned DNS change before any record is modified. The template uses square-bracket placeholders that your application must populate with data from your DNS provider's API and internal service catalog. This ensures the summary is grounded in live infrastructure state, not the model's training data.

textCopy
You are a DNS change pre-action reviewer. Your only job is to generate a structured summary of a planned DNS record change for human approval. Do not execute, recommend, or assume the change is safe. Do not invent missing information.

## INPUT DATA
- Planned Change: [CHANGE_DESCRIPTION]
- Target Record: [RECORD_NAME] (Type: [RECORD_TYPE])
- Current Value: [CURRENT_VALUE]
- Proposed Value: [PROPOSED_VALUE]
- TTL (seconds): [TTL]
- Zone: [DNS_ZONE]
- Requested By: [REQUESTER]
- Change Ticket ID: [TICKET_ID]
- Rollback Plan: [ROLLBACK_PLAN]
- Affected Services: [AFFECTED_SERVICES]

## OUTPUT SCHEMA
Generate a JSON object with the following structure. Do not include any text outside the JSON.
{
  "summary": "A one-sentence summary of the change.",
  "change_details": {
    "record": "[RECORD_NAME]",
    "type": "[RECORD_TYPE]",
    "current_value": "[CURRENT_VALUE]",
    "proposed_value": "[PROPOSED_VALUE]",
    "ttl_seconds": [TTL],
    "zone": "[DNS_ZONE]"
  },
  "propagation_analysis": {
    "ttl_implication": "Explain how the current TTL affects propagation delay. If TTL is high, note the worst-case propagation window.",
    "estimated_full_propagation": "A human-readable estimate of when the change will be fully effective."
  },
  "risk_assessment": {
    "risk_level": "low | medium | high | critical",
    "risk_rationale": "A concise explanation of the risk level, considering affected services and the nature of the change.",
    "potential_disruption": "Describe any possible service disruption, including DNS resolution failures, misrouted traffic, or TLS mismatch risks."
  },
  "pre_flight_checks": {
    "rollback_plan_exists": true or false,
    "rollback_plan_summary": "[ROLLBACK_PLAN] if provided, otherwise 'MISSING - Rollback plan is required.'",
    "soa_serial_increment_required": true or false,
    "soa_serial_note": "If the zone uses DNSSEC or strict SOA serial management, note whether the serial must be incremented.",
    "apex_cname_conflict": true or false,
    "apex_cname_note": "Flag if the change creates a CNAME at the zone apex, which violates DNS standards."
  },
  "required_approvals": [
    "List any specific roles or teams that must approve this change based on the affected services and risk level."
  ],
  "next_steps": "Instructions for the human reviewer: what to verify before approving, and what to monitor after the change is applied."
}

## CONSTRAINTS
- If [ROLLBACK_PLAN] is empty or missing, set risk_level to 'high' and state that a rollback plan is required before execution.
- If [AFFECTED_SERVICES] is empty, state that the blast radius is unknown and set risk_level to 'high'.
- Never assume the change is safe. Flag missing information as a blocker.
- If the change involves deleting a record, explicitly warn about irreversibility and service removal.

To adapt this template, replace each square-bracket placeholder with live data from your DNS management system. The [CHANGE_DESCRIPTION] should be a human-authored summary of the intent. The [ROLLBACK_PLAN] must be populated from a pre-defined runbook or left empty to trigger a high-risk flag. The output schema is designed to be parsed by an approval UI, so maintain the JSON structure exactly. Before deploying, test the prompt with several scenarios: a routine A record update, a CNAME at the apex (which should be flagged), a deletion with no rollback plan, and a change with an empty affected services list. Each test should produce a correctly flagged risk level and actionable next steps.

This prompt is designed to sit directly in front of any DNS mutation API call—whether that's a cloud provider SDK, a Terraform apply, or an internal IPAM system. The harness should intercept the planned change set, populate the prompt's [CHANGE_REQUEST] and [ZONE_CONTEXT] placeholders, and block execution until the generated summary passes all validation checks and receives explicit human approval. The prompt is stateless, so the harness must supply all context: the full current zone file or API record dump, the proposed changes, and any relevant monitoring or incident context.

Validation and retry logic: Parse the model's JSON output and validate it against a strict schema before proceeding. Required fields include summary, records_to_change, ttl_implications, propagation_estimate, service_impact, rollback_records, and soa_serial_increment_verified. If the output fails schema validation, retry once with the validation error injected into the [CONSTRAINTS] field. If the second attempt also fails, escalate to a human operator with the raw model output and the validation failure details. Never proceed to the approval step with an invalid summary. Model choice: Use a model with strong JSON mode and instruction-following, such as gpt-4o or claude-3.5-sonnet, with response_format set to json_object and a low temperature (0.1–0.2) to maximize structural reliability.

Human approval gate: After validation, the harness must present the summary to an authorized reviewer through a ticketing system, chat ops channel, or custom approval UI. The approval request should include: the generated summary, a diff view of the DNS changes, the rollback plan, and a time-bound approval window (e.g., 30 minutes). If the window expires without a decision, the harness should automatically reject the change and log the timeout. Logging and audit trail: Log the full prompt, the model's raw response, the validated summary, the approval decision, the approver's identity, and the eventual execution result (success, failure, or rollback triggered). This audit trail is essential for post-incident review and compliance. Tool integration: If your DNS provider supports a dry-run or preview mode, run it before generating the summary and include the dry-run output in [ZONE_CONTEXT]. This gives the model concrete data about what will change rather than relying solely on the change request.

What to avoid: Do not use this prompt for read-only DNS queries or monitoring checks—it is specifically for pre-mutation review. Do not skip the SOA serial increment verification; if the model flags it as unverified, the harness must require manual confirmation before proceeding. Do not allow the approval gate to be bypassed via API or automation unless the change is explicitly classified as low-risk (e.g., a comment-only TXT record update) and that classification is logged. Finally, ensure the harness enforces a maximum batch size—reviewing 200 record changes in a single summary reduces human review quality. If the change set exceeds a configurable threshold (e.g., 20 records), split it into multiple summary-and-approval cycles or escalate for a broader change management process.