Skip to content
MyIP.dog

DNS and routing

What is DNS? Resolution, records and troubleshooting

Learn how DNS connects names with records, what resolvers and authoritative servers do, and how to distinguish a lookup failure from a connection problem.

Published:

What DNS means

DNS stands for Domain Name System. It is a distributed naming system that lets software request records associated with a name. The familiar example is finding an address for a website, but the system also carries information used by email, service discovery and other applications. A name can have several records, and an address can serve many names.

For a practical starting point, open DNS lookup, enter a public domain and select a record type. Read the name, answer, response code, resolver, TTL and observation time together. Those details make the result more useful than an isolated address copied from a table. The tool's explanatory content shows how its particular query is performed.

A domain is not the same thing as an IP address, and DNS is not the same thing as web hosting. A domain registration, a delegation, a record and a running website are related but separate resources. A company may provide several of them through one dashboard, which can hide the distinction until a configuration or renewal problem occurs.

Names describe a hierarchy

In DNS, dots separate labels within a hierarchical name. For a name such as www.example.com, responsibility can be delegated through that hierarchy. The root and the relevant top-level domain help a resolver find the appropriate authority; they do not store every site's full collection of records in one central table. Naming architecture, RFC 1034

This organization explains why a DNS problem can involve different operators. The registrar, parent-zone operator, authoritative hosting provider and recursive service may each have a distinct role. When investigating a failure, identify which part supplied the observed answer or referral. Changing a website's application code will not repair a broken parent delegation.

How DNS resolution works

A typical application asks a local resolver interface for information. That request may be satisfied from a cache or passed to a recursive resolver. The recursive service obtains an answer, potentially following referrals and aliases, and returns it to the client. Some applications use their own configured service, so the operating system setting is not always the complete picture.

The two DNS server roles most often confused are recursive and authoritative. A recursive resolver pursues answers for clients and commonly caches them. An authoritative server supplies the records or authoritative negative information for the zones it serves. One software package can support both roles, but their responsibilities remain different. Current terminology, RFC 9499

An uncached DNS resolution can involve the root, the relevant top-level domain, and the domain's authoritative servers. Referrals and previously cached information influence which requests are necessary. The browser does not need to contact every level directly on every page visit. A diagram of the full chain is a learning aid, not a literal trace of every connection.

After a DNS answer supplies suitable destination information, the application still needs to establish its intended connection. Routing, transport, TLS and application behavior can fail later. A successful lookup therefore does not prove that the website is healthy. The TCP/IP guide explains those later responsibilities without combining them into one result.

Follow a small example

To investigate DNS for a public website, begin with its exact hostname rather than a complete URL. The path after the hostname is normally part of the web request, not the record name you want to query. Check the browser address bar carefully: example.com and www.example.com are different names and can have different records.

Query A and AAAA separately in the lookup tool. Do not expect both to exist for every name. Save the record type and response code alongside any returned values, and inspect an alias if one appears. DNS observations can change over time or vary by resolver context, so this guide does not publish a fixed address as the permanent answer for a live domain.

Then compare the result with the symptom. If the site fails only on one device, a successful query from our server is useful context but not proof that the device received the same answer. If several independent networks report the same failure, inspect authoritative configuration and service status. Preserve the evidence from each vantage point rather than merging it into one universal claim.

Common DNS record types

DNS records have types because a name can support several kinds of information. Ask for the type related to the task. An address record helps with a destination; a mail-exchange record describes mail routing; a text record can carry application-specific data. A missing answer of one type does not establish that the name itself is absent.

  • A: an IPv4 address associated with a name.
  • AAAA: an IPv6 address associated with a name.
  • CNAME: an alias pointing to another name, requiring the relevant answer to be obtained through that relationship.
  • MX: a mail-exchange name and preference used for mail routing.
  • NS: nameservers associated with a zone or delegation context.
  • SOA: zone administration and timing information.
  • TXT: text strings interpreted according to the application using them.
  • PTR: a name returned from the appropriate reverse-address namespace.

The base record formats and message structure are defined in RFC 1035, with additional types defined by later specifications. DNS is extensible; the list above is a practical starting set, not every possible type. A tool that checks only address records has not inspected every record associated with a domain.

For reverse DNS, an IP address is transformed into the corresponding reverse query name before requesting PTR records. The result is not a complete inventory of websites hosted at that address, nor proof of a person's identity. Use reverse DNS lookup when that narrower question matches your task.

Mail-related DNS also needs context. Finding an MX record does not prove that a mail server accepts messages or that a sender is authorized. Text-based policies have their own syntax and evaluation rules. Inspect the exact requirement rather than treating the mere presence of a TXT value as a successful email-security configuration.

DNS caching, TTL and update timing

DNS answers commonly include a time to live, or TTL, expressed in seconds for caching purposes. A recursive service can reuse an answer while it remains eligible in its cache. This reduces repeated work and latency. The TTL shown by a cached response may be lower than the value configured at the authority because some of its lifetime has already elapsed.

The phrase “DNS propagation” often bundles several different events together: publishing new authoritative data, changing delegation, and waiting for previously cached information to age out. There is no single global refresh button. Lowering a TTL shortly before a change does not retroactively shorten a longer lifetime already cached elsewhere.

Negative DNS information can also be cached. An earlier result saying a name does not exist can remain relevant after a new record is added until the negative-cache rules allow a refresh. Distinguish that from a positive record with an old value. Negative caching, RFC 2308

Cache behavior is not a precise worldwide stopwatch. Some recursive services support controlled use of stale data during upstream problems, as described in RFC 8767. For a DNS migration, compare authoritative answers and named resolver observations, preserve timestamps, and investigate discrepancies instead of promising that every client switches at an identical instant.

Troubleshoot DNS by reading the response

Start with the exact name and requested type. A typo, a missing label or a query for the wrong record can explain an apparently empty DNS result. Check whether the name is intended to be public. Internal company names may resolve only through an authorized network's resolver; sending them to a public tool may be inappropriate and will not reproduce that private configuration.

NOERROR means the query did not receive a protocol-level error code; it can still have no answer of the requested type. NXDOMAIN indicates a non-existent queried name in the response's context. SERVFAIL indicates that the server could not complete the request. A timeout means no usable response arrived within the tool's wait. These DNS outcomes require different next steps.

If a public record exists but an application fails, move to the next layer of evidence. If the name is absent, verify its spelling, delegation and publication. If validation or upstream resolution fails, inspect the responsible service and authoritative configuration. Repeatedly changing local DNS settings without identifying the failure can hide the cause rather than fix it.

Use a controlled comparison when the problem affects one connection. Query the same name and type through an appropriate second resolver, then keep both source labels with the results. Different answers can reflect caching, local policies or distributed service design. A difference alone does not prove tampering or establish which answer your application actually used.

DNS security and encrypted transport

DNSSEC supplies mechanisms for authenticating data and checking integrity within its validation model. It does not encrypt the lookup or prove that a website is benign. The validation chain and the resolver's behavior matter. Our lookup reports the named resolver's returned authentication indicator; it does not independently repeat every cryptographic validation step. DNSSEC overview

Encrypted DNS transports protect a particular communication path, such as the exchange between a client and a configured resolver. The resolver still processes the question. Encryption is therefore different from a guarantee of no logging, anonymity or device-wide VPN coverage. DNS over HTTPS is specified in RFC 8484.

Changing a DNS provider normally changes the naming service used for queries, not the public source address of your ordinary web connection. If the actual objective is a different public exit, read how to change your IP address. Keep the purpose of a setting separate from the broader privacy outcome you hope to achieve.

DNS questions in everyday use

Can one domain have several addresses? Yes. A name can return more than one address, and different clients may use different answers or address families. Do not assume the first row in a DNS table is the only server or a permanent physical location. Record the full relevant answer set when comparing observations.

Is an IP lookup the same operation? No. IP lookup explains an address and its registered network context. DNS resolves a question about a name and type. Neither operation, on its own, tells you who is using a particular device or supplies an exact location for a person.

Does this tool detect my browser's resolver? A normal DNS lookup here asks Google Public DNS through our application server. It does not inspect your browser's configured resolver. Observing which recursive servers handle browser-triggered random names requires a separate measurement method, with its own infrastructure and limitations. Choose the tool whose observation matches your question.