How to Use Online DNS Lookup: A Complete Guide to Domain Resolution Checks

After switching servers, changing domain resolution, or adding a CDN, the first thing many people do is refresh the page to see whether the site loads properly. If the page opens, they assume DNS has taken effect; if it doesn't, they start suspecting the server, the CDN, or the certificate.

In real operations, though, DNS resolution doesn't update for every user nationwide—or worldwide—the moment you make a change. For the same domain, Beijing Telecom may already have the new IP, Guangzhou Mobile may still be using an old cache, and some overseas regions may return a different set of CDN nodes. If you only run a single Ping from your own computer, it's easy to get an incomplete picture. In that case, a more direct approach is to run an online DNS lookup.

By looking at results returned from nodes in different regions and on different carriers, you can see where the domain currently resolves, whether records like A, AAAA, and CNAME are correct, and which regions still haven't picked up the change after a DNS update. For server migrations, CDN switches, email configuration, or troubleshooting resolution issues, this step usually offers more insight than simply refreshing your browser. Today we'll look at how to use online DNS lookup in practice and how to read the results.

1. What Can Online DNS Lookup Check?

When accessing a website, the browser ultimately needs to connect to a server IP, not the domain name you normally see.

For example, a user visits:

www.example.com

Before an HTTP or HTTPS connection can actually be established, the system first needs to use DNS to find the address corresponding to this domain.

The general process can be understood as:

User enters domain
      ↓
Local cache / recursive DNS
      ↓
Authoritative DNS
      ↓
Returns A, AAAA, CNAME, etc. records
      ↓
Obtains server or CDN node address
      ↓
Establishes network connection
      ↓
Accesses website

What an online DNS lookup tool does is essentially initiate a DNS query from a specified test node and then display the resolution records it currently receives. Unlike running nslookup once on your own computer, multi-node DNS lookup lets you observe resolution results from different regions, making it easier to spot regional caching, routing resolution, or CDN scheduling issues.

Common lookup needs in daily work include:

• Checking which IPv4 or IPv6 address a domain currently resolves to;

• Verifying whether a DNS change has taken effect;

• Checking whether a CDN's CNAME is configured correctly;

• Determining whether resolution results are consistent across provinces and carriers;

• Checking MX, TXT, and other records for email and domain verification;

• Determining whether affected regions are still using an old IP.

So online DNS lookup isn't just about "checking an IP." Its real value lies in using results from different locations to judge whether the current DNS state matches expectations.

2. How to Use Online DNS Lookup

Online DNS lookup isn't complicated to operate. Here we'll use Chahu's DNS lookup feature as an example:

If you're just troubleshooting ordinary website resolution, you can usually complete it by following these steps: enter the domain, select the record type, and view results from different nodes.

1. Enter the domain to look up

Open Chahu and go to the DNS lookup page. First, enter the domain you want to check, for example:

www.example.com

Note that DNS lookup targets a domain, not a specific web page path.

For example, this format is suitable for lookup:

www.example.com

but not:

https://www.example.com/product/page.html

because /product/page.html is an internal URL path of the website, not something DNS resolves.

If a website uses all of these:

example.com
www.example.com
api.example.com

then these domains may also have completely different resolution records configured. When troubleshooting, it's best to look them up separately rather than assuming that a working root domain means all subdomains are fine.

2. Select the DNS record type to look up

DNS isn't limited to the single record type of "domain maps to IP." Different records serve different purposes. When a website has access issues, the first thing to confirm is which type you should actually check.

If you just want to know which server a website currently points to, start with the A record; if the site uses a CDN, also pay close attention to the CNAME; if the site has enabled IPv6 and some users report they can't access it, you should also check the AAAA record; if corporate email verification fails, you usually need to check MX and TXT. Determining the record type first and then reading the results will make troubleshooting much more efficient.

3. How to Read A, AAAA, CNAME, MX, and TXT Records

Different DNS records return different content, and the way you judge them shouldn't be mixed together.

1. A record: check whether IPv4 is correct

The A record is the type most commonly checked in daily website operations.

For example, a lookup result shows:

www.example.com
203.0.113.20

