> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/lookup-privacy/dns-resolver.md).

# DNS Resolver

Resolve a domain through many public DNS providers at once and compare the answers to spot CDN steering, stale caches, or filtering along the path.

## What it does

Every time you open a website, your device asks a DNS resolver to turn the domain name into an IP address. Different resolvers can give different answers.

The **DNS Resolution** tool asks a list of well-known public resolvers the same question at the same time, then shows every answer side by side. You do not need to change any setting on your device. The lookups happen from the IPCheck.ing server, not from your computer.

This is the fastest way to see whether the answer your network gives you matches what the rest of the world sees.

## How to run it

{% stepper %}
{% step %}

### Open the tool

Go to **Advanced Tools** and click the **DNS Resolution** card. It opens in a panel. You can also open it as its own page at `/tools/dnsresolver`.
{% endstep %}

{% step %}

### Pick a record type

The record type is the dropdown on the left of the input box. `A` is selected by default and is the right choice for "which IP does this website use?" — the other types are explained at the bottom of this page.
{% endstep %}

{% step %}

### Enter a domain

Type a domain name or paste a full URL into the box. A URL works fine, because the tool takes the host name out of it. Press Enter, or click the play button.
{% endstep %}
{% endstepper %}

## Reading your results

Results appear in a two-column table — **DNS Provider** and **Resolution Result** — with a flag beside each provider showing which country it is based in.

Above the table is a row of region tags: **All Regions**, plus one for every country present in the results. Tap one to show only that country's resolvers. This is the quickest way to tell whether a disagreement follows a whole region or just one provider.

Each provider name carries a tag:

| Tag        | Meaning                                                                |
| ---------- | ---------------------------------------------------------------------- |
| `(DNS)`    | Queried over plain DNS, the traditional unencrypted protocol.          |
| `(DoH 🔒)` | Queried over DNS-over-HTTPS, an encrypted version of the same request. |

Some providers are queried over both protocols, so the same name can appear twice with different tags. Comparing those two rows is worth a moment on its own: they are the same question asked over an unencrypted and an encrypted channel.

`N/A` means that provider returned nothing. Either no record of that type exists, or the provider was unreachable from the server, or the request timed out. A single `N/A` is not a problem on its own.

Asking for `SOA` on a name below the top of the zone — `www.example.com` rather than `example.com` — is one case worth knowing about: the DoH rows fall back to the zone's own record while the plain-DNS rows may show `N/A`. That is a difference between the two protocols, not a fault.

Answers that are themselves names always end in a trailing dot, which is the standard way of writing a fully-qualified name. Both rows a provider contributes are written the same way, so a visible difference in the text is a real difference in the answer.

### Why answers can differ, and why that is often normal

Different answers are common and usually harmless:

* **CDNs.** Large sites are served from many data centres. A resolver in Europe and a resolver in Asia get pointed at different edge servers.
* **Geo-DNS.** Some services answer with a different IP depending on where the question came from.
* **Load balancing.** A domain can have several IPs and hand them out in rotation, so two lookups a second apart can differ.
* **Caching.** A resolver may still be serving an older answer until its cache expires.

See [How DNS Works](/knowledge-base/concepts/how-dns-works.md) for the background.

### When a difference is suspicious

{% hint style="warning" %}
Not every disagreement is innocent. An answer can be filtered or rewritten anywhere along the path between a resolver and you — by a network operator, by equipment in between, or by the resolver itself. Querying resolvers in many countries at once is what makes that visible: tampering tends to show up as a disagreement confined to one region, while CDN steering shows up as many small, plausible differences.
{% endhint %}

Patterns worth a second look:

* Most providers agree on one set of IPs, and one or two return something completely different.
* A provider returns a private or reserved address (something starting with `10.`, `192.168.`, or `127.`) for a public website.
* A provider returns an address that belongs to an unrelated network or country.

If you see one of these patterns, check what your own device is doing. It may be getting the same wrong answer.

<details>

<summary>Which record type should I choose?</summary>

* **A** — the IPv4 address of a website. Start here.
* **AAAA** — the IPv6 address of a website.
* **CNAME** — an alias pointing to another name. Common for sites behind a CDN.
* **MX** — the mail servers that receive email for the domain.
* **NS** — the authoritative name servers for the domain.
* **TXT** — free-form text records, used for domain verification and email rules such as SPF, DMARC and DKIM.
* **SOA** — the "start of authority" record: which name server is the master copy for the zone, the contact address, and the timers other servers use to refresh from it.
* **CAA** — which certificate authorities are allowed to issue certificates for the domain.

</details>

<details>

<summary>Checking email records: SPF, DMARC and DKIM</summary>

All three are `TXT` records, and all three are worth confirming that the whole world sees the same value — a stale or filtered answer is a common reason mail suddenly starts failing.

* **SPF** — choose `TXT` and enter the domain itself, such as `example.com`. Look for the value starting `v=spf1`.
* **DMARC** — choose `TXT` and enter `_dmarc.example.com`. Look for `v=DMARC1`.
* **DKIM** — choose `TXT` and enter `<selector>._domainkey.example.com`. The selector is chosen by whoever sends your mail; it appears in the `s=` field of a `DKIM-Signature` header on a message you have already sent.

Names beginning with an underscore are ordinary DNS names, and the tool accepts them.

</details>

## What to do next

* Suspect your own resolver is the problem? Work through [Is My DNS Hijacked or Polluted?](/knowledge-base/diagnose/is-my-dns-hijacked.md).
* Want to know which resolvers your device actually uses? Run the [DNS Leak Test](/knowledge-base/connection-tools/dns-leak-test.md).
* A site will not open at all? Start with [Can't Open a Website?](/knowledge-base/diagnose/cant-open-a-website.md).
* Curious who owns an IP that came back? Look it up with [Whois Search](/knowledge-base/lookup-privacy/whois-search.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/lookup-privacy/dns-resolver.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
