DNS Checker Free Tool

Enter a URL

Enter a domain or URL

About DNS Checker

What This Tool Actually Does

The DNS Checker sends a single DNS query from this server and displays every record it finds. The query uses PHP's native dns_get_record() function with the DNS_ALL flag, which asks the operating system's resolver for every record type it understands. The server sits in Germany at a Hetzner data center. There is no third-party API involved and no network of global test points behind the scenes.

You type a domain into the form above. The tool strips http://, https://, and www. from whatever you enter. It then prepends http:// and validates the result. If the input fails validation, you see the message "Input Site is not valid!". If the input passes, the tool extracts the host part, drops any path you may have included, and makes one resolver call for that host.

The output is a series of bordered tables, and each table represents one DNS record, so you can easily scan through the results for each type. Each row inside a table represents one field of that record, exactly as PHP names it. You will see Host, Class, Ttl, Type, and then type-specific fields like Ip, Ipv6, Target, Pri, Txt, Mname, Rname, Serial, Refresh, Retry, Expire, Minimum-ttl, Flags, Tag, and Value.

This is a lookup tool, and it shows you what this one server's resolver returns at the moment you click Submit, which means you get a snapshot of the current DNS state. It does not compare answers from multiple cities. It does not track changes over time. It does not tell you whether a DNS update has finished spreading across the internet. Those tasks belong to other services, and this page makes no claim to perform them.

The live test run for this rewrite used two domains, and the first was example.com, which returned two A records, two NS records, and one SOA record, so the output was complete. The second was github.com, which returned one A record, one MX record, eight NS records, one SOA record, seven CAA records, and twenty-four TXT records. The github.com page was long. Yours will be too if you check a domain with heavy email authentication and verification records.

A domain that does not exist produces no tables at all, and you get an empty result page with only the "Try New URL" button, which clearly indicates the lookup failed. There is no error message for this case. The tool simply finds nothing and shows nothing.

How to Use This Tool

1. Open the tool page. Find the input box above this article and make sure you are on the DNS Checker page at limitlessreferrals.info.
2. Enter a domain name. Type the bare domain like example.com, or include a subdomain like mail.example.com if you want records for that specific host.
3. Include a protocol if you prefer. The tool accepts http://example.com or https://example.com and strips the protocol before looking up the host.
4. Submit the form. Click the Submit button. The page will reload and show the results below the form.
5. Read the record tables. Each table is one DNS record. Look at the Type row to know what kind of record you are viewing, then read the type-specific fields.
6. Run another check when needed. Use the "Try New URL" button or the form again. Remember that TTL values count down, so a second run moments later will show different numbers.

What Each Record Type Table Means

DNS records come in several types, and each type carries different information, so the tables on this page name their fields the way PHP names them, which mostly matches the official DNS terminology from the relevant RFCs. You do not need to know RFC numbers to read the tables, but knowing what each field means helps.

A Records

An A record maps a hostname to an IPv4 address. The table shows Host, Class, Ttl, Type, and Ip. The Ip row contains the actual IPv4 address, something like 172.66.147.243. When a domain has multiple A records, you get multiple tables, one per address. This is how round-robin load balancing appears in DNS. example.com returned two A records in the live test, which means the domain resolves to two different IPv4 addresses.

The Class row will say IN, which stands for Internet. You will rarely see anything else in modern DNS. The Ttl row shows the remaining time to live in seconds, which we will discuss in detail later.

AAAA Records

An AAAA record maps a hostname to an IPv6 address. The table looks like the A record table, and the address field is named Ipv6. IPv6 addresses are long hexadecimal strings with colons, like 2606:4700::6810:179a. Many domains still lack AAAA records entirely. github.com showed no AAAA table in the live test because github.com has no IPv6 address published.

If a domain has no AAAA records, you will simply not see a table for that type. The tool does not tell you that a type is missing. It only shows what exists.

MX Records

