MODULE v1.0.0

DNS

reads: resolution

Name resolution failures, including the works-by-IP-but-not-by-name pattern.

Built to the Open Module Standard

Healthy and broken

What healthy looks like
  • The name resolves to the expected address from both a local and a public resolver, and the two agree.
  • Response code is NOERROR with an answer in the record.
  • A and AAAA records both exist when the service serves IPv4 and IPv6.
  • Apex and www are consistent, with one canonical name.
  • For email: MX points at real mail hosts, exactly one SPF TXT record, DKIM keys publish at selector._domainkey, DMARC at _dmarc, sending IP has matching forward and reverse DNS.
  • TTLs are set to a sane value for how often records change.
What broken looks like
  • Answers by IP but not by name.
  • Local and public resolver disagree (stale cache or split view).
  • Response code is NXDOMAIN, SERVFAIL, REFUSED, or NOERROR with no answer.
  • A changed record still shows the old value because the TTL has not expired.
  • Email lands in spam: SPF, DKIM, DMARC, or PTR missing or wrong.
  • An internal name behaves differently on the VPN than off it.

What it checks, in order

  1. Reproduce and capture the exact name and record type.
  2. Resolve the name and read the response code first.
  3. Compare the local resolver against a public resolver.
  4. If answers differ by location, trace delegation from the root.
  5. Check the local hosts file and search domains.
  6. For email, walk MX, then SPF, then DKIM, then DMARC, then PTR.
  7. If a record changed recently, confirm the TTL and account for caching at each hop.

Common causes and how to spot them

  • Cause: Typo, missing record, or expired domain.
    Spot it: NXDOMAIN from an authoritative server.
  • Cause: DNSSEC failure, unreachable authoritative server, lame delegation, or timeout.
    Spot it: SERVFAIL. If it resolves with DNSSEC checking off, DNSSEC is the cause.
  • Cause: Wrong record type for the name.
    Spot it: NOERROR with an empty answer (NODATA).
  • Cause: Stale cache after a change.
    Spot it: Local resolver returns the old value while a public resolver or the authoritative server returns the new one.
  • Cause: Split-horizon drift.
    Spot it: Internal and external views return different addresses and only one is correct for the current connection.
  • Cause: Email auth gaps.
    Spot it: Zero or multiple SPF records, a missing DKIM key, no DMARC, or a sending IP with no PTR record.

An example investigation

Symptom: Payroll application at payroll.acme-anvil.example unreachable after a record change.

Failing layer: Resolution.

Finding: The internal resolver at 10.0.0.10 holds a stale cached A record pointing to the old address 10.20.4.9. The public resolver at 8.8.8.8 and the authoritative server ns1.acme-anvil.example both return the new address 10.20.7.41. The internal and external views disagree because the internal cache did not refresh after the record changed.

Proposed solution for a person to perform: Flush or expire the internal resolver cache for payroll.acme-anvil.example, or wait out the remaining TTL, then re-test from the internal network.

Confidence: High. Not verified: why the internal cache did not refresh on its own.

pathwise · dns module · resolution layer 
pathwise > investigate "payroll app unreachable after DNS change"

module        dns v1.0.0  ·  layer: resolution
evidence      reading dns/exports/lookups.json (file-drop door)

lookup 1      name payroll.acme-anvil.example  ·  type A
              resolver 10.0.0.10 (internal)
              answer    10.20.4.9  NOERROR  ttl 3600  (cached)

lookup 2      name payroll.acme-anvil.example  ·  type A
              resolver 8.8.8.8 (public)
              answer    10.20.7.41  NOERROR  ttl 300

lookup 3      name payroll.acme-anvil.example  ·  type A
              resolver ns1.acme-anvil.example (authoritative)
              answer    10.20.7.41  NOERROR  ttl 300  (authoritative)

analysis
  public and authoritative agree: new address is 10.20.7.41
  internal resolver disagrees:    old address 10.20.4.9 still cached (ttl 3600)
  pattern: stale internal cache after a record change

finding       the internal resolver holds a stale cached record.
              public and authoritative answers agree on the new address.
              the internal view disagrees. this is a cache problem, not a DNS config problem.
layer         resolution  (confidence: high)
not verified  why the internal cache did not refresh on schedule

proposed solution (for a person to perform):
  flush or expire the internal resolver cache for payroll.acme-anvil.example,
  or wait out the ttl (up to 3600s), then re-test from the internal network.

⚠ PathWise never makes the change. This step is yours.
Failing layer: Resolution (stale cache) Confidence: High

What this module contains

dns/
  module.yml        manifest: name, vendor, version, layer, covers, author
  knowledge.md      plain-language how-to troubleshoot DNS
  connection.yml    file-drop door (this module declares no live door)
  evidence.yml      field labels, for a later feature (not read yet)
  examples/
    sample-ticket.md
    exports/
      lookups.json  sample data the module reads
  README.md

This module reads files you export and drop in the module folder. It never writes back. The engine also ships an API door and an MCP door, described in the Open Module Standard, and the DNS module does not declare either one. Its live evidence comes from the engine's own resolver probes instead.

Stop guessing which layer broke.

Get PathWiseFrom $399 a year.Read the docs ›
Who is it for?

Anyone with the right permissions stands it up. After that, anyone working an access ticket, help desk, IT ops, or developers, gets the same evidence-backed answer.

What exactly do I get?

The engine skeleton as a Docker image, all nine modules, the command-line tool, and the browser interface. You supply your own model backend.

Does it change anything in my network?

No. It diagnoses and advises. It runs checks, including its own live network probes, and proposes a fix you perform. It makes no changes.

It is built with AI. Why should I trust it?

PathWise is built by an engineer with more than 30 years in systems infrastructure, 18 of them securing networks in regulated banking, holding the CISSP and CCSP. It solves a problem its builder has lived for two decades. You still do not have to take it on faith. PathWise cannot change your systems. The read-only boundary lives in the code, not in a request to the model, so the worst case is a wrong answer you catch, never a wrong action. Every answer shows the probes it ran and the evidence behind each claim, so you check the conclusion instead of trusting it. It ships with more than 1,600 automated tests, and an outside security review of the live app in July 2026 found no critical or high issues. And it is free to trial on your own box until the beta license expires in one year. Point it at a problem you already understand and watch what it does before you pay.

What model does it run on?

You bring your own. It runs against the Anthropic API by default, or any OpenAI-compatible backend, including a local model through Ollama or vLLM. A managed in-tenant placement is planned. The model is a quality dial you set.

Is my data sent anywhere?

Your model does the reasoning, so in the Anthropic mode your investigation data goes to your AI provider over your own key. Run a local model to keep the reasoning inside your boundary. A managed in-tenant cloud placement is planned. Probes send only the host or IP being checked.

What is a module?

A small folder of plain files describing one vendor or one layer. The standard is free and open, and you can write your own.

How is it licensed?

An annual subscription license. Solo covers one engineer. Team is licensed to one organization and covers four user accounts, with more sold in 3-packs. Modify it for internal use, no resale, as-is, copyright retained.