workers.dev DNS lookups usually happen when something already feels wrong. A website may be loading for one person and failing for another, mail may be bouncing without a clear reason, or a recent DNS change may not be visible yet on every network. This route is designed to answer that specific debugging intent instead of acting like a thin doorway. You get the live records for workers.dev, the TTL values that explain cache behaviour, and enough context to decide whether the issue is delegation, propagation, mail routing, or something above DNS entirely.
The page is also built to be operationally safe. There is no file upload, no account step, and no need to bounce through multiple tabs to understand what the record set means. The lookup runs securely against public resolver infrastructure, Plain Tools only requests the data needed for the response, and the surrounding content stays focused on what engineers, operators, and non-specialists actually need when they search phrases like "dns records workers.dev" or "nameservers for workers.dev".
DNS issues are deceptively expensive because they often look like application failures at first. If A or AAAA records point to the wrong origin, a site can appear down even though the server is healthy. If MX records are missing or misprioritized, email delivery fails while the website still looks normal. If TXT values are malformed, ownership verification and mail authentication break even though the rest of the zone is intact. This page narrows all of that into one route for workers.dev so users do not need to mentally reconstruct the zone from scattered command outputs.
Variant intent matters here. Someone searching for a DNS lookup page is rarely doing general education. They normally need to answer a production question, compare current answers with expected infrastructure, or explain to another teammate why a change has not propagated yet. That is why the content below spends time on TTL, delegation, and next-step diagnosis instead of just listing records in a raw table.
The record tables below are rendered on the server with cached DNS-over-HTTPS responses so the page remains indexable and shareable. Each record group shows the raw answer value, the TTL, the resolver that returned it, and the DNS status code where available. That gives you one stable reference page for workers.dev instead of a transient browser-only debug panel.
When you need a fresh manual check, use the live lookup widget in the sidebar. That widget lets you run a new DNS query, switch record types, and move straight into a new canonical /dns/[domain] route. The result is a workflow that supports both search intent and active troubleshooting without forcing users back to a generic tool homepage.
Step 1
Check whether the issue sits on workers.dev, a www subdomain, a mail hostname, or a service-specific subdomain. Debugging the wrong host is a common source of wasted time, especially after provider migrations.
Step 2
These records tell you which IPv4 and IPv6 targets browsers should contact. If the origin or CDN looks wrong, fix that first before spending time deeper in the stack.
Step 3
Mail delivery and domain verification usually fail because of missing or malformed MX and TXT entries, while NS issues can point to a delegation problem at the zone level.
Step 4
A low TTL suggests resolvers should refresh soon. A high TTL means old answers can remain visible longer, which explains why two networks can disagree after a change.
Step 5
Once the records match the expected infrastructure, the next question is whether the target IP is owned by the right provider, whether the host responds, and whether the site is actually healthy.
This section shows live answers for A, AAAA, MX, NS, TXT, SOA, and CNAME. Use the answer values together with TTL to decide whether the zone is correct, stale, or only partly propagated.
Record groups
7
Answers returned
8
Coverage
A, AAAA, MX, NS, TXT, SOA, CNAME
Lookup model
Secure public resolver query
A records are the most common DNS answers for websites. They tell browsers which IPv4 address to connect to when the hostname is requested.
| Host | Value | TTL |
|---|---|---|
| workers.dev. | 104.18.13.15 | 300s |
| workers.dev. | 104.18.12.15 | 300s |
AAAA records perform the same job as A records but for IPv6. They matter when a service supports modern dual-stack networking.
| Host | Value | TTL |
|---|---|---|
| workers.dev. | 2606:4700::6812:d0f | 300s |
| workers.dev. | 2606:4700::6812:c0f | 300s |
MX records control inbound email routing. They typically point to mail gateways and are often one of the first things to inspect when mail delivery fails.
NS records show which nameservers are authoritative for the domain. They matter during delegation changes, propagation checks, and provider migrations.
| Host | Value | TTL |
|---|---|---|
| workers.dev. | clyde.ns.cloudflare.com. | 21600s |
| workers.dev. | sofia.ns.cloudflare.com. | 21600s |
TXT records are used heavily for email authentication, domain ownership verification, and security policies. They can grow long and sometimes appear as multiple quoted segments.
| Host | Value | TTL |
|---|---|---|
| workers.dev. | v=spf1 -all | 300s |
The SOA record is the start-of-authority entry for the zone. It contains the primary nameserver, responsible mailbox, serial number, and refresh timing values used by secondary DNS servers.
| Host | Value | TTL |
|---|---|---|
| workers.dev. | clyde.ns.cloudflare.com. dns.cloudflare.com. 2402108617 10000 2400 604800 1800
| 1800s |
CNAME records point one hostname to another hostname. They are common for subdomains and CDN or SaaS integrations that want to control the final target.
A DNS lookup page becomes much more useful when it includes A, AAAA, MX, NS, TXT, SOA, and CNAME together. Web, mail, verification, and zone-authority issues often overlap, so isolating only one record type can hide the real cause of the incident.
That is especially true for workers.dev when teams are migrating providers, rotating infrastructure, or investigating partial failures that only affect one region, resolver, or delivery path.
A DNS answer is not just a value. The TTL tells you how long a resolver may continue serving that answer from cache before it asks again. During a migration or rollback, that one number often explains why one observer sees the new state while another still sees the old state.
Engineers often skip this and jump straight to blaming the upstream service. A page that exposes TTL next to the answer shortens that loop and makes the route useful for real troubleshooting, not just curiosity clicks.
DNS is only the first layer. Once resolution looks healthy, users usually need to inspect IP ownership, run a ping or reachability check, or verify whether the service itself is degraded. Strong internal links keep that path inside the same intent cluster instead of sending users back to search.
That internal-link structure is important for indexing and useful for people. It helps search engines understand the network-tool silo and helps users continue the diagnosis from the same context.
This route does not ask you to upload files, paste secrets, or create an account. The page only requests the public DNS data needed to answer the lookup. In practical terms that means the query target is the domain you asked for, and the result is returned with no extra workflow baggage.
Plain Tools stays explicit about the trade-off: DNS data lives on the public internet, so the page has to query a public resolver to retrieve it. The privacy-first part is that the request stays narrow, the route does not collect extra document data, and the page immediately gives you the next diagnostic step without pushing you through ad-heavy intermediaries.
The most common production mistake is a mismatch between the expected provider and the actual record target. A records might still point at an old server after a migration, or NS records might show that the domain is delegated to a different provider than the team assumes. That usually creates confusing partial failures where one network works while another still sees stale answers.
Email problems often come from MX and TXT, not the website records. If mail routing, SPF, DKIM, or DMARC entries are missing or malformed, the website can remain fully healthy while customer emails fail. This is why the route shows all major record types together rather than only the web-facing ones.
Finally, remember that correct DNS does not prove end-to-end availability. Once the records for workers.dev look right, move to IP ownership, ping, and status checks to confirm that the resolved target actually responds and belongs to the provider you expect.
Start with A and AAAA if the website is not loading, MX if mail is bouncing, NS if you suspect a delegation problem, and TXT when verification, SPF, DKIM, or DMARC checks are failing.
Resolvers can answer differently because of caching, load balancing, geographic routing, or because one resolver has not refreshed the record yet. TTL values help explain how long stale answers can persist.
TTL is the cache lifetime in seconds. A higher TTL means resolvers can keep an answer longer, which is good for stability but slower for rollbacks and record changes.
Yes. DNS only proves where traffic should go. The origin, CDN, TLS configuration, firewall, or application can still fail after resolution, which is why DNS checks should be paired with status and latency tools.
The NS records show which provider is authoritative for the zone. If the wrong nameservers are delegated at the registry, every other record can appear inconsistent depending on which resolver you query.
Plain Tools does not ask for uploads or account data here. The page runs the minimum public DNS query needed to return the records and present them with TTL and record-type explanations.
Strong internal linking keeps the route inside the same task silo instead of forcing users back to search results after one page.
Continue with related tools, comparisons, and practical guides.