An MX record tells email senders which mail servers handle mail for a domain. The table shows Host, Class, Ttl, Type, Pri, and Target. The Pri field is the priority number, also called preference. Lower numbers win. A mail server with priority 10 is tried before one with priority 20. The Target field names the mail server hostname, like aspmx.l.google.com.

The live test on github.com returned one MX record. You may see several MX records for domains that use multiple mail providers or redundant mail servers. The priority numbers tell the sending server the order to try them.

NS Records

An NS record names the authoritative name server for a domain. The table shows Host, Class, Ttl, Type, and Target. The Target field contains the name server hostname, like hera.ns.cloudflare.com. example.com returned two NS records in the live test, both belonging to Cloudflare. github.com returned eight NS records.

These are the servers that hold the authoritative answer for the domain. When you change nameservers at your registrar, you are changing the NS records that the parent zone points to. The NS records shown here come from the domain's own zone, which may differ briefly from what the parent zone lists during a nameserver change.

SOA Records

The SOA record, short for Start of Authority, is the administrative record for a zone. It contains more fields than any other record type. The table shows Host, Class, Ttl, Type, Mname, Rname, Serial, Refresh, Retry, Expire, and Minimum-ttl.

Mname is the primary name server for the zone. Rname is the email address of the zone administrator, formatted with a dot instead of an at sign, so hostmaster.example.com means hostmaster@example.com. Serial is a version number that secondary name servers use to detect zone changes. Refresh tells secondaries how often to check for updates. Retry tells them how long to wait after a failed refresh. Expire tells them when to give up on a primary that never responds. Minimum-ttl is the default TTL for records that do not specify their own.

The SOA record is the one place where you see the full administrative heartbeat of a domain. If you are troubleshooting why a nameserver change has not propagated, the SOA Serial on your new provider should be higher than the old one.

TXT Records

A TXT record holds arbitrary text. Modern DNS uses TXT records for email authentication and domain verification. The table shows Host, Class, Ttl, Type, and Txt. The Txt field contains the text string, which can be long.

SPF records appear as TXT records starting with v=spf1. DMARC records appear as TXT records on the _dmarc subdomain. Domain verification tokens from Google, Microsoft, and other services also appear as TXT records. github.com returned twenty-four TXT records in the live test, a large number that reflects heavy email security and verification needs.

The tool shows TXT records for the bare domain you enter. To check a DMARC record, you would enter _dmarc.example.com. To check a DKIM selector, you would enter the full selector subdomain like selector1._domainkey.example.com. The tool keeps subdomains other than www, so these lookups work.

CAA Records

A CAA record restricts which certificate authorities may issue certificates for a domain. The table shows Host, Class, Ttl, Type, Flags, Tag, and Value. The Tag field is one of issue, issuewild, or iodef. The Value field names the certificate authority, like letsencrypt.org. The Flags field is a number, usually 0, that indicates whether the record is critical.

github.com returned seven CAA records in the live test. This is a higher-than-average count and reflects careful control over certificate issuance. If a CAA record exists and a certificate authority is not listed, that authority must not issue a certificate for the domain.

CNAME, PTR, SRV, NAPTR, HINFO, and A6 Records

The DNS_ALL flag asks for every record type PHP supports, including CNAME, PTR, SRV, NAPTR, HINFO, and A6. These appear less often in ordinary lookups. A CNAME record maps one hostname to another and shows a Target field. A PTR record maps an IP address to a hostname and is used for reverse lookups. An SRV record specifies a host and port for a service and shows fields like Priority, Weight, Port, and Target. NAPTR records support telephone number mapping and other complex routing. HINFO records describe hardware and operating system, and they are rare. A6 records were an experimental IPv6 address format that never saw wide adoption.

Because the tool strips www from the input, you cannot see the CNAME record that a www subdomain often has. Entering www.github.com returns the records of github.com directly. The tool answers the question of what a domain resolves to.

