Check DNS records: View current DNS configuration of a domain

When a website is unreachable, emails fail to arrive, or a DNS change seems to have no effect, checking the current DNS records is one of the most important steps in troubleshooting.

With a DNS query, for example, you can determine which IP address a domain points to, which mail servers are responsible for receiving emails, which name servers are used, or which TXT records are publicly available via DNS.

What is important here is the distinction between the configuration you see in a management interface and the DNS information that can actually be queried publicly at present.

Briefly explained: With a DNS check, you can verify which DNS information is currently publicly visible for a domain. This is particularly helpful after making changes or when experiencing issues with your website and email.

Check DNS records directly with the CURIAWEB DNS check #

For a quick check, you can CURIAWEB DNS-Check use.

Enter the desired domain there and run the DNS query. This allows you to check the currently publicly visible DNS information for the domain.

For example, the DNS check is suitable if you want to check whether:

• a domain points to the expected IP address
• the correct mail servers are entered
• a DNS change is already visible
• the expected nameservers are used
• TXT entries are available
• an existing DNS configuration should be documented before a move

Practical Tip: If you just changed a DNS record, make a note of the old and the new value. This makes it much easier to tell during a subsequent query which version is currently being returned.

What can I find out with a DNS query? #

What information you receive depends on which DNS record type you query.

Among the most important in everyday hosting are A, AAAA, CNAME, MX, TXT, and NS.

If these terms are not yet familiar to you, you can find a detailed explanation at DNS Records Explained: A, AAAA, CNAME, MX, TXT, and CAA.

Check A record: Which IPv4 address is my domain pointing to? #

By querying the A record, you can determine which IPv4 address is returned for a domain or host name.

For example, a query for:

meine-firma.ch

return an IPv4 address according to this scheme:

192.0.2.10

If you want to check whether a website is pointing to the new server after a hosting change, the A-record is one of the first entries you should check.

Important: A correct A record merely proves that the hostname resolves to the expected IPv4 address. It does not prove that the web server, website, or HTTPS are configured correctly.

Check AAAA record: Is there an IPv6 address? #

The AAAA record fulfills a similar function for IPv6 as the A record does for IPv4.

For example, a query can return a value according to this scheme:

2001:db8::10

If you are having trouble reaching a website, checking the AAAA record is particularly worthwhile when both IPv4 and IPv6 are used.

A common mistake is an old AAAA record that still points to a no longer used IPv6 address, while the A record has already been correctly updated.

In this case, access via IPv4 may work, while clients using IPv6 experience issues.

Check CNAME: Where does an alias point? #

A CNAME record points one DNS name to another DNS name.

For example, could:

www.meine-firma.ch

on:

meine-firma.ch

refer.

Therefore, during a CNAME query, you should check whether the returned target name matches the intended configuration.

Note that a CNAME is not a redirect in the browser. It operates at the DNS level.

Check MX records: Which mail servers receive my emails? #

If emails to a domain are not arriving, you should check the MX records.

MX records determine which mail servers should accept emails for a domain.

A domain can have multiple MX records. These additionally contain a priority.

To put it simply, a result could look like this, for example:

10 mx1.example.net.
20 mx2.example.net.

For MX records, the smaller numerical value has the higher preference.

Check in particular whether the returned mail servers actually belong to the email infrastructure you want to use.

Check MX records in SpamExperts #

If your domain is protected by SpamExperts Incoming Filtering, the MX records must point to the designated SpamExperts infrastructure.

The incoming messages are then first checked by SpamExperts and subsequently forwarded to the configured destination mail server.

If emails do not arrive as expected, a DNS query can therefore quickly show whether the MX configuration basically points to the intended infrastructure.

We handle the setup under Set up SpamExperts incoming filtering and configure MX records.

Check TXT records #

TXT records are used for various purposes. These include, among other things, email authentication and domain verification for external services.

Therefore, multiple different entries can be returned with a TXT query.

For example, an SPF record typically starts with:

v=spf1

A DMARC record typically starts with:

v=DMARC1;

With DKIM, a specific selector is also queried.

Therefore, if you control SPF, DKIM, or DMARC, it is not enough to simply determine that some TXT record exists. The crucial factor is whether the correct record is published under the correct name with the expected content.

We explain the three procedures in detail at SPF, DKIM, and DMARC explained with CURIAWEB Hosting.

Check nameservers of a domain #

With an NS query, you can determine which nameservers are delegated for a domain.

If your domain is supposed to use the CURIAWEB nameservers, you expect:

ns1.curiaweb.ch
ns2.curiaweb.ch

If the nameservers of a previous provider are still displayed instead, it should first be checked whether the nameservers were actually changed at the registrar and whether cached DNS information may still be playing a role.

You can find more information at Finding and correctly using CURIAWEB nameservers.

Why do I see a different value in the customer portal than in a DNS query? #

This can have various causes.

A particularly important possibility is that you edited a DNS record in a zone that is not actually used authoritatively for the domain.

Assuming you change the A-record of a domain in a hosting management panel, but the domain still uses the nameservers of another DNS provider.

Then the change can be saved completely correctly in the administration interface without it being relevant for public DNS queries.

Important: In case of unexpected DNS results, first check which nameservers are actually authoritative for the domain. Only then will you know in which DNS zone the active records are managed.

What does „authoritative DNS response“ mean? #

The authoritative name servers provide the authoritative DNS information for the zone they manage.

In addition, there are recursive resolvers that can perform DNS queries for clients and cache results.

Because of this, there can be a difference between the current information on the authoritative nameserver and an older value in a resolver's cache.

How resolvers, authoritative nameservers, and DNS zones work together is explained at DNS simply explained: How the Domain Name System works.

Why do different DNS queries show different results? #

Following a DNS change, different resolvers may temporarily return different information.

One resolver may still have the previous value cached, while another resolver has already performed a new query to the responsible DNS infrastructure.

This is related to, among other things, DNS caching and the TTL of the relevant records.

This behavior is frequently referred to as DNS propagation.

We will cover the background in the next fundamental article under DNS Propagation Explained: Why Changes Can Take Time.

Practical Tip: Different DNS results immediately after a change do not automatically mean that the configuration is wrong. Check the new value, the responsible nameservers, and the TTL before making any further changes.

What is the TTL and why is it important during the exam? #

TTL stands for Time to Live. It determines how long a DNS response may be cached by a resolver.

A TTL of:

3600

corresponds, for example, to one hour.

If a record was queried before the modification, the old value may still be present in a resolver until the corresponding cache entry expires.

A new change to the DNS record does not automatically clear already existing caches on other resolvers.

Check DNS before hosting change #

A DNS query is not only helpful for troubleshooting. It is also great for preparing a hosting migration.

Before changing the DNS configuration of an existing domain, you should document the currently used records.

Of particular relevance are:

• Nameserver
• A and AAAA records
• CNAME Records
• MX records
• SPF
• DKIM
• DMARC
• Verification records of external services
• existing subdomains

With the CURIAWEB DNS-Check can you get an overview of publicly visible DNS information.

Important: A public DNS query is a helpful inventory, but it does not necessarily replace a complete backup of the existing DNS zone. Not every required record can be meaningfully captured by a single general query.

Check DNS after a hosting change #

After a change, you can query the same values again and compare them with the previous configuration.

If the website has been migrated to a new server, you should check, for example, whether A and, if applicable, AAAA records point to the intended destinations.

If the email infrastructure remains unchanged, the required MX and authentication information should still be correctly in place.

This helps avoid a common mistake: the website was successfully migrated, but entries for e-mail or external services were lost during the DNS change.

Check DNS after a nameserver change #

After changing your nameservers, you should first check whether the expected NS records are visible.

If CURIAWEB is to be responsible for the DNS zone, these are:

ns1.curiaweb.ch
ns2.curiaweb.ch

Subsequently, you should check whether the required A, AAAA, MX, TXT, and other records are also correctly returned via the new DNS infrastructure.

