Domain unreachable after switching to CURIAWEB: Causes and solutions

Have you connected an existing domain to your CURIAWEB hosting or switched the nameservers to CURIAWEB, and now the website is unreachable? In this case, you shouldn't just wait for DNS propagation.

Following a domain change, several components must work together: the domain must use the correct nameservers or DNS records, the DNS zone must be complete, and the domain must be correctly configured in the CURIAWEB hosting environment.

Briefly explained: If a domain does not work after switching to CURIAWEB, first check the nameservers and DNS, and then the domain assignment in the hosting. An incorrect configuration will not automatically become correct by waiting longer.

What was actually changed on the domain? #

Before you begin troubleshooting, you should know what kind of conversion was made.

An existing domain can generally be connected to CURIAWEB in different ways:

• The nameservers have been completely changed to CURIAWEB.
• The previous nameservers remain in place and only individual DNS entries have been changed to CURIAWEB.
• The domain was additionally transferred to CURIAWEB.

These processes are not technically the same.

If you only want to use CURIAWEB Hosting, for example, a domain transfer is not required. We explain the various options at Keep domain with another registrar and connect to CURIAWEB Hosting.

First, check the current nameservers #

If all DNS management is to be done via CURIAWEB, the designated CURIAWEB nameservers must be configured for the domain:

ns1.curiaweb.ch
ns2.curiaweb.ch

With the CURIAWEB DNS-Check can you check which DNS information for your domain is currently publicly visible.

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

What does it mean if the old nameservers are still displayed? #

If the nameservers were just changed, the switch may not be visible everywhere yet.

However, if the nameservers of your previous provider continue to be displayed permanently, you should check with your registrar to see if the change was actually saved or executed.

The nameservers are configured during domain registration or with the responsible registrar. A change within CURIAWEB Hosting alone does not replace this delegation.

Important: If you have not changed the nameservers at the registrar, the previous DNS zone remains authoritative. Changes to another, non-authoritative DNS zone will then have no effect on public DNS queries.

The CURIAWEB name servers are active, but the website still isn't working #

The correct nameservers alone are not enough.

The DNS zone provided via these nameservers must also contain the correct entries. For a website, A, AAAA, and CNAME entries are particularly relevant.

The domain must point to the infrastructure designated for your hosting account.

We explain which DNS record types have which task at DNS Records Explained: A, AAAA, CNAME, MX, TXT, and CAA.

Why is the old DNS zone so important? #

When changing the nameservers, the DNS zone of the previous provider is not automatically transferred to CURIAWEB.

This is one of the most significant potential sources of error during a nameserver migration.

The previous DNS zone can contain, in addition to the entry for the website, for example:

• MX records for email,
• SPF, DKIM, and DMARC records,
• Subdomains,
• Verification TXT entries,
• CNAME records for external services,
• or further individual DNS configurations.

If such entries are missing from the new DNS zone, the corresponding services may fail after the nameserver change.

Practical Tip: Before changing a nameserver, the existing DNS configuration should be documented and the new zone prepared. Only change the nameserver once the required DNS records exist at the new destination.

How do I check the current DNS records? #

With the CURIAWEB DNS-Check You can check the publicly visible DNS configuration.

You can find a more detailed explanation at Check DNS records: View current DNS configuration of a domain.

Be sure to compare not only the nameservers but also the A, AAAA, CNAME, MX, and TXT records relevant to your services.

The domain points to CURIAWEB – is it also set up in the hosting? #

DNS ensures that a request is routed to the correct server infrastructure. The web server must then know which website to serve for the requested domain.

Even if the domain points to the correct server, but is not set up correctly in the hosting account, the website still cannot function as expected.

Briefly explained: DNS answers the question „Which server should the request go to?“ Hosting must then be able to answer: „Which website belongs to this domain?“

Also check the www version of the domain #

The main domain and its www-Variants are hostnames that differ technically:

example.ch
www.example.ch

If only one of the two options works, you should check the DNS and hosting configuration for the option that isn't working.

Depending on the configuration, www for example, connected to the main domain via a CNAME.