Reading the Live Test Results

The live test run for this rewrite produced concrete results worth examining. example.com returned two A records with addresses 172.66.147.243 and 104.20.23.154. Both addresses belong to Cloudflare's anycast network. The NS records named hera.ns.cloudflare.com and elliott.ns.cloudflare.com, confirming that example.com uses Cloudflare for authoritative DNS.

The TTL values in that test were telling. The A records showed a TTL of 195 seconds at the moment of the query. The NS records showed 82504 seconds. The SOA record showed 277 seconds. These numbers differ because each record type can have its own TTL, set by the zone administrator. The A records had a short TTL, which is common for records that may change during load balancing or failover. The NS records had a long TTL, which is typical because nameserver changes are rare and should propagate slowly.

github.com returned a different picture. One A record, one MX record, eight NS records, one SOA record, seven CAA records, and twenty-four TXT records. No AAAA records appeared because github.com has none. The MX record shows where github.com wants email delivered. The eight NS records show a highly redundant authoritative DNS setup. The CAA records restrict certificate issuance to approved authorities. The TXT records include SPF, verification tokens, and other authentication material.

You will encounter both simple and complex cases. A small domain like example.com returns a handful of tables. A large service like github.com returns dozens. The page length varies accordingly, and there is no way to filter the output to one record type.

Why TTL Numbers Change Between Runs

You will notice that running the same domain twice produces different TTL values. This is not a bug. TTL stands for time to live, and it counts down. When a DNS record is fetched from an authoritative server, the resolver stores it in cache with a TTL measured in seconds. Each second that passes reduces that number. When you query the same domain a minute later, the TTL has decreased by roughly sixty seconds.

The live test on example.com showed an A record TTL of 195. If you run the same check now, you will see a different number because time has passed. The authoritative TTL for that record might be 300 seconds, and the resolver cached it some seconds before your query arrived. The number you see is the remaining lifetime of the cached entry, not the original TTL set by the zone administrator.

When the TTL reaches zero, the resolver discards the record and fetches a fresh copy from the authoritative server. The TTL then resets to the full value. This is why you may see a TTL jump from a small number to a large one between two runs. The cache expired in between.

A domain can have multiple DNS records of the same type. Your registrar or DNS provider shows one TTL value in their control panel. This tool shows another. Both are correct. The control panel shows the configured TTL. The tool shows the remaining TTL from this server's resolver cache. The difference is the age of the cached entry.

Correcting the Old Description of This Tool

The previous version of this page described the DNS Checker as a propagation checker. It implied that the tool queried multiple locations around the world and compared their answers to show whether a DNS update had spread everywhere. That description does not match the code.

This tool makes one query from one server. The server is located in Germany at a Hetzner data center. There is no network of global test points. There is no comparison of answers from different cities or continents. The result you see is what this single server's resolver returns at the moment you ask.

The old page also included a question about why the DNS checker shows a different result than dig or a registrar's control panel. The answer in the old copy pointed to resolver cache and TTL, which is accurate. A single-location lookup cannot tell you whether a change has propagated to Tokyo, London, or New York. It can only tell you what one resolver in Germany currently knows.

The old page discussed SPF, DKIM, and DMARC checking. Those discussions were partially accurate. SPF records appear as TXT records on the bare domain, and this tool shows them if they exist. DMARC records live on the _dmarc subdomain, which you can enter because the tool only strips www. DKIM records live on selector subdomains like selector._domainkey.example.com, and you can enter those in full as well. What the old page did not make clear is that this tool has no special handling for email authentication records. It shows all TXT records, and you must find the SPF or DMARC entries yourself among the others.

The old page's claim about checking multiple locations was the main error. This rewrite corrects that claim. The tool is a single-location DNS lookup with full record type support. It is useful for inspecting the DNS configuration of a domain from one vantage point. It is not useful for verifying global propagation.

