Network lookup tools expose observations about an address, route, resolver, or DNS zone. They do not automatically identify a person, prove ownership, establish a server's physical location, or prove that an IP is malicious. A useful diagnosis records the vantage point, protocol, resolver, time, cache state, and authorization for every active check.
Key Takeaways
- An IP address identifies an interface or endpoint in a routing context, not necessarily a device or person. NAT, proxies, VPNs, CDNs, anycast, and shared hosting matter.
- Use CIDR and address scope rather than obsolete class A/B/C categories. IPv4 private space is defined by RFC 1918; IPv6 has global, link-local, unique-local, multicast, loopback, and documentation ranges.
- DNS answers depend on the queried resolver, cache, TTL, delegation, transport, and time. “Propagation” is not one global switch.
- A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, and CAA records have different owners and semantics. TXT is not one security protocol.
- GeoIP is an approximate database inference. It is unsuitable as a precise location, identity, fraud, or legal-compliance decision without additional evidence.
- Diagnose systems you own or are authorized to test. Passive lookup and active probing have different privacy, rate-limit, and legal implications.
IP Address Scope
An IP address is a numeric identifier assigned to an interface or used as a service endpoint. It is not a permanent identity. One public address can represent many clients through NAT, and one service can have many addresses through load balancing, CDNs, or anycast.
IPv4
IPv4 is 32 bits, conventionally written as four decimal octets. Modern networks are described with CIDR prefixes, for example 192.0.2.0/24, rather than classful defaults.
RFC 1918 private ranges are:
10.0.0.0/8172.16.0.0/12192.168.0.0/16
They are not globally routed, but “private” does not mean trusted. Loopback, link-local, multicast, carrier-grade NAT, documentation ranges, and reserved ranges have separate meanings and should be classified with a maintained IP library.
IPv6
IPv6 is 128 bits and uses hexadecimal hextets. :: may replace one consecutive run of zero hextets only once. Common scopes include:
| Scope | Example | Meaning |
|---|---|---|
| Global unicast | 2000::/3 |
Globally routable allocation space |
| Link-local | fe80::/10 |
Local link; interface scope matters |
| Unique local | fc00::/7 |
Private-style local addressing |
| Multicast | ff00::/8 |
One-to-many delivery |
| Loopback | ::1/128 |
Local host |
| Documentation | 2001:db8::/32 |
Examples, not production routing |
IPv6 does not make NAT, firewalling, authentication, or confidentiality unnecessary. IPsec support and deployment are separate from the address format.
IP Geolocation Is an Estimate
GeoIP databases combine allocation records, ISP information, routing observations, measurements, and sometimes opt-in signals. They estimate the network or egress location, not a user's GPS position. VPNs, mobile carriers, corporate gateways, cloud regions, proxies, CDNs, and stale allocations can move the estimate far from the endpoint.
Do not publish fixed city/region accuracy percentages without a dated provider, sample, geography, and methodology. Use GeoIP for coarse localization, language defaults, or an investigation lead; do not use it alone for identity, exact address, access denial, employment, immigration, or criminal attribution.
Treat IP addresses and lookup results as personal or sensitive data where applicable. Minimize retention, document the provider, respect terms and regional law, and avoid exposing query history.
DNS Roles and Resolution
DNS is a distributed naming system, not simply a database that “converts a domain to an IP.” A stub resolver sends a query to a recursive resolver. The recursive resolver may use cached data or query root, TLD, and authoritative servers, then return an answer with TTL and status.
The root system has 13 named root-server identities served by many instances; “13 servers” does not mean thirteen physical machines. The resolver's path, DNSSEC validation, transport, split-horizon policy, and cache determine what a client observes.
Useful diagnostic questions:
- Which name and record type were queried?
- Which resolver and network vantage point answered?
- Was the answer authoritative, cached, synthesized, or a negative response?
- What TTL, DNSSEC status, and response code were returned?
- Does the result differ over IPv4/IPv6, networks, or resolvers?
TTL limits caching time; it does not guarantee that every resolver refreshes at the same instant. Negative caching and delegation changes can persist according to their own TTLs.
DNS Record Semantics
| Record | Role | Important boundary |
|---|---|---|
| A | IPv4 address | Multiple answers do not necessarily mean round-robin quality |
| AAAA | IPv6 address | Client reachability and firewalling still matter |
| CNAME | Alias to another name | Cannot coexist with most data at the same owner name; apex behavior is provider-specific |
| MX | Mail exchangers with preference | The target must resolve; preference is not load percentage |
| TXT | Text strings for several protocols | SPF, DKIM, DMARC, and verification have separate names and syntax |
| NS | Delegation/name servers | Parent delegation and child NS data must be considered |
| SOA | Zone administrative parameters | Serial and negative-cache fields need zone context |
| PTR | Reverse mapping under in-addr.arpa/ip6.arpa | The address holder controls it; it is not forward identity proof |
| SRV | Service, priority, weight, port, target | Clients must implement the service contract |
| CAA | Certificate-authority issuance policy | It constrains compliant CAs; it is not a universal certificate revocation mechanism |
SPF is published as TXT at the domain and has evaluation limits. DKIM publishes a selector's public key under _domainkey; the message signature is elsewhere. DMARC is published under _dmarc and defines policy/reporting. Reading one TXT string is not an email-security audit.
DNSSEC can provide authenticated DNS data when the validation chain succeeds. A lookup result without DNSSEC validation does not prove that the answer is authentic, and DNSSEC does not encrypt queries or authorize an application user.
Safe Diagnostic Commands
Run active checks only against systems you own or have permission to test:
# Show resolver, status, answer, and TTL.
dig example.com A
dig example.com AAAA +dnssec
# Ask a specific resolver and compare vantage points.
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
# Inspect mail and delegation records.
dig example.com MX
dig example.com NS
dig _dmarc.example.com TXT
dig -x 192.0.2.1
# Trace delegation when authorized and useful.
dig +trace example.com
dig +trace generates multiple queries and may expose your test activity. Public resolvers have their own privacy, logging, rate-limit, and policy terms. Do not place credentials or private internal names in public DNS queries.
For connectivity, distinguish DNS failure from routing, transport, TLS, and application failure:
getent hosts example.com # local resolver path on many Unix systems
curl --fail-with-body -I https://example.com
traceroute example.com # or tracepath/mtr where authorized
ping can be blocked or deprioritized and is not proof that HTTPS works. A successful DNS answer is not proof that a port is open or a certificate is valid.
Security and Privacy Boundaries
Passive DNS and IP lookup can support an investigation, but “bad country,” ASN, reverse DNS, or a blacklist hit is not proof of malicious intent. Use multiple signals, timestamps, confidence, and an analyst review. Do not use geolocation to infer a person's identity.
Avoid SSRF when implementing lookup services:
- validate and canonicalize user input;
- resolve and classify addresses before connecting;
- block loopback, link-local, private, metadata, multicast, and reserved destinations unless explicitly required;
- re-check the destination after DNS resolution and redirects;
- enforce scheme, port, timeout, response-size, redirect, and egress policies;
- do not return internal response bodies or resolver details to untrusted clients.
DNS over HTTPS or TLS can protect a query from some local observers, but it shifts trust to the selected resolver and does not make the answer authoritative. DNSSEC authenticates DNS data, not the application session.
Practical Workflows
Website Incident
Record the failing URL, client network, time, resolver, response code, A/AAAA answers, TLS result, and HTTP status. Compare an authoritative query with the recursive answer, then test IPv4 and IPv6 separately. Avoid changing DNS before capturing evidence.
Email Delivery
Check MX target reachability, PTR and forward-confirmed reverse DNS, SPF evaluation, DKIM selector publication, DMARC alignment, TLS, provider logs, and message headers. Do not infer delivery from the existence of an MX record.
Domain Change
Lowering TTL does not instantly flush every cache. Record the old and new RRsets, serial/delegation changes, negative answers, resolver observations, and rollback plan. Test DNSSEC signatures and DS records when the zone is signed.
Security Investigation
Preserve source, query time, resolver, raw response, and confidence. Treat an IP as an indicator, not an attribution. Correlate with authentication logs, flow data, host evidence, certificate history, and authorized threat-intelligence sources.
Standard-Library IP Validation
Use a maintained parser rather than a large hand-written IPv6 regular expression:
import { isIP } from "node:net";
export function classifyAddress(value) {
const version = isIP(value);
if (version === 0) return { valid: false };
return { valid: true, version };
}
console.log(classifyAddress("2001:db8::1")); // { valid: true, version: 6 }
Syntax validation is not routing or authorization. If an application will connect to the address, apply a separate destination policy and resolve/re-check behavior.
Python DNS Query with Bounded Errors
When using a DNS library, pin the dependency, set timeouts, avoid leaking private names to public resolvers, and distinguish response conditions:
import dns.resolver
def lookup(name: str, record_type: str = "A"):
resolver = dns.resolver.Resolver()
resolver.timeout = 2.0
resolver.lifetime = 4.0
try:
answer = resolver.resolve(name, record_type, raise_on_no_answer=False)
return {
"status": "answer" if answer.rrset else "no_answer",
"ttl": answer.rrset.ttl if answer.rrset else None,
"values": [rdata.to_text() for rdata in answer],
}
except dns.resolver.NXDOMAIN:
return {"status": "nxdomain", "values": []}
except dns.resolver.NoNameservers:
return {"status": "no_nameservers", "values": []}
except dns.exception.DNSException as exc:
return {"status": "error", "error_type": type(exc).__name__}
Do not catch every exception and return raw error text to an untrusted caller. Do not hardcode a public resolver as if it were authoritative.
Frequently Asked Questions
Is an IP address a device's unique identity?
No. Addresses can be shared, reassigned, translated, proxied, anycast, or attached to virtual interfaces. Identity requires authenticated application or host evidence.
Does a DNS lookup prove domain ownership?
No. It observes an answer from a resolver. Ownership requires control-plane evidence, authenticated DNSSEC where applicable, or a protocol-specific verification challenge.
Does GeoIP show a person's exact location?
No. It estimates a network or egress location and can be wrong for VPNs, mobile, corporate, cloud, and CDN traffic. Do not use it alone for identity or high-impact decisions.
Does a low TTL make DNS changes instant?
No. Existing caches, negative caching, delegation, resolver behavior, and client caches can still delay observations.
Is DNSSEC encryption?
No. DNSSEC authenticates DNS data when validation succeeds. It does not hide queries or authorize application actions; use an appropriate encrypted transport and application authentication separately.
Can a public DNS resolver be used for internal names?
Avoid it unless the names are intentionally public and the privacy impact is accepted. Use an authorized internal resolver for internal zones and prevent leakage of sensitive names.
Primary Sources
- RFC 791: Internet Protocol
- RFC 8200: IPv6 Specification
- RFC 1918: Address Allocation for Private Internets
- RFC 1034 and RFC 1035: Domain Names
- RFC 4033: DNS Security Introduction
- RFC 7208: SPF
- RFC 6376: DKIM
- RFC 7489: DMARC
- OWASP: SSRF Prevention Cheat Sheet
Conclusion
Network tools are instruments for collecting bounded evidence. Identify the address scope, query the right DNS role, compare resolver and time context, separate wall-clock observations from ownership and attribution, and apply authorization and egress controls to active checks. A careful diagnostic record is more useful than a lookup result presented as certainty.