Enter a URL
DNS records connect a domain name with the services that operate behind it. They can identify the IP address used by a website, the servers responsible for receiving email, the authoritative name servers for a DNS zone, verification text and other technical details. The Find DNS Records tool gives you a convenient way to inspect the records returned for one hostname without installing command-line software.
Enter a domain or webpage address and submit the form. The tool cleans the submitted value, extracts its hostname and requests the available DNS records for that host. The returned information can help with routine domain setup checks, migration reviews and troubleshooting. It is a lookup report, not a security audit, ownership certificate or guarantee that every resolver worldwide currently sees the same answer.
People normally use memorable names such as example.com, while network services depend on structured DNS data. When this tool receives a valid address, it separates the hostname from the rest of the URL. A path, query string or fragment is not itself a DNS name, so the lookup is performed for the hostname rather than the complete webpage address.
The server then requests the DNS record set available for that hostname. Results depend on records published by the domain's DNS provider and on what the server's resolver can return at that moment. Different subdomains may have different configurations, so testing the root domain does not reveal every record used by its subdomains.
You may enter a hostname such as example.com or a URL such as https://example.com/page. The tool uses the hostname for the DNS request. If you need to examine a subdomain such as mail.example.com or shop.example.com, enter that exact subdomain because its records may differ from those of the main domain.
An A record maps a hostname to an IPv4 address. A website may publish one A record or several addresses for redundancy and traffic distribution. The presence of an address shows where the hostname currently points; it does not prove that a website application is healthy or that the server accepts every type of request.
An AAAA record maps a hostname to an IPv6 address. A hostname can publish both A and AAAA records so compatible clients can connect over IPv4 or IPv6. If an AAAA record is configured incorrectly, some visitors using IPv6 may experience a different result from visitors using IPv4.
A CNAME record makes one hostname an alias of another canonical hostname. It is frequently used for subdomains connected to hosted services. A CNAME points to another name rather than directly storing the final IP address, so additional DNS resolution may be required. DNS providers also impose rules about where CNAME records can be used.
MX records identify the mail exchangers that receive email for a domain. Each entry normally includes a priority value; mail systems generally try the server with the lower preference number first, subject to the applicable mail configuration. An MX record alone does not confirm that mailboxes, authentication policies or spam controls are correctly configured.
NS records identify the authoritative name servers for a DNS zone. These servers publish answers for the zone. When investigating delegation problems, compare the name servers configured at the domain registrar with the authoritative configuration. A mismatch can cause inconsistent or failed lookups.
The Start of Authority record provides administrative and timing information for a DNS zone. It commonly includes the primary name server, a responsible-party field, a serial value and timers used by DNS infrastructure. The serial helps secondary servers recognise zone changes. The exact presentation of these fields may vary between lookup interfaces.
TXT records store text data associated with a name. They are commonly used for domain verification and email-related policies such as SPF, DKIM and DMARC. A long TXT value may be returned in multiple quoted sections even though applications interpret it as one logical value. Do not publish secret keys or other private credentials in a public DNS record.
Depending on the domain and the lookup environment, results may include records such as CAA, SRV, PTR, NAPTR or other supported types. CAA can restrict which certificate authorities may issue certificates for a domain. SRV records describe the location of certain services. PTR records are mainly used for reverse DNS and are usually managed for an IP address by the organisation controlling that address.
TTL means time to live. It tells caching resolvers how long a DNS answer may generally be kept before it should be refreshed. A high TTL can reduce repeated queries but can also make planned changes take longer to appear through caches. A low TTL may help during a controlled migration, although the effective update time still depends on previous cached values and resolver behaviour.
DNS changes are not necessarily visible everywhere at the same moment. One resolver may still have an earlier response cached while another has already requested the new data. Therefore, a difference immediately after an update does not always mean that the DNS provider failed. Check the authoritative configuration, allow for the prior TTL and retest from an appropriate resolver.
A blank or incomplete result can have several explanations. The hostname may be misspelled, the requested subdomain may not exist, the domain may have no record of that type, or the resolver may have received an error. DNSSEC problems, temporary name-server issues, network restrictions and recent configuration changes can also affect a lookup.
The tool requests the record data available through its server environment. A request for all supported record types should not be interpreted as a promise that every conceivable DNS record will be displayed. PHP, the operating system, the resolver and the authoritative response can affect the returned set. For a critical production change, compare the result with the authoritative DNS provider and use specialist diagnostic tools where necessary.
These checks can reveal configuration clues, but they should be combined with application, hosting, email and certificate tests. Correct DNS only directs clients toward the intended service; it cannot prove that the service itself is configured correctly.
DNS availability supports access to a website, so broken records can prevent users and search crawlers from reaching pages. That makes reliable DNS an important technical foundation. However, an individual DNS record or a particular record count is not a page-quality score, and this report does not predict search position.
Use the lookup to diagnose reachability and migration issues. Search visibility also depends on crawl access, indexability, canonicalisation, redirects, content usefulness, internal discovery and many other signals. Publishing extra DNS records does not by itself improve rankings, and unnecessary records can make a configuration harder to maintain.
No. It performs a lookup for the hostname entered. DNS does not normally provide a public list of every possible subdomain. Enter each known subdomain separately when you need to inspect it.
A resolver may still be serving a cached response based on the earlier TTL. Confirm the new value at the authoritative provider, check the previous TTL and test again after the relevant cache can refresh.
Not always. It can mean the hostname has no applicable record, the lookup failed temporarily, the input was invalid or the resolver could not obtain an answer. Check the exact hostname and authoritative DNS settings.
No. It only reads publicly available DNS information. Changes must be made through the DNS provider, hosting panel or registrar responsible for the domain's DNS configuration.
No. The report can show relevant routing records, but separate tests are required to confirm that the web server, mail server, TLS certificate and application respond correctly.
The Find DNS Records tool provides a practical snapshot of the record data returned for a selected hostname. Read each record in context, account for caching and verify important changes against the authoritative provider. Used this way, the report can support accurate troubleshooting without treating DNS data as a ranking guarantee, complete security assessment or substitute for ongoing domain administration.