What a Single-Location Lookup Cannot Tell You

DNS propagation is the delay between when you change a record at your authoritative nameserver and when resolvers around the world have fetched and cached the new value. The delay depends on TTL values, on when each resolver last queried the zone, and on the caching policies of intermediate resolvers. No single query can measure this process.

A single-location lookup tells you what one resolver knows. If you just changed an A record and this tool still shows the old address, that means this server's resolver has not yet expired its cached copy of the old record. It does not mean the change has failed. It does not mean the change is slow everywhere. It means one resolver in Germany has a cached answer that has not expired.

If you just changed a record and this tool shows the new address, that means this server's resolver has fetched the new value. It does not mean every resolver worldwide has done the same. Resolvers in other regions may still hold the old value in cache until their TTL expires.

To check propagation properly, you need a service that queries multiple locations simultaneously. Such services exist, and they show you a map of which resolvers have adopted the new value and which still hold the old one. This tool does none of that. It gives you one data point.

You can apply the tool's output directly to your page. Use this tool to inspect the current DNS configuration of a domain as seen from Germany. Use a multi-location service when you need to verify that a change has spread. The two tools answer different questions.

Limitations of This Tool

Every tool has boundaries, and this one has several that come directly from its code. The most visible limitation is the lack of a record-type selector. The tool always queries with DNS_ALL, which means it requests every record type PHP supports. You cannot ask for only MX records or only TXT records. You get everything or nothing.

The output can be long. Domains with heavy email authentication, like github.com with its twenty-four TXT records, produce dozens of tables. You will scroll. There is no collapsible section and no summary view. The page simply lists every record in the order the resolver returns them.

The tool offers no choice of resolver or location. You cannot select a different DNS server to query. You cannot choose a location in North America or Asia. The query always goes to this server's own resolver in Germany. If you need to see DNS from another region, you need a different tool.

The tool strips www from the input. This means you cannot look up the www subdomain's own records. Many domains use a CNAME record for www that points to the bare domain or to a CDN. This tool will never show you that CNAME because it removes www before querying. Other subdomains are preserved, so you can look up mail.example.com or _dmarc.example.com.

The tool provides no DNSSEC information. If a domain uses DNSSEC, you will not see the RRSIG, DNSKEY, or DS records here. The DNS_ALL flag in PHP does not request DNSSEC-related record types in a way that this tool surfaces. You need a dedicated DNSSEC checker for that.

The tool does not perform reverse lookups. You cannot enter an IP address and get the hostname. The tool treats whatever you enter as a hostname to query, so an IP address does not produce a reverse (PTR) lookup here.

A nonexistent domain shows no error. The result page is empty except for the "Try New URL" button. This can be confusing. If you typo a domain, you get a blank page rather than a message explaining that the domain does not exist. The tool treats "no records found" and "domain does not exist" as the same outcome.

The TTL values are not the configured values. They are the remaining seconds from the resolver cache. If you need the authoritative TTL, you must query the authoritative nameserver directly, which this tool cannot do.

The rate limit is worth understanding. There is no CAPTCHA on this tool and no tool-specific request cap. A shared site-wide throttle applies to every page of this site. Roughly fifteen requests within a single second from one visitor address blocks that address for the rest of the day. This is a protective measure against abuse, not a normal usage limit. Ordinary use, even frequent use spread over minutes, will not trigger it.

These limits define what the tool is good for. It is a quick way to see the full DNS configuration of a domain from one server. It is not a propagation checker, not a DNSSEC validator, and not a global DNS monitoring service.

The Resolver Behind the Query

The query goes to the operating system's resolver on the Hetzner server. Hetzner is a German hosting company that operates data centers in Europe and elsewhere. The server's IP address is 204.168.255.143, and its physical location affects the answers you see.