The old website is still displayed #

If the website of the previous host still appears after the changeover, the domain or a used hostname may still be pointing to the old infrastructure.

In addition, following a recent DNS change, different resolvers may temporarily return different answers.

Therefore, first check the currently visible DNS entries and compare them with the intended CURIAWEB configuration.

If the public DNS data already clearly points to the new infrastructure, a browser, proxy, or website cache may also be involved.

Why isn't the domain working for me, but it is for someone else? #

After a DNS change, different DNS resolvers may temporarily use different cached information.

Therefore, it can happen that the domain already works with the new configuration over one internet connection, while another connection is still using older DNS information.

We explain the technical background at What is DNS propagation and why does a DNS change take time?.

Important: If the domain delivers the same incorrect DNS configuration everywhere, „propagation“ is probably not the solution. Then check the actually stored values.

The website works over HTTP, but not over HTTPS #

Then basic domain resolution may already be working while the HTTPS configuration is not yet correct.

For HTTPS, a valid SSL/TLS certificate for the domain name used must be present in the hosting environment.

If the domain previously pointed to a different server, the issuance or validation of a certificate in the new environment can only work after the domain correctly points to this infrastructure.

Also check both the main domain and the used www-Variant.

The browser is showing a certificate warning #

A certificate warning does not automatically mean that DNS is not working.

If the browser already reaches a web server whose certificate does not match the requested domain name, the problem is more likely related to the SSL/TLS or hosting configuration.

DNS, web server, and SSL should therefore be checked separately.

The website works, but email no longer does #

This is a particularly critical error scenario after changing nameservers.

If the website is reachable, it only means that the configuration required for the website is working. Email uses its own DNS records.

MX records are particularly relevant for receiving mail. In addition, SPF, DKIM, and DMARC may be required for sending and authentication.

If external email services were used before the nameserver change and their DNS records were not transferred to the new zone, the website may work while email fails.

What do I need to keep in mind with SpamExperts? #

If your domain uses SpamExperts Incoming Filtering, the designated MX records must be correctly in place.

SpamExperts first receives incoming messages, filters them, and then forwards them to the actual destination mail server.

We explain the MX configuration at SpamExperts Incoming Filtering and MX Configuration.

Important: The SpamExperts MX servers are not IMAP or POP3 servers. To access your mailbox, continue using the mail server settings designated for your email account.

What about SPF, DKIM, and DMARC? #

When completely changing the nameserver, it must also be checked whether the required email authentication records are present in the new DNS zone.

A missing SPF, DKIM, or DMARC record does not necessarily mean the website is inaccessible. However, it can affect email delivery or message authentication.

You can find more information at SPF, DKIM, and DMARC in Hosting.

I only changed the A-Record – do I need the CURIAWEB nameservers? #

No.

If you intentionally keep the existing nameservers and merely connect the website to CURIAWEB via a DNS record, the CURIAWEB nameservers do not need to be entered.

In this case, the previous DNS provider remains authoritative and you change the required A, AAAA, or CNAME record there, for example.

Use exclusively the specific target values of your CURIAWEB hosting account for this.

Why am I not allowed to change nameservers and individual DNS records at the old provider at the same time? #

If you switch the nameservers completely to CURIAWEB, the CURIAWEB DNS zone becomes authoritative after effective delegation.

DNS records that you subsequently modify exclusively in the old DNS zone will generally no longer affect the public resolution of the domain.

Conversely, as long as the old nameservers are still authoritative, changes in a future CURIAWEB DNS zone will not yet have any public effect.

Note: What is always decisive is the DNS zone on the currently authoritative nameservers.

Can DNSSEC cause issues after changing nameservers? #

Yes.

When DNSSEC is enabled for a domain, the information stored in the parent zone must match the DNSSEC configuration actually in use.

If nameservers are changed without properly taking an existing DNSSEC configuration into account, DNSSEC-validating resolvers may consider the domain's responses to be invalid.

This can lead to the domain appearing to be completely unresolvable for some users.