If 203.0.113.20 happens to be the new server IP you just switched to, it means this DNS lookup node has already received the new record; if it still returns the old IP, you need to keep checking: whether the authoritative DNS has been updated; whether the TTL has not yet expired; whether the current recursive DNS still holds an old cache. Seeing a single IP by itself doesn't mean much—the key is knowing whether it's the IP you expect.

2. AAAA record: check IPv6

AAAA works similarly to A, except it returns an IPv6 address.

For example:

2001:db8::10

Some websites run into this: IPv4 access works perfectly, but after enabling IPv6, some mobile networks or IPv6-capable users have access issues. In that case, check whether AAAA still points to an old server, a wrong server, or an IPv6 address that is no longer valid. If the website doesn't deploy IPv6 at all but an AAAA record unexpectedly exists, that's also worth checking closely.

3. CNAME: focus on CDN and third-party services

After adding a CDN, CNAME is often used.

For example:

www.example.com
        ↓
example.cdn-provider.net
        ↓
203.0.113.30
203.0.113.31

At this point, don't just stare at the final IP. First confirm: whether the CNAME points to the CDN address you're currently using. If you've already switched from an old CDN to a new one but the lookup result still returns the old CNAME, the problem is very likely still at the DNS resolution layer. If the CNAME is correct but different regions ultimately return different IPs, that isn't necessarily a problem either. Many CDNs return different edge nodes based on the user's region, carrier, and network conditions—that's normal scheduling behavior.

4. MX: check corporate email resolution

MX records are mainly used for email.

For example, after migrating corporate email, you often run into issues like: emails not being received; domain verification failing; the old mail service still receiving some messages. In that case, look up MX to see whether it already points to the new mail server. Also pay attention to MX record priority. Usually, the smaller the number, the higher the priority. For example:

10 mx1.example.com
20 mx2.example.com

Mail servers will usually try mx1.example.com first.

5. TXT: check SPF, DKIM, DMARC, and domain verification

TXT records themselves have many uses.

Common ones include:

• SPF;

• DKIM;

• DMARC;

• Google Search Console verification;

• SaaS platform domain ownership verification;

• SSL DNS verification.

If a third-party platform keeps saying "verification failed," don't just keep clicking the verify button. First look up the TXT record to confirm whether the record has actually been published to DNS. This is especially important for longer SPF or DKIM content—watch for missing characters, duplicate records, or incorrect hostnames.

4. How to Read DNS Lookup Results

Once you have the lookup results, it's best to judge them in a fixed order rather than immediately concluding there's a DNS failure just because one node looks different.

1. First check whether the returned address is the expected result

This is the most basic step.

For example, you just migrated your website to:

203.0.113.20

Most nodes already return the new address, while a few still return:

192.0.2.10

Right away you can tell that old and new resolution results currently coexist.

Next, determine whether this is normal caching or a problem with the resolution configuration itself.

2. Then check whether the anomalies are concentrated in a certain region or carrier

If most regions nationwide are normal and only a few nodes still use the old IP, DNS caching is usually the first thing to consider.

But if you see:

Telecom: all normal
Unicom: all normal
Mobile: many anomalies

then it's worth checking further:

• Smart DNS mobile line configuration;

• Carrier recursive DNS caching;

• Whether a specific line has different records configured;

• Whether there is a regional DNS anomaly.

In this kind of situation, the value of multi-node results becomes clear.

3. Check TTL

TTL is a very important parameter when judging how long DNS changes take to take effect.

For example:

TTL = 600

600 seconds is 10 minutes.

Simply put, after a recursive DNS receives this record, it can continue using the cache within the TTL period without querying the authoritative DNS again on every access.

So generally speaking, the shorter the TTL, the faster the resolution can switch; the longer the TTL, the longer the cache is retained.

But there is a commonly overlooked issue here:

Lowering the TTL now will not immediately invalidate old records that have already been cached.

For example, the original TTL is:

3600 seconds

A recursive DNS server has just cached the old IP.

At this point you change the TTL to:

300 seconds

The previous cache may still persist according to the original TTL until it expires on its own.

So when preparing to migrate servers or switch CDNs, the safer approach is to lower the TTL in advance rather than adjusting it on the day of the switch.

4. Check whether the CNAME chain is correct

CDN users in particular should pay attention to this item.

For example, the expected configuration should be:

www.example.com
        ↓
new-cdn.example.net

But the query still shows:

www.example.com
        ↓
old-cdn.example.net

This clearly indicates that the CDN switch has not yet fully propagated to the current query node. If the CNAME is already correct, you can continue checking the final returned IP, and then use Ping, HTTP, or website speed test to determine whether the actual node is working properly.

5. Check for NXDOMAIN, SERVFAIL, or timeouts

DNS queries do not only produce two outcomes: "has IP" and "no IP."

Other common anomalies include:

For example, if an A record query returns No Answer, it does not necessarily mean the domain does not exist; it could also mean the domain only has a CNAME or AAAA record. When encountering an abnormal status, do not just look at the red warning; you should also consider the query record type and domain configuration together.

5. After changing DNS, how do you determine whether resolution has fully taken effect?

When actually migrating a website, you can troubleshoot in the following order.

Step 1: Confirm that the authoritative DNS is already returning the new record

If the authoritative DNS itself is still returning the old IP, then the problem is clearly not caching but the resolution configuration itself.

At this point, you should first go back to the DNS management console and check:

• Whether the host record was entered incorrectly;

• Whether the A or CNAME record was modified successfully;

• Whether duplicate records exist;

• Whether the wrong domain was modified;

• Whether the NS still points to the current DNS provider.

Step 2: Query resolution results from different regions

Once the authoritative DNS is correct, look at different regions. Focus on: the proportion of new IPs; whether old IPs still exist; whether anomalies are concentrated with a particular ISP; and whether there are obvious differences between domestic and overseas results.

Step 3: Compare TTL

If only a few nodes are still using old records and the modification time has not yet exceeded the previously set TTL, you can observe for a while; if it has clearly exceeded the TTL and many regions still have not updated, you need to continue investigating the DNS provider, recursive DNS, or configuration issues.

Step 4: Check the website itself

Once DNS resolution is correct in all regions, DNS troubleshooting should actually stop for the time being. If the website still cannot be opened, the next step should be to check: whether TCP can connect; whether ports 80 / 443 are open; whether the SSL certificate is correct; whether the HTTP status code is normal; and whether the CDN can properly fetch from the origin.

A practical troubleshooting path is:

Modify DNS
    ↓
Check authoritative DNS
    ↓
Does it return the new record?
    ↓
   Yes
    ↓
Multi-region DNS query
    ↓
Is resolution basically consistent?
    ↓
   Yes
    ↓
Check Ping / TCP / HTTP / SSL

This way, you will not continue wasting time repeatedly checking resolution when DNS is already normal.

6. What real-world problems can online DNS queries help troubleshoot?

DNS queries are best suited for "first determining whether the problem is at the resolution layer." The following scenarios are all common in actual operations.

1. After changing servers, some users still access the old website

This is the most typical DNS caching problem: you can first query the A record to see whether different regions return the new IP or the old IP. If the vast majority of regions have already switched and only a few still retain the old address, you can usually use the TTL to determine whether it is still within a normal caching period. When migrating servers, do not shut down the old server immediately after the DNS change is completed; keep a transition period to avoid direct access failures for users who still receive the old resolution.

2. After integrating a CDN, some regions do not go through the CDN

In this case, first check the CNAME.

Confirm:

Business domain
↓
CDN CNAME
↓
CDN edge node

whether the entire resolution chain is correct.

After DNS is normal, combine Ping or website speed test results to check the nodes actually accessed in different regions.

In CDN scenarios, it is not surprising for different regions to return different IPs. Users in Beijing, Guangzhou, Singapore, or even the United States may all be scheduled to different edge nodes, which is usually exactly how a CDN normally works.

3. IPv4 is normal, but some users cannot open the website

Pay special attention to AAAA for this kind of problem. If the website has an incorrect IPv6 resolution, some users who support IPv6 may try IPv6 first and end up connecting to the wrong address, while IPv4 users are completely fine. When troubleshooting "only some networks cannot open it," do not only check A; you should also check AAAA while you are at it.

4. Corporate email suddenly cannot receive messages

Email problems are often related to DNS in addition to the server itself.

You can check in sequence:

MX
TXT / SPF
DKIM
DMARC

Especially after corporate email migration, changing the domain's DNS provider, or modifying MX, if old records have not fully updated, some emails may still be delivered to the old server.

5. SSL certificate application or automatic validation fails

Some SSL certificate validations rely on DNS.

At this point, you can check: whether the TXT is correct; whether the CNAME validation record exists; and whether CAA allows the corresponding CA to issue the certificate.

If the validation record has clearly been added in the console but the certificate platform keeps saying it cannot be found, you can first use an online DNS query to confirm whether the record is truly publicly visible.

7. What is the difference between online DNS queries and nslookup or dig?

There is no issue of online tools necessarily being more professional than command-line tools; they suit different scenarios.

For example, running locally:

nslookup www.example.com

What you mainly see is: what result your current network environment obtained through the current DNS server. A multi-node online DNS query focuses more on: what results users in different regions can currently obtain. The two do not conflict. In actual troubleshooting, you often first use online tools to see the overall situation, then use dig or nslookup to dig deeper into specific anomalies.

8. The correct troubleshooting order when website DNS has issues

If you do not often deal with DNS problems, you can simply remember this order:

① Query A / AAAA / CNAME
        ↓
② Confirm whether authoritative DNS is correct
        ↓
③ Check different domestic regions and ISPs
        ↓
④ If you have overseas business, check global nodes
        ↓
⑤ Compare old and new IPs and TTL
        ↓
⑥ After DNS is normal, continue checking Ping / TCP / HTTP / SSL

If an anomaly is found in the first or second step, prioritize checking the DNS configuration: if the authoritative DNS is normal but only a few regions have not updated, focus on TTL and recursive DNS caching; if resolution is already correct for most nodes nationwide or even globally but the website still cannot be accessed, you should promptly shift the troubleshooting direction to the server, CDN, network connection, or HTTP service. This allows you to quickly determine which layer the problem is at, rather than guessing back and forth among the server, CDN, and DNS.

Domain resolution is essentially a relay race of global nodes synchronizing information. Once you understand how it takes effect, many seemingly unsolvable access anomalies actually have traces to follow. Whether it is a newly launched project or routine operations inspection, developing the habit of "check resolution first, then test connectivity, and finally look at the business" can make you much more composed when handling failures. It is recommended to bookmark the Chahu multi-node query tool. When resolution is uncertain or cross-region access is slow, take a moment to check it, and it will often help you avoid many hidden network pitfalls.

Related Q&A

1. What is the difference between a "node" and a "DNS server" in a DNS query tool? How should I choose?

A node is the location from which the query is initiated, while the DNS server is who it asks. For domestic business, choose Beijing, Shanghai, Guangzhou, and the three major ISPs; if you have overseas users, add the US West, Europe, and Southeast Asia. To simulate different public DNS servers, choose 8.8.8.8, 1.1.1.1, and ISP DNS respectively to compare differences.

2. If the TTL of a DNS record is 0, does that mean it takes effect globally immediately after modification?

Not necessarily. TTL 0 only tells recursive servers to avoid caching as much as possible, but many resolvers still cache briefly, and clients, systems, browsers, and DoH may also keep a layer. If it still has not updated with TTL 0, clear the local cache first, then wait a few minutes and check multi-region results.

3. When checking MX records, should I enter example.com or mail.example.com?

If the email address is user@example.com, query the MX for example.com, not mail.example.com. Many tools default to querying A, so you need to manually switch to MX. If the root domain has no MX, email may go through another domain or the configuration may be missing.

4. If a domain uses wildcard resolution, what will an online DNS query show?

Query a subdomain that clearly does not exist, such as test123.example.com. If it also returns the same A or CNAME, it is basically wildcard resolution. When checking, do not only test www; try several random subdomains. CDN wildcard resolution may also return different nodes.

5. An online lookup shows the record resolves, but my own computer still can't open the site. What's going on?

Don't blame DNS right away. Check the local hosts file, the system cache, any proxy or VPN, the firewall, and whether the browser has DoH enabled. Try again on a phone hotspot or with 1.1.1.1 set as the resolver. If it works, the problem is most likely on your machine or local network, not a failure of the domain to resolve.