DNS resolvers cache answers according to TTL values. When you query example.com, the resolver checks its cache. If a fresh answer exists, it returns the cached records with the remaining TTL. If the cache has expired, the resolver queries the authoritative nameservers, which for example.com are Cloudflare's hera and elliott nameservers, fetches fresh records, stores them in cache, and returns them to the tool.

The geographic location matters because some DNS providers return different answers in different regions. Content delivery networks use geo-DNS to route users to nearby servers. A query from Germany may return a different IP address than a query from the United States, even for the same domain. This tool always queries from Germany, so you will see the German answer.

The resolver's cache also matters. If a domain recently changed its records, the resolver may still hold the old values until their TTL expires. The tool shows you what the resolver has, not necessarily what the authoritative server currently publishes. This distinction is central to understanding why the tool's output may differ from a direct query to the authoritative server.

The Role of TTL in DNS

TTL is a fundamental part of the DNS protocol. Every record has a TTL, measured in seconds, that tells resolvers how long to keep the record in cache before asking the authoritative server again. The TTL is set by the zone administrator and can vary by record type.

Short TTLs, like 60 or 300 seconds, mean resolvers will re-query frequently. This is useful for records that may change, such as A records during a failover or load balancing event. Long TTLs, like 86400 seconds (one day), mean resolvers will cache aggressively. This reduces load on authoritative servers but slows down propagation when a change occurs.

The TTL values you see in this tool are the remaining values from the resolver cache. If a record has a configured TTL of 300 seconds and the resolver fetched it 120 seconds ago, the tool shows 180. Run the check again in thirty seconds and you will see roughly 150. The countdown continues until the resolver discards the record and fetches a new copy.

TTL values can vary between queries due to caching and record updates. It also explains why the tool may show a record that you just deleted from your DNS zone. The resolver still has the old record cached, and it will continue to serve it until the TTL expires. Deleting a record at the authoritative server does not purge it from every resolver worldwide. You must wait for the TTL to expire.

This table summarizes the record types you are most likely to encounter. The type-specific fields are the ones that matter for each record. The Host, Class, Ttl, and Type rows appear in every table.

How This Tool Differs From dig and nslookup

If you have used dig or nslookup on a command line, you have performed the same kind of query this tool performs. The difference is convenience and presentation. dig requires you to know the command syntax and to specify record types. This tool gives you a web form and shows all records at once.

dig also lets you choose which resolver to query. You can point dig at 8.8.8.8 for Google Public DNS or at 1.1.1.1 for Cloudflare. This tool has no such option. It always uses the server's default resolver.

Another difference is output format. dig shows raw DNS responses with header information, flags, and timing data. This tool shows only the record fields in tables. The output loses diagnostic detail but remains readable.

The live test results confirm that the tool returns the same kind of data dig would return for the same resolver. The A records for example.com match what Cloudflare publishes. The NS records match. The SOA record contains the expected administrative fields. The tool is not inventing data. It is presenting the resolver's answer in a clean format.

For users who do not have command-line access or who prefer a graphical interface, this tool fills the gap. It answers the question "what DNS records exist for this domain" without requiring any technical setup.

When to Use This Tool

This tool fits specific use cases. You have just registered a domain and want to confirm that the NS records point to your chosen DNS provider. You are setting up email and want to verify that your MX records are correct. You are troubleshooting a website that will not load and want to see which IP address the domain resolves to from this server. You are checking whether an SPF record exists before sending bulk email.

You are auditing a domain's security posture and want to see CAA records and TXT records. You are comparing the DNS configuration of your domain against a competitor's. You are a developer who needs a quick look at all record types without opening a terminal.

The tool is also useful for educational purposes. Seeing the SOA record fields laid out in a table makes DNS administration tangible. Seeing twenty-four TXT records on github.com illustrates how large organizations use DNS for email security and verification.

The tool is not useful for propagation checking, as discussed. It is not useful for DNSSEC validation. It is not useful for reverse DNS lookups. It is not useful for checking the www subdomain's CNAME. Knowing these exclusions prevents frustration.

