MyIP.dogChecking…
IP data sources and limitations
The providers and standards behind public address observations, DNS results, registration records and local calculations.
Last updated: 2026-09-28
The providers and standards behind public address observations, DNS results, registration records and local calculations.
Last updated: 2026-09-28
Checking…
IP data sources are not interchangeable. A request observation tells us which address reached an endpoint. A regional registry describes network registration. A DNS resolver answers a naming question. A geolocation database estimates a location using its own methods. This page identifies the IP data sources used by the current tools and explains why a field from one category should not silently be treated as evidence from another.
The practical rule is to keep the source close to the result. A current address should show where it was observed. A DNS response should name its resolver. A registration result should link to the registry record. IP data sources can have different update schedules, access conditions, coverage, and failure modes. Naming them helps a reader decide whether the result is suitable for a support request or operational decision.
The homepage can obtain the visitor's source address from trusted request context in a supported deployment. Cloudflare's request metadata can also contain approximate country, region, city, timezone, and network organization information. These IP data sources belong to the request being handled. Their availability depends on the deployment and request, so missing metadata is not replaced with guessed values from the application's own server location.
Cloudflare documents its relevant headers in the HTTP headers reference and request properties in the Workers request documentation. IP data sources carried in headers still require a trust boundary. An arbitrary visitor can send a header with a familiar name to an ordinary server, so the application must establish that trusted infrastructure supplied it before treating it as evidence.
The address observation and location metadata have different meanings. The connection source can be directly observed at an endpoint, while a city field remains a location estimate. IP data sources should not be given one blanket accuracy label when they describe different facts. A VPN exit, mobile gateway, or business network can also make the observed network location differ from the device's physical position.
The homepage map uses approximate latitude and longitude from the same trusted Cloudflare request as the displayed address. These IP data sources are never replaced by GPS coordinates or the backend server's location. Invalid, incomplete or untrusted coordinates produce a clearly labeled world overview without a visitor pin. The browser renders the map with MapLibre and loads geographic tiles, fonts and icons from OpenFreeMap. A locally versioned Liberty-derived style follows our light and dark themes. OpenMapTiles and OpenStreetMap attribution remains visible; style credits and licenses describe the adaptation. OpenFreeMap currently permits free commercial use without an account or key, but does not guarantee perpetual availability. Its data remains OpenStreetMap-derived. The browser sends its network address and requested map area to the map provider. The provider's privacy policy explains normal logging and temporary security logs. Coordinates outside the map projection's supported latitude range use an unpinned overview. These IP data sources and map imagery serve different purposes: tiles draw geography; they do not verify the location estimate. A failed map does not remove the IP result.
The browser fallback uses ipify's documented public address API. The IPv4 test uses api.ipify.org, the IPv6 test uses api6.ipify.org, and a general fallback can use api64.ipify.org. These IP data sources observe the source address of requests sent from the browser. The site labels that provider rather than presenting the result as a direct observation by its own server.
A request to an external address endpoint necessarily discloses a source address to that endpoint. Browser requests omit credentials and do not send the site's page URL as a referrer. The provider's own policies still govern its operation. IP data sources can also be blocked or temporarily unavailable. A failed endpoint request is reported as a failed check, not as a made-up address or a guarantee that a particular protocol is disabled.
The WebRTC leak test uses browser-reported ICE candidates and Cloudflare's public STUN endpoint, stun.cloudflare.com:3478. These IP data sources are contacted only when the visitor starts this test. Cloudflare observes the source of the STUN traffic; separate ipify requests provide HTTP references for each address family.
Candidate reports stay in the current tab unless copied. IP data sources can expose public, private or mDNS candidate values under the browser's policy, so a copied report should be reviewed before sharing. No camera permission, microphone permission or remote peer is used. These IP data sources do not establish the route of every application, and incomplete gathering is not interpreted as a privacy success.
The IP comparison uses direct browser requests to the site's public address endpoint, ipify, and Cloudflare's trace endpoint. These IP data sources receive separate requests to the URLs displayed in the tool. Cloudflare trace contributes its reported address field; unrelated fields are discarded. Additional regional nodes, when configured, must provide direct observations and carry an operator-declared destination label. The default IP data sources do not establish a mainland China versus fixed overseas comparison or the address seen by Google. Same-version results are compared, with missing responses and partial coverage kept visible.
The ping test and online traceroute use Globalping probes. These IP data sources observe remote paths to a submitted public target. We show the actual probe location and network, selected protocol, timestamp, and public source response. A hostname is resolved through Google Public DNS before one validated public address is sent to the probe. These IP data sources do not measure the visitor's own route or application response time. Targets and results are public at the provider and may remain available for up to six months. Stopping collection or clearing our display does not cancel or delete an upstream measurement. Missing replies and provider failures remain distinguishable from a proven target outage.
The HTTP headers check uses the same public Globalping IP data sources for bounded HEAD requests and redirects. Each destination is validated and pinned separately; the original hostname supplies Host and SNI. Actual response fields, truncation and probe TLS authorization remain separate evidence. These IP data sources may return headers from an unverified TLS connection; we display that condition and stop the chain.
The port checker uses the site server's own TCP socket outcome. These IP data sources distinguish connection establishment, refusal, timeout, unreachable conditions and runtime restrictions. One public target is tested per submission, using a single port or a fixed preset of four or six ports without application data. Hostnames use Google Public DNS before the selected address is pinned. The optional browser-address control uses ipify only to fill the target. These IP data sources do not identify the application's health, the probe's geographical location, or UDP behavior. No public Globalping measurement is created by this tool. The destination may log the connection, and other IP data sources or network observers may retain their own records even after the local result is cleared.
DNS and reverse DNS tools use the Google Public DNS JSON-over-HTTPS interface. Queries go through the site server with the selected name and record type. The response can include answer records, authority records, TTLs, response codes, and DNSSEC-related flags. These IP data sources describe the remote resolver's view, not the cache or DNS configuration of every visitor's device.
The tool requests an empty EDNS client subnet to avoid forwarding a client network prefix for geographic answer selection. That setting does not make the query invisible to the resolver: the requested name is still required to answer it. IP data sources should be chosen with the sensitivity of the input in mind. Avoid submitting private internal names unless you understand the disclosure and the limitations of a public resolver.
A PTR result can name an address without listing all hosted websites. An A or AAAA result can identify a published destination without proving that its application is healthy. IP data sources from DNS should be interpreted using the record type and response code. NOERROR, NXDOMAIN, and SERVFAIL represent different outcomes, and an absent authenticated-data flag is not a general declaration that a site is unsafe.
Registration lookups use IANA's IPv4 RDAP bootstrap directory and IPv6 RDAP bootstrap directory to find the responsible service. The supported regional registry hosts belong to ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. These IP data sources are used for internet number registration, and the returned source URL is visible with the result.
The tool displays selected network fields rather than every nested contact object. Depending on the record, available fields may include a name, handle, range, type, and registration country. IP data sources in registries describe allocations and assignments under their policies. They do not necessarily identify the retail provider's brand, the current individual user, or the physical location of an endpoint. Shared addresses and intermediary providers make those limits especially important.
Registry services can return errors, referrals, or incomplete information. The implementation follows only supported secure registry destinations and limits response size and request duration. IP data sources outside that supported path are not silently fetched through arbitrary URLs. If a referral cannot be followed, the interface reports the limitation. A failed query is not evidence that a public address has no legitimate allocation.
The domain WHOIS lookup uses the separate IANA domain RDAP directory. These registration services complement IP data sources but describe domain objects, not address allocations. One exact name is sent to the selected HTTPS registry endpoint from our server. The summary includes returned registrar entities, events, statuses, nameservers, DNSSEC declarations and privacy notices. Registrar referral links are shown without automatically requesting them. Unsupported suffixes, access restrictions, rate limits and RDAP 404 responses stay distinct. Missing domain records do not establish availability. As with other IP data sources, the provider URL and retrieval time remain visible.
The ASN lookup uses RIPEstat's Network Info and AS Overview endpoints. An IP query returns a matching prefix and observed origin numbers; an ASN query returns a holder description and origin visibility under the source's threshold. These IP data sources are collected routing and registry evidence. They do not directly test packet delivery or identify the subscriber who used an address.
Network Info uses eight-hour data dumps, while overview responses can include a source query window. These IP data sources are therefore labeled separately from the time this site receives a response. Every returned origin is preserved. Special-use ASN ranges are classified without a RIPEstat query, and a negative origin status is not described as an outage because transit-only networks can also have that status.
The subnet calculator does not need a live provider response. It applies address arithmetic locally in the browser using the supplied address and prefix. Its supporting IP data sources are standards and address definitions rather than a remote database of active devices. RFC 4632 describes CIDR, RFC 3021 covers IPv4 point-to-point /31 use, and RFC 6164 discusses IPv6 inter-router /127 prefixes.
Address handling also relies on published special-use definitions and normalized text conventions. RFC 1918 defines private IPv4 space, RFC 6598 defines shared address space, and RFC 5952 specifies a recommended IPv6 representation. These IP data sources help interpret the input, but they do not reveal who occupies a private address in a particular local network.
The site does not currently substitute a registry country for an arbitrary address's city-level geolocation. It does not manufacture a VPN label, abuse reputation score, or exact location from a network name. Additional IP data sources would need appropriate access rights, definitions, update behavior, and visible limitations before those fields could be supported. A blank field is more honest than an unsupported inference presented as a measurement.
Original research also requires reproducible observations. Provider disagreement studies, browser privacy matrices, and performance comparisons cannot be created merely by combining plausible text with source links. IP data sources must actually support the measurements claimed. The site should distinguish a methodology for a future study from results that have already been collected, and disclose the sample and environment when presenting original findings.
When IP data sources disagree, compare equivalent fields for the same address and time. A registered country, a geolocation estimate, a DNS hostname, and the user's physical location are four different concepts. Record the provider and update or observation time where available. If the disagreement affects a service, ask which provider and field that service actually uses before requesting a correction from an unrelated source.
For a reproducible report, include the tool, query, response code, relevant values, source URL, and observation time. Keep unnecessary personal information out of public reports. IP data sources are useful when their scope is understood and their limitations remain visible. The methodology explains how these sources are turned into individual checks, and each tool guide describes the most common mistakes when interpreting its results.
The speed tool contacts Cloudflare’s public /__down and /__up endpoints directly from the browser after an explicit start. These IP data sources provide test payload responses, while browser Resource Timing supplies the network timestamps. The endpoint receives the visitor’s public address and request information. Our generated upload data contains no selected personal files, and the tool does not send a separate report to a results-logging service.
These IP data sources support one browser-to-provider path. They do not establish universal internet capacity, ICMP latency, UDP packet loss or precise server geography. MyIP.dog uses its own bounded measurement transport rather than the provider’s SDK. See the published endpoint configuration and provider information. Additional IP data sources would require their own verified method and operating terms; this integration does not imply an unlimited service commitment from Cloudflare.
The mail-list IP data sources are SpamCop and PSBL, queried through Google Public DNS with per-run source controls. These IP data sources supply narrow mail-list evidence, not subscriber identities or universal safety ratings. The blacklist check names both integrations, preserves failures and does not query IPv6. DNS cache lifetimes do not establish listing age.
For hostname lookup, Google Public DNS supplies three separate DNS observations. These IP data sources are queried with checking enabled and empty EDNS client subnet; the browser does not independently validate signatures. CDN hints compare observed alias targets with documented CloudFront, Fastly and Akamai suffixes. Such IP data sources do not provide a complete CDN inventory or an origin-server identity.
The CIDR calculator also works locally, covering inclusive ranges, aggregating networks and splitting prefixes. It needs no live IP data sources. It preserves the mathematical family of mapped IPv6 inputs and displays exact totals; paginated splits do not enumerate every address. External IP data sources cannot turn those calculations into evidence of allocation or permission.
The email header analyzer uses pasted header text as its only evidence. These local IP data sources are unverified user-supplied records. Parsing runs in the tab without DNS, registry or location requests; authentication assertions are not independently checked. Such IP data sources cannot establish a sender's identity or physical location.
The password generator and PIN generator use browser Web Crypto as their random source. They need no external IP data sources, account identifiers or existing passwords. Rejection sampling avoids character-selection bias; generated strings remain local until explicitly copied. IP data sources cannot certify the receiving account's protections or register these candidate strings as credentials.