PathMRI

Overview/Features/DNS

DNS from the source host

A green result on
an address nobody uses.

The most common real cause of "the app cannot reach the database" is the name — resolving to the wrong place, to nothing, or to different places for different clients. An IP-based check cannot see it. So PathMRI resolves the name where the application would: on the source host.

Download Read the manual

Asked from the right place

The controller's answer can differ from the source host's, and it is the source host's that the application will use.

Which resolver replied

The A and AAAA answers, and the resolver that gave them — so an override on one host stops looking like a network fault.

Whether it even was DNS

An answer from the hosts file is called out. It overrides DNS entirely, and no zone change will ever affect it — which is why this is the one that wastes a whole afternoon.

What other hosts see

The same name resolved from other source hosts. That is the evidence a split-horizon finding rests on, and it cannot be produced from one machine.

Shown whenever a resolution happened, not only when something is wrong. "We asked the source host and its answer matches what we tested" is evidence. Hiding it would leave you unable to tell that from "DNS was never checked".

Next

Path verification What was actually tested, and against which address. Kubernetes & Docker Cluster DNS gets the same treatment, asked from inside the pod. Application-aware checks Where the name and the ports come from in the first place.