The Single Query Design

The tool makes exactly one call to dns_get_record with the DNS_ALL flag. This design choice has consequences. The query is fast because it involves one round trip to the resolver. The output is complete because DNS_ALL requests every record type PHP supports. The page loads quickly even for domains with many records.

The single query also means the tool cannot show you records that require separate queries. A DKIM record on a selector subdomain requires its own query. If you enter example.com, you will not see DKIM records for selector._domainkey.example.com because those are separate DNS names. You must enter the full selector subdomain to see its records.

The same applies to DMARC. The DMARC record lives on _dmarc.example.com, not on example.com. Entering example.com shows the domain's TXT records, which may include SPF, but not the DMARC record. You must enter _dmarc.example.com to see it.

The tool strips only www from the input. This is a narrow transformation. Other subdomains pass through unchanged. This means you can query mail.example.com, _dmarc.example.com, or any other subdomain you need. The only hostname you cannot query is the www subdomain itself.

The Record Type Reference

The DNS_ALL flag requests the following record types from the resolver. PHP's dns_get_record supports A, AAAA, MX, NS, SOA, TXT, CNAME, PTR, SRV, NAPTR, CAA, HINFO, and A6. The tool displays a table for each record returned. Record types with no records produce no tables.

The table below lists the record types and their practical meanings. Use it as a quick reference when reading the output.

When you see a table, identify the Type row first. Then read the type-specific fields according to this reference. The Host row tells you which hostname the record belongs to. The Class row will almost always say IN. The Ttl row tells you the remaining cache time.

Related Tools

When you need to convert a domain name into its IP address without the full DNS record breakdown, use the Domain into IP Converter. It gives you the address quickly without the surrounding record tables.

When you want ownership, registration, and expiration details for a domain, use the Whois Checker. It complements the DNS Checker by showing the registrar-side data that DNS records do not contain.

When you want to find all domains hosted on the same IP address, use the Reverse IP Domain Checker. It works in the opposite direction from this tool, starting with an address and finding hostnames.

Frequently Asked Questions

Why does the DNS checker show a different result than dig or my registrar?

The tool queries this server's resolver in Germany, and that resolver serves cached answers until their TTL expires. Your registrar shows the configured values from the zone file, while this tool shows what the resolver currently holds. If you just changed a record, the resolver may still have the old value cached. Wait for the TTL to expire and run the check again.

I got no results at all. What does that mean?

A nonexistent domain or a domain with no DNS records produces an empty result page with no tables and no error message. The tool does not distinguish between a domain that does not exist and a domain that has no records. Check your spelling and confirm the domain is registered and has DNS configured.

Can I check SPF, DKIM, and DMARC records with this tool?

SPF records appear as TXT records on the bare domain, so entering example.com will show them if they exist. DMARC records live on the _dmarc subdomain, so enter _dmarc.example.com to see them. DKIM records live on selector subdomains like selector._domainkey.example.com, and you can enter those in full because the tool only strips www.

Why does the TTL number change every time I run a check?

TTL counts down from the moment the resolver caches a record. Each second that passes reduces the number you see. When the TTL reaches zero, the resolver fetches a fresh copy and the number resets to the full configured value. The number you see is the remaining cache time, not the configured TTL.

Why can't I see the CNAME record for www.example.com?

The tool strips www from the input before querying. Entering www.example.com returns the records of example.com, not the www subdomain's own records. This design choice means you cannot see the CNAME that many domains use for their www subdomain. Other subdomains are preserved and can be queried normally.

Is this a DNS propagation checker?

No. This tool makes one query from one server in Germany. It does not query multiple locations around the world, and it cannot tell you whether a DNS change has propagated globally. Use it to inspect the current DNS configuration from this server's vantage point. Use a dedicated multi-location propagation checker when you need to verify that a change has spread everywhere.