test report
Eight reproducible IP and DNS lookup checks
A dated check of address normalization, input rejection, DNS responses and RDAP behavior. This is a functional test, not a geolocation accuracy score.
Scope and test conditions
We ran eight predetermined requests against the IPTestor production HTTPS service on 10 September 2026 at 20:05 UTC (11 September in Hong Kong). The release under test was f82697d and its DB-IP Lite database version was September 2026. We used public service addresses, a private address and deliberately invalid inputs; no visitor query history was used.
The origin server made the requests using curl with the hostname pinned to the serving address and normal TLS verification. This avoids the test host’s intermittent DNS resolution problem, so these results do not establish public DNS availability, global uptime or mobile performance.
Observed results
8.8.8.8 returned HTTP 200, IPv4 and ASN 15169. 2001:4860:4860::8888 returned HTTP 200, IPv6 and ASN 15169. ::ffff:8.8.8.8 was normalized to 8.8.8.8 and reported as IPv4.
192.168.1.1 returned HTTP 400 as a private/local input. not-an-ip returned HTTP 400 as an invalid address. These are expected rejections, not service outages.
example.com with record type CNAME returned HTTP 200 and status OK with no answers. iptestor-test.invalid with type A returned HTTP 200 and status Domain does not exist. The HTTP request succeeded in both cases; the DNS meanings differ.
The Whois request for 8.8.8.8 returned RDAP from rdap.arin.net with handle NET-8-8-8-0-2 and name GOGL. Registration fields and live DNS answers may change after this report.
Why these results are not an accuracy percentage
All eight observations matched the intended behavior for these selected cases. The sample is small and deliberately chosen; it is not random and cannot establish a population-wide success rate.
The IPv4 and IPv6 resolver addresses produced different database city labels: Mountain View and Montreal. That is an observation about the database, not proof of the physical location of a server or user. We did not measure geographic ground truth or test residential/VPN classification.
Repeat the checks
Use the IP lookup for each address, the DNS page for each domain/type pair, and the Whois page for the registration check. Record the returned fields and UTC time. The downloadable JSON includes the exact API paths and selected response fields.
Compare address versions and error handling directly. For live DNS or registry differences, investigate the current upstream data before calling a change a regression. Report reproducible problems with the input, expected behavior and observed response.