DNS Resolution & Reverse DNS Explained
DNS resolution is the lookup that turns a domain name into the IP address a browser or mail server actually connects to. Reverse DNS is the lookup that runs the other direction — given an IP address, what hostname does it belong to. Both are simple in principle, and both fail in specific, recognizable ways that show up as three of Nivaronix's DNS findings.
Last updated August 11, 2026.
Forward resolution: name to address
When anything — a browser, a mail server, a scanner like Nivaronix — needs to reach your domain, it first asks DNS to resolve the hostname to an IP address. An A record maps a hostname to an IPv4 address; an AAAA record does the same for IPv6. This lookup has to succeed before any actual connection (HTTP, SMTP, or anything else) can be attempted.
When this lookup fails outright — no A/AAAA record answers, the domain isn't registered, or the nameservers themselves don't respond — the domain is effectively unreachable for anyone hitting the same failure. Nivaronix reports this as DNS Resolution Failed.
When resolution succeeds but points nowhere real
A resolution can also succeed and still be wrong. Two IPv4 ranges are reserved and can never be a real destination for a public domain: 127.0.0.0/8, the loopback range that always means "this same machine," and 0.0.0.0/8, a reserved range no host can legitimately use. A domain whose A record resolves into either range has a DNS misconfiguration, not a working (if unusual) setup.
In practice, this pattern almost always traces back to a leftover placeholder — a template DNS record that was never replaced with the real server IP, a local development value accidentally pushed to production DNS, or an infrastructure script that failed partway through and wrote a default value instead of the intended one. Nivaronix reports this as Invalid IP Address.
Reverse DNS: address to name, and why mail cares
Reverse DNS runs the lookup in the other direction: given an IP address, a PTR record answers with a hostname. Unlike A/AAAA records, which live in your own domain's DNS zone, a PTR record is set by whoever controls the IP address block — typically your hosting or cloud provider, not your DNS host.
Reverse DNS matters almost entirely for outbound email. Many receiving mail servers check that the IP a message arrives from has a PTR record, and often that the PTR hostname resolves forward back to the same IP (forward-confirmed reverse DNS). A server with no PTR record looks more like an unmanaged or compromised machine to spam filters, independent of whether SPF and DMARC are configured correctly. Nivaronix reports a missing PTR record as No Reverse DNS — deliverability hygiene, not a vulnerability.
How this connects to DNSSEC
Resolution failure can also be a symptom of a broken DNSSEC chain rather than a plain misconfiguration. If a domain publishes a DS record (DNSSEC enabled) and also fails to resolve in the same scan, that specific combination points at a stale or mismatched DS record — see Domain Is Signed With DNSSEC But Did Not Resolve and the DNSSEC guide for how that chain works.
Checking your own setup
- Confirm your domain is registered and its nameservers point to the DNS provider you actually manage.
- Confirm the A (and AAAA, if used) record resolves to your real server's public IP — not a loopback or reserved-range placeholder.
- If this server sends email, ask your hosting/cloud provider to set a PTR record for its IP, and add a matching forward record for the PTR hostname.