Required record missing
The selected DNS record type returns no usable value.
MissingRecords, resolvers, ports
DNS monitoring for failures hidden behind a healthy app.
PageLantern verifies the records customers resolve and the public ports services accept, separating routing drift and network reachability from application health.
Expected value changed
The public answer no longer matches the value stored on the monitor.
DriftTCP connection refused
The target host does not accept a connection on the configured port.
UnreachableDNS and network evidence
Separate name resolution from port reachability.
DNS checks validate the public record contract. TCP checks test whether a service is listening. Keeping those signals distinct makes the broken layer easier to identify.
DNS record checks
Compare the public answer with what should exist.
- A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, and SRV
- Optional expected-value matching
- Record values, TTL, and resolver evidence
TCP port checks
Test the public network boundary directly.
- Any valid TCP port from 1 to 65,535
- Configurable host, port, and timeout
- Connection result and incident history
Location model: DNS and TCP checks run hub-local. Customer-selected multi-location schedules apply to HTTP website monitoring, not DNS or TCP monitors.
Example result
The record moved. The service did not.
Illustrative values keep the expected DNS answer, observed answer, and TCP reachability in one diagnosis.
- Target
- api.example.com
- Record type
- A
- Expected
- 203.0.113.10
- Observed
- 203.0.113.24
- TCP 443
- Reachable
- Outcome
- DNS drift
Next step
Verify the route before traffic depends on it.
FAQ
Frequently asked questions
Can PageLantern detect DNS record changes?
Yes. You store the DNS values that should exist and PageLantern checks whether public resolution still matches, alerting when required records disappear or drift after zone edits or provider changes.
Which DNS record types are supported?
DNS monitoring supports A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, and SRV records, covering website routing, mail delivery, verification, aliases, authority data, and service discovery.
Can I also check TCP ports?
Yes. Optional TCP checks verify public reachability for ports such as 443, 22, 25, or 3306, which helps separate routing failures from application health.