MyIP.dogChecking…
DNS lookup
Query DNS records and inspect answers, TTLs and response codes from a named public resolver.
Query DNS records and inspect answers, TTLs and response codes from a named public resolver.
Checking…
A DNS lookup asks a resolver for records attached to a name. Enter a domain such as example.com, choose a record type, and run the query. Do not include a scheme, path, or port: https://example.com/account is a URL, while example.com is the DNS name. The DNS lookup above sends the name to Google Public DNS through this site's server and displays the response with its source and observation time.
Choose the record type according to the problem. Use A for IPv4 destinations, AAAA for IPv6 destinations, MX for mail routing, and TXT for text records such as domain verification and email policies. NS identifies name servers, CNAME identifies an alias, SOA describes zone administration, and CAA expresses certificate issuance policy. One DNS lookup does not return every possible record in a zone, so a clean A result does not establish that email is configured correctly.
The example button fills the input without sending a request. You can inspect or change it before submission. Internationalized domains are converted to their ASCII form, and a trailing dot is accepted. Names containing service labels, such as _dmarc.example.com, are useful for TXT queries. If the DNS lookup rejects your input, check for a copied space, full URL, empty label, or label longer than the DNS format permits.
The query is sent to the named resolver to obtain a real answer. It is not sent to the domain's website as an HTTP request. The resolver may need to contact authoritative name servers if the relevant answer is not cached. This DNS lookup requests an empty EDNS client subnet to avoid forwarding part of your client network for geographic selection. The query still discloses the requested name to the resolver, so avoid submitting confidential internal hostnames unnecessarily.
Each answer row includes a name, record type, TTL in seconds, and record data. Multiple rows can be legitimate: a service may publish several addresses for availability or traffic distribution. An alias can also appear before the final address. A DNS lookup is a snapshot of the resolver's view at the observation time, rather than a permanent inventory of the domain's infrastructure.
The TTL tells caches how long a record may be retained, subject to resolver behavior. A cached answer's remaining TTL can be lower than the value configured at the authoritative provider. A DNS lookup that returns a lower number a minute later is therefore not automatically evidence of a configuration change. Compare the record values, resolver, and time as well as the number in the TTL column.
NOERROR means that the DNS operation completed without the indicated protocol error. It can still have no answer records for the requested type. For example, a name can have an A record but no AAAA record. NXDOMAIN means the queried name does not exist according to that response. SERVFAIL means the resolver could not complete the operation, which can involve upstream failures, DNSSEC validation, or other problems.
Do not read every empty DNS lookup as “the domain is offline.” An empty AAAA response says little about an IPv4 website. A mail domain can work through MX records even when the bare name is not intended to serve a web page. If a DNS lookup returns an error, retain the exact response code and query type when reporting the issue. They are more useful than a screenshot labeled only “DNS broken.”
The authenticated-data flag reports whether the resolver marked the response as authenticated. An absent flag is not a declaration that the website is malicious. The domain might be unsigned, or the response might not carry authenticated data for other reasons. A successful DNS lookup with this flag also does not verify a website's business, content, or login form. DNSSEC concerns DNS data authenticity, not all aspects of internet safety.
This tool uses a remote public resolver. It cannot see your operating system's DNS cache, a hosts-file override, a private corporate resolver, or every browser's secure DNS settings. If a DNS lookup here succeeds while your browser fails, compare the local resolver and application configuration. A VPN can also provide a different DNS view for internal names. That difference is not necessarily an error in the public answer.
Geographic routing can make different resolvers receive different records. Cached answers can differ during a change, and authoritative servers can be temporarily inconsistent. A single DNS lookup cannot prove worldwide propagation. Repeat a focused query after a sensible interval, compare independent resolvers when necessary, and check the authoritative configuration. Avoid making rapid requests that cannot reveal a meaningful change within the published TTL.
This DNS lookup is also not a DNS leak test. A leak test needs to observe which recursive resolvers receive names generated by your browser's test session. Calling a known public resolver through our server establishes only that resolver's answer. It says nothing by itself about whether your VPN carries the browser's normal DNS traffic. Keep those two diagnostic questions separate.
First confirm that the record was changed in the authoritative zone actually delegated for the domain. Editing an account at an unused DNS provider will not update public answers. Next, compare the exact owner name: www.example.com and example.com are separate names. A DNS lookup for one does not automatically describe the other, even when users expect both to open the same website.
Then review the old TTL and allow existing caches to expire. Lowering the TTL after a record was cached does not retroactively change the timer in every resolver. Use the DNS lookup response as evidence of one resolver's current state and record the timestamp. If answers remain inconsistent after the expected interval, inspect delegation, authoritative replies, and DNSSEC configuration rather than repeatedly clearing only your browser cache.
DNS records primarily describe naming and service configuration. A TXT value or SOA mailbox is not a verified statement of legal ownership. Domain registration data is a different source and may be redacted. For IP network registration, use the IP WHOIS lookup. Do not treat a DNS lookup as proof that a named organization controls every service or piece of content delivered through an address.
Operators can publish several destinations to distribute requests, support redundancy, or route clients differently. The client and surrounding infrastructure decide which address is actually used. A DNS lookup with several rows does not measure server health or guarantee that all destinations answer from your network. If a connection fails intermittently, compare the observed destination with individual connection results gathered through an appropriate network diagnostic.
Use the reverse DNS lookup for an address. It constructs the appropriate reverse name and requests PTR records. An ordinary DNS lookup for a domain follows the forward direction. The two directions are maintained separately and need not match. A missing PTR record does not establish that an address is unused, and a returned hostname does not list every site sharing that server.
No. Name resolution can succeed while a connection is blocked, the TLS certificate is wrong, or the web application is failing. A DNS lookup handles the naming step. Network reachability, encryption negotiation, and the application response are additional steps with different failure modes. Keep the successful DNS evidence and investigate the next layer instead of changing healthy records without a reason.
Include the name, record type, response code, relevant answers, resolver, and time. State what you expected and whether the problem affects one network or several. The copy button exports the structured result, which makes exact TTLs and values easier to preserve. Review TXT values and internal names before posting them publicly. A concise, accurately scoped DNS lookup report helps another person reproduce the same question.
The resolver interface and response fields are documented by Google Public DNS. For a guided explanation, read what is DNS, then return to the DNS lookup with a specific name and record type. The general DNS concepts are defined in RFC 1034 and the record and message format in RFC 1035. These specifications help interpret a DNS lookup; they do not substitute for checking your own authoritative configuration and application behavior.
For a combined view of forward addresses and aliases, open hostname lookup. It runs three DNS lookup questions and keeps their answers separate. This can reveal a useful CNAME path while preserving an unavailable address-family query, without treating a DNS lookup as a website availability test.