DNS Lookup Guide: Compare Public, System, VPN, and Reverse DNS

A hostname can resolve correctly in a browser, fail inside a container, and return a third answer on a VPN. That does not automatically mean DNS is random. It usually means the clients are asking different resolvers or reaching different views of the same zone.

Start by naming the vantage point: a public DNS lookup answers “what does an internet resolver see?” A system DNS lookup answers “what does this device—or the local bridge environment—see?” Comparing the two turns a vague resolution problem into evidence.

Public DNS versus system and VPN DNS

Public DNS resolvers can inspect records published on the internet. They cannot see a private corporate zone unless that zone is deliberately reachable and delegated. Your operating system resolver may use a router, a VPN-provided nameserver, a cloud private zone, a search suffix, or a local hosts file.

The Bug Days DNS lookup and reverse DNS checker queries public DNS in the browser. For the device or VPN view, Holy CORS runs locally and uses its environment’s configured resolver. A native Holy CORS binary follows the host configuration; a Docker container follows Docker’s DNS configuration.

Choose the record type that answers your question

• A and AAAA: IPv4 and IPv6 addresses for a hostname.
• CNAME: an alias that points at another DNS name.
• MX: mail exchangers, including their priorities.
• TXT: SPF, domain verification, and other text policies. Long TXT values may be split into several quoted segments on the wire.
• NS and SOA: zone delegation and administrative metadata.
• SRV: host and port discovery for a named service.
• CAA: which certificate authorities may issue for a domain.
• PTR: a reverse mapping from an IP address to a hostname.

Run an IPv4 or IPv6 reverse DNS lookup

Reverse DNS stores PTR records under a special name. IPv4 uses reversed octets beneath in-addr.arpa; IPv6 uses reversed hexadecimal nibbles beneath ip6.arpa. A checker can build that query for you when you enter an IP address.

# IPv4 PTR lookup
dig -x 8.8.8.8

# Ask a specific public resolver
dig @1.1.1.1 -x 8.8.8.8

No PTR record is common and should be reported as “not published,” not as proof that an address is broken. More than one PTR hostname is also legal, though many operational conventions prefer one stable canonical name.

Forward-confirm the PTR hostname

A PTR record says an address maps to a name. Forward-confirmed reverse DNS performs the second half: resolve that name’s A and AAAA records and check whether the original address appears. This is often called FCrDNS.

1. Query PTR for the IP address.
2. Collect the returned hostname or hostnames.
3. Resolve each hostname to A and AAAA.
4. Check whether the original normalized IP is in the forward result.

A match shows consistent forward and reverse configuration. It does not prove who controls the machine, whether traffic is benign, or whether the TLS certificate matches that name. Use the IP, ISP, ASN, and cloud lookup for network context and the TLS certificate checker for service identity.

Interpret NXDOMAIN, NOERROR with no data, and SERVFAIL

A practical split-DNS investigation

1. Record the exact hostname and whether the failing client is on the VPN.
2. Compare public DNS with the system or VPN resolver.
3. Compare record data and status—not only whether a command printed output.
4. Capture TTLs and resolver latency to separate stale cache from connectivity.
5. If an address is returned, test the service and its TLS identity independently.
6. Share or export the snapshot so another engineer can compare the same evidence.