Attention: If a domain used DNSSEC before the nameserver change, the DNSSEC configuration should be explicitly checked. Do not change DS or DNSSEC data on suspicion.

How do I recognize a potential DNSSEC problem? #

A possible indicator is when a domain cannot be resolved by certain resolvers, even though the authoritative nameservers are basically reachable and the DNS records appear to be correct.

However, for a definitive diagnosis, the DNSSEC chain must be checked. A common browser error alone does not prove a DNSSEC problem.

What happens after a domain transfer to CURIAWEB? #

A domain transfer and a name server change are separate processes.

The transfer of domain management does not automatically mean that website files, databases, or email mailboxes have been transferred.

The DNS configuration should also be checked separately when changing registrars.

We explain the basic procedure under Domain transfer to CURIAWEB: How the transfer works.

Can I change the domain back to the old nameservers? #

Technically, another nameserver change may be possible as long as the old DNS infrastructure is still available and correctly configured.

However, this should not be done reflexively as a first measure.

Frequent nameserver changes in rapid succession complicate diagnosis because resolvers may use different cached delegations or DNS responses.

Practical Tip: If something does not work after a change, do not immediately revert and reapply multiple settings. First, determine which nameservers are currently authoritative and what DNS responses they actually return.

What if only one subdomain is not working? #

If the main domain works, but a subdomain does not, there is probably no fundamental domain registration issue.

Then check the DNS record of the subdomain in question and whether it has been set up correctly on the target system.

For example

example.ch
shop.example.ch
mail.example.ch

different hostnames and can point to different technical destinations.

What if only www does not work? #

Also www.example.ch is its own hostname.

Therefore, check whether for www a matching DNS record exists and whether the hosting configuration takes this variant into account.

The fact that the main domain works does not automatically guarantee a correct www-Configuration.

How can I tell whether the problem lies with the DNS or the web server? #

First, check whether the domain or the affected hostname resolves to the expected target.

If DNS resolution already fails or points to an incorrect destination, you should first examine DNS or the nameservers.

If DNS, on the other hand, delivers the expected destination, but the web service still does not work, further troubleshooting is more likely to lie with hosting, web server, SSL, firewall, or application.

A ping test can provide additional information, but it is not a complete test for a website. We explain the correct interpretation at Perform ping test: Check connection to a domain or server.

What is a logical order for troubleshooting? #

After switching to CURIAWEB, you can perform the diagnostics in this order:

Which nameservers are currently authoritative?
        ↓
Is the correct DNS zone active?
        ↓
Are A / AAAA / CNAME correct?
        ↓
Does the domain point to the intended hosting infrastructure?
        ↓
Is the domain set up in the hosting?
        ↓
Do HTTP and HTTPS work?
        ↓
Are MX and email configuration correct?
        ↓
Are subdomains and external services complete?

When DNSSEC is used, its correct configuration must also be included in the audit.

When should I contact CURIAWEB support? #

If the domain does not work after the switch and you cannot clearly determine the cause, specific technical details will help with the diagnosis.

Please share if possible:

• which domain is affected,
• what was changed,
• when the change was made,
• whether the website, email, or both are affected,
• what error message appears,
• and whether the problem occurs on multiple devices or internet connections.

The more precisely the initial situation is described, the faster it can be determined whether registration, DNS, hosting, SSL, or email is affected.

Summary #

If an existing domain is not accessible after switching to CURIAWEB, you should not automatically just wait for DNS propagation.

First, check which nameservers are actually authoritative. If the entire DNS management is to be handled via CURIAWEB, the designated CURIAWEB nameservers must be active and the new DNS zone must contain all required entries.

If the existing nameservers remain in place, the DNS records required for CURIAWEB must instead be changed with the currently authoritative DNS provider.

If DNS is already pointing to the correct destination, you should then check the domain mapping in your hosting, HTTPS, and, if applicable, the email configuration.

When changing a nameserver, special attention is required for existing MX, SPF, DKIM, DMARC, subdomain, and DNSSEC configurations.

Check the migration systematically from nameserver delegation and DNS to hosting and email. This makes it much more reliable to find the cause than by repeatedly changing various settings.