A successful nameserver change alone does not automatically mean that the new DNS zone is complete.

The domain points to the correct IP address, but the website is not working #

If the A or AAAA record is correct, troubleshooting should be continued at other levels.

Possible causes can include, for example:

• The domain is not correctly configured on the web server
• The website files are missing or in the wrong location
• the web application causes an error
• the HTTPS or certificate configuration is faulty
• A redirect is incorrectly configured

DNS merely answers the question of which technical destination is published for the queried name. Whether the service reachable there functions correctly is a separate question.

The website works, but emails are not coming through #

In this case, a problem with the website's A-record is rather unlikely.

Check in particular instead:

• the MX records
• the resolution of the mail servers specified in the MX records
• the configuration of the destination mail server
• the intended filter and destination server configuration in SpamExperts

For further troubleshooting, we have the item Emails not arriving: Systematically checking causes created.

The website works for me, but not for someone else #

If the same domain yields different results for different users, a DNS cache can be a potential cause – especially shortly after a change.

Another resolver may still have an older DNS response cached.

However, other causes are also possible, such as local network problems, browser caches, or issues with IPv4 or IPv6.

Therefore, the DNS configuration should not be changed again based solely on this symptom.

Can I also check DNS via the command line? #

Yes. Depending on the operating system, different tools are available for DNS queries.

Frequently used examples include:

nslookup

or on corresponding systems:

dig

This can be used to specifically query certain DNS record types.

A simple query can be made, for example, according to this scheme:

nslookup meine-firma.ch

With suitable options, MX, NS, or other DNS information can also be queried.

The exact syntax varies depending on the tool and operating system.

Why is a DNS check better than speculative changes? #

DNS problems can often be narrowed down relatively specifically if the current state is determined first.

For example, if a website is unreachable, you should first check which IP address is actually being resolved before changing the A record.

In case of email issues, you should first check the currently visible MX records before entering new MX values.

And if a change appears not to have been applied, you should first check the authoritative name servers and possible caches.

Basic rule for DNS problems: Check first, then change. Making multiple changes at the same time makes troubleshooting more difficult and can cause additional problems.

Edit DNS records at CURIAWEB #

If your domain's DNS zone is managed via your CURIAWEB hosting, you can edit DNS records in cPanel via the Zone Editor.

We explain the practical operation at Using the DNS Zone Editor in cPanel.

The zone editor shows the configured zone. You can then use an external DNS query or the DNS check to verify which information is being resolved publicly.

DNS checking and DNS management are not the same #

A DNS check allows you to read DNS information. This does not change anything about your domain.

Changes, on the other hand, are made at the provider or in the DNS management responsible for the authoritative zone of your domain.

The CURIAWEB DNS-Check is therefore a diagnostic tool and not a DNS management interface.

A logical sequence for DNS problems #

If you suspect a DNS problem, you should proceed systematically.

1. Check which nameservers are responsible for the domain.
2. Check the DNS record of the affected service.
3. Compare the result with the desired configuration.
4. Consider TTL and DNS caches for recent changes.
5. Change only the entry whose function and correct target value are known.
6. After the change, check again which information is returned publicly.

This often makes it possible to distinguish whether the problem actually lies with the DNS or whether troubleshooting needs to be continued at the web server, mail server, or the respective application.

Summary #

DNS queries show you which information about a domain can currently be resolved publicly via the Domain Name System.

With the CURIAWEB DNS-Check Can you check the DNS configuration of a domain and, for example, verify whether the expected name servers, IP addresses, mail servers, or TXT records are visible?.

For website issues, A and AAAA records are particularly relevant. For problems with receiving emails, you should check the MX configuration. NS records show you which nameservers are delegated for the domain.

Following changes, DNS caches may temporarily continue to provide older information. Therefore, a differing result should first be analyzed rather than responding with further changes on suspicion.

Therefore, the most important rule in DNS troubleshooting is: first check the current state, then narrow down the cause, and only then make targeted changes.