OneLinersCommand workbench
AI
Back to prompts
plain-prompt

Triage a DNS resolution outage

Compare client resolver, authoritative answers, delegation, and transport evidence.

Revision
1
Verified
2026-07-26
Save or explore
Save to collectionCreate a collection in the sidebar first.

Compatibility and paths

GenericWorks with instruction-following chat models.
ChatGPT
Claude Code
Gemini CLI

Trust and provenance

Curated record reviewed 2026-07-26. Results still depend on the supplied context and target environment.

Fill variables

Values stay in this browser tab and are not stored.

Generated asset2 required field(s) must be completed
Objective: Identify the failing DNS layer and the next discriminating query.

Context: Treat cached and authoritative answers as different evidence.

Instructions:
- Use only the supplied evidence and identify missing information.
- Lead with the finding, confidence, and one safe next action.
- Put read-only checks before mutations and include a stop condition.
- Never request or reproduce secrets, credentials, or private keys.

User request:
Client and domain:
{{environment}}

Queries and output:
{{evidence}}

Produce a layered DNS diagnosis.

Required output:
- Finding
- Evidence
- Confidence
- Safe next check
- Stop condition

Real example

Input

resolvectl query api.example.net: timeout; dig @1.1.1.1 returns A 203.0.113.8

Expected result

Public resolution works, while the configured local resolver times out. Next: inspect `resolvectl status` and query the listed resolver directly before changing DNS configuration.

Source evidence

systemd-resolved manualofficial