What IP Lookups Say About Public DNS Resolvers: 8.8.8.8, 1.1.1.1, 9.9.9.9 and More

Why look up resolvers at all

Public DNS resolvers are the most familiar IP addresses on the internet. Their operators are publicly known, their purpose is documented, and nobody seriously suspects 8.8.8.8 of fraud. That makes them an ideal control group: if an IP lookup reports something surprising about an address whose identity we already know, the surprise tells us about the data source, not about the address.

On 9 October 2026 we looked up six resolvers with the same checks TrustIP runs for every result page: ip-api for network owner, location and its proxy, hosting and mobile classification; a PTR lookup for reverse DNS; the Tor Project bulk exit list; and five public DNS blocklists (SpamCop, PSBL, Mailspike, UCEPROTECT Level 1 and DroneBL). The raw observations are below, followed by what they do and do not mean.

The observations

• 8.8.8.8 — AS15169 Google LLC; ip-api location Ashburn, United States; proxy: true, hosting: true; PTR dns.google; not a Tor exit; not listed on any of the five blocklists.
• 1.1.1.1 — AS13335 Cloudflare; ip-api location South Brisbane, Australia; proxy: false, hosting: true; PTR one.one.one.one; not a Tor exit; not listed.
• 9.9.9.9 — AS19281 Quad9; ip-api location Berkeley, United States; proxy: false, hosting: true; PTR dns9.quad9.net; not a Tor exit; not listed.
• 208.67.222.222 — AS36692 Cisco OpenDNS; ip-api location San Jose, United States; proxy: false, hosting: true; four PTR names including resolver1.opendns.com and dns.umbrella.com; not a Tor exit; not listed.
• 223.5.5.5 — AS37963 (Alibaba); ip-api location Hangzhou, China; proxy: false, hosting: true; PTR public1.alidns.com; not a Tor exit; not listed.
• 114.114.114.114 — AS137702; ip-api location Jinan, China; proxy: true, hosting: true; PTR public1.114dns.com; not a Tor exit; not listed.

Lesson 1: two of six “proxies” are not proxies

ip-api flagged 8.8.8.8 and 114.114.114.114 as proxies and left the other four unflagged. A recursive resolver answers DNS questions; it does not relay your web traffic, so none of the six is a proxy in the sense that matters to a website deciding whether to trust a visitor. The flag is a property of how ip-api classifies certain ranges, and its documentation describes the field broadly as covering proxy, VPN or Tor exit addresses.

The practical rule: a proxy flag from one provider is a prompt to look closer, not a finding. If your own address is flagged, check whether a second, independent source agrees, whether the network owner and PTR are consistent with your provider, and whether the flag matches the symptom you are actually seeing. A flag that two sources disagree on should never be the sole reason to block, refund, or accuse someone.

Lesson 2: the city is a registration artifact

All six resolvers are anycast: the same address is announced from many locations, and your query is answered by whichever site your network routes to. Yet each lookup returned exactly one city. 1.1.1.1 resolved to South Brisbane, Australia, which is where APNIC—the registry that holds the 1.1.1.0/24 block and lends it to Cloudflare—has its headquarters. 114.114.114.114 resolved to Jinan, although the service is commonly associated with Nanjing.

Neither city is wrong in the database’s own terms; each reflects registration or a past mapping decision. Both are wrong if you read them as “where my request went”. This is the same mechanism that makes some ordinary users appear in the wrong city: the database records a place for a block of addresses, and reality is more distributed than a single row.

Lesson 3: clean blocklists and Tor checks are narrow, useful facts

None of the six appeared on the Tor exit list or on any of the five blocklists. That is a precise statement: at query time, these lists did not contain these addresses. It does not mean the addresses are “safe” in some general sense, and an empty result from a list that failed to answer must never be read as clean—which is why TrustIP withholds results from any blocklist whose test entry does not resolve correctly.

Reverse DNS was the most informative single field. Every resolver had a PTR name under its operator’s own domain, which is what you expect from well-run infrastructure and the opposite of the generic “1-2-3-4.dynamic.example.net” pattern that mail filters treat with suspicion.

How to reproduce this yourself

• Look up each address on TrustIP; the result page lists every check with its source.
• Run dig -x 8.8.8.8 +short to see the PTR record from your own resolver.
• Download https://check.torproject.org/torbulkexitlist and search it for the address.
• Query a blocklist directly by reversing the octets and appending the zone: for 9.9.9.9 that is dig +short 9.9.9.9.bl.spamcop.net, and for 223.5.5.5 it is dig +short 5.5.5.223.bl.spamcop.net. No answer means not listed—provided the list’s test entry (dig +short 2.0.0.127.bl.spamcop.net) does return an answer from your resolver.
• Repeat on another day: provider classifications and lists change, so date every observation.

References and source material

These sources are provided so readers can verify the technical background. Inclusion does not imply endorsement of TrustIP.

• ip-api JSON fields (proxy, hosting, mobile)
• Tor Project bulk exit list
• RFC 5782 — DNS blacklists and whitelists
• APNIC Labs and Cloudflare: 1.1.1.1