MyIP.dogChecking…
Hostname lookup
Resolve a hostname to IPv4, IPv6 and CNAME records. Inspect each DNS response and source-linked CDN hints.
Checking…
Resolve a hostname to IPv4, IPv6 and CNAME records. Inspect each DNS response and source-linked CDN hints.
Checking…
Checking…
Query A, AAAA and CNAME through Google Public DNS. We inspect returned records without connecting to the target addresses.
Starts only when submitted. Three DNS queries per run; six lookups per minute per connection, with shared service limits.
No lookup has run.
A hostname lookup translates a name into the records a DNS resolver returns. It helps you investigate where a website name points, whether both address families are published, and whether an alias connects the name to another hostname. Enter the exact name you want to inspect. The apex example.com and www.example.com can have different records and behave differently.
This hostname lookup sends three separate questions to Google Public DNS: one for A, one for AAAA, and one for CNAME. An A record contains an IPv4 address. An AAAA record contains an IPv6 address. A CNAME describes an alias to another name. The results remain separate because these questions are independent observations, rather than one atomic snapshot of a zone.
To start a hostname lookup, type a domain or hostname without a scheme, path, query string, or port. For example, enter www.example.com instead of a full page URL. The example button fills www.python.org without submitting it. Select Look up hostname when ready. No DNS query starts simply because you open this page or change the input.
The hostname lookup converts international names to the ASCII form used for these DNS queries. You can enter an internationalized name, then review its normalized form above the results. Conversion is not an endorsement of the name’s owner or spelling. Visually similar characters can still represent different names, so compare the actual intended domain carefully when investigating an unfamiliar link.
A hostname lookup here does not inspect your operating system’s hosts file, company resolver, local search suffix, or browser DNS cache. The named public resolver supplies the answers. Private service names, IP literals, and service-record labels with underscores are not accepted by this particular form. Use DNS lookup when you need the broader record-type interface.
The hostname lookup queries DNS through our service, which means the submitted name is disclosed to our server and to Google Public DNS. The resolver can contact the relevant authoritative servers. We request an empty EDNS client subnet, so this query does not deliberately attach part of your address for geographic selection. That does not hide the server’s connection from the resolver.
Each hostname lookup response has its own record type, observation time, response code, and DNSSEC AD flag. A result for A can succeed while AAAA fails, or vice versa. Preserve that distinction when sharing a report. An unavailable IPv6 query cannot establish that the domain has no IPv6 record, and an address record does not prove that your browser can connect to it.
When the hostname lookup finds addresses, it shows each validated address with a cache lifetime and address-range classification. Duplicate addresses within the same response are combined using the shortest returned lifetime. A private or documentation address is identified as such instead of presented as a normal public destination. The service does not connect to any of these addresses.
An IPv4-mapped value in an AAAA response remains an IPv6-form record in the hostname lookup, with an explicit mapped-address label. It is not silently substituted for a successful IPv4 question. That distinction matters because DNS data, address notation, and actual network connectivity answer different questions. A published record alone cannot demonstrate working IPv6 service.
Expand Returned CNAME path in the hostname lookup to see the ordered aliases that were actually present in that response. The sequence begins at your requested name. Unrelated records elsewhere in the answer cannot contribute addresses or provider hints to that path. The final name examined is shown even when the response does not establish a usable terminal address.
The hostname lookup inspects at most sixteen returned alias hops per response. It rejects cycles, conflicting targets for one alias owner, and a name that simultaneously supplies conflicting alias and address data. The resolver handles DNS recursion; this application does not invent extra hops or claim to have inspected names that were never present in the returned evidence.
A Records returned hostname lookup result means the requested type was established on the returned path. For a CNAME question, a valid alias itself is the requested answer. For A or AAAA, the tool looks for matching address records at the terminal name. This describes the DNS response, not a guarantee of HTTP service, TLS validity, or application availability.
A No record of this type hostname lookup result requires a successful DNS response and suitable negative authority evidence, without the requested record. The name may still publish other types. For example, a name with IPv4 service might have no AAAA record. Do not equate the absence of one type with a nonexistent domain or an expired registration.
A Name does not exist in this response hostname lookup result uses NXDOMAIN with appropriate authority evidence. When aliases precede that answer, the missing name can be the alias target. Examine the path before deciding which configuration to investigate. The visible input name and the last name in the response are not always the same object.
An Alias path only hostname lookup result means some aliases were observed but the response did not establish a terminal address or the expected negative evidence. It preserves the useful path while acknowledging what is missing. A timeout, refusal, truncated message, or malformed answer instead leaves that query unavailable; none of these outcomes becomes an automatic “domain offline” conclusion.
The TTL values in a hostname lookup describe cache lifetimes, measured in seconds. Zero is a valid result and is displayed explicitly. A returned TTL is not the time since the domain was registered or the moment a record was last edited. Comparing TTLs alone cannot establish who changed a record or whether an update has reached every resolver.
Negative caching also affects a hostname lookup. A resolver can cache an absence response, so a newly created record may not immediately appear everywhere. The tool shows a negative cache lifetime when the necessary authority information is present. It does not promise that waiting that many seconds will force every resolver or application to display a new answer.
The DNSSEC field in the hostname lookup reports the resolver’s AD flag. A set flag indicates what the resolver asserted about authentication of the response data. MyIP.dog is not independently validating DNS signatures in your browser. A flag that is not set is distinct from a DNS error and does not, by itself, prove that a website is malicious or unreachable.
A hostname lookup may reveal aliases that match a documented delivery-provider naming pattern. This tool recognizes selected CloudFront, Fastly, and Akamai suffixes and shows the exact observed target and the relevant provider documentation. These are narrow, inspectable hints. They are not a complete inventory of every CDN, hosting platform, traffic manager, or service a site uses.
For example, a hostname lookup can associate a returned alias under a recognized provider suffix with that provider’s documented naming convention. It cannot establish whether a distribution is active, whether the domain’s routing configuration is correct, or whether the provider serves every resource on the page. A site can use different delivery services for its HTML, images, video, and API.
When the hostname lookup finds no recognized alias, it does not conclude that no CDN is involved. Flattening can return addresses without exposing the underlying alias as an ordinary CNAME answer. Direct address configurations, provider-specific designs, and services outside this tool’s signature set can also leave no recognized hint. Lack of a match is simply lack of this particular evidence.
The hostname lookup matches suffixes at DNS label boundaries. A name that merely contains a provider’s brand, or appends another domain after a familiar-looking suffix, does not receive that provider hint. This helps avoid misleading matches from attacker-controlled names. Nevertheless, a genuine-looking target can be misconfigured or obsolete, so the hint still does not replace an actual service check.
Your hostname lookup result can differ from a colleague’s result. DNS answers may depend on resolver location, cache state, traffic-management choices, and time. This page reports one named resolver path rather than worldwide DNS propagation. For a controlled investigation, keep the input name and record type consistent, record the observation time, and compare the resolver used by each test.
A hostname lookup also cannot identify the physical machine behind a shared address. Anycast, load balancers, reverse proxies, and shared hosting can place many systems or services behind the same visible destination. Use the result as a DNS starting point. Do not interpret a network registration address or the location of a resolver as the exact location of a website’s origin server.
Start with a hostname lookup when a name resolves unexpectedly. Compare the spelling, whether the www label is present, the returned alias path, and the requested address family. Then inspect the relevant DNS records and the authoritative configuration you administer. The report provides evidence for that conversation; it does not modify DNS, clear remote caches, or change traffic routing.
Follow a hostname lookup with ASN lookup for a public address whose observed routing origin interests you, or IP WHOIS lookup for number-resource registration. Copy the particular address intentionally. These are separate datasets with different meanings: registration and route observations cannot automatically establish the owner of a website or the identity of a visitor.
If your hostname lookup returns records but a connection fails, use the port checker for an explicit public TCP test or ping test for a remote-probe observation. Each tool has a different vantage point and protocol. A successful DNS answer does not guarantee that a firewall permits the port or that an application responds correctly.
No. A hostname lookup starts with a name and inspects forward records. Reverse DNS lookup starts with an address and asks for PTR records in the reverse namespace. These records are maintained separately. A PTR can be absent or point to a name that differs from a website’s name, without contradicting its forward DNS records.
A hostname lookup can receive several addresses because the name publishes an address set or uses delivery infrastructure with multiple destinations. The list is the resolver’s answer at that time, not an exhaustive scan of every possible serving endpoint. This tool displays the returned set and does not choose one to claim it is the site’s unique or permanent server.
Yes. Public DNS can return a private or special-use address, and the hostname lookup labels its range instead of contacting it. The result does not prove that the service is accessible from the public internet. It might relate to an internal design, a mistake, or another configuration context. Investigate the domain’s intended use before changing it.
Stopping the hostname lookup aborts waiting and invalidates pending results in this tab. A DNS question already received by the service or resolver may have started processing. Clear also resets the input. Leaving through site navigation or a page lifecycle event invalidates the pending response so that an old result cannot reappear after you have cleared it.
Use Copy report to export the hostname lookup evidence as JSON, including individual questions, returned records, times, interpretation, and provider hints. Review the name and records before sharing. Even DNS information can disclose something about a business or a system under investigation. The report should travel with its stated resolver and limitations rather than become an unexplained screenshot of one address.
The hostname lookup follows the Google Public DNS JSON interface. Background references include RFC 1034 for DNS concepts and RFC 2308 for negative caching. Provider hints link to CloudFront, Fastly, and Akamai; Cloudflare’s flattening explanation illustrates why aliases may be hidden. Sources were checked on September 28, 2026.