When a Website “Disappears”: Understanding DNS, Cloudflare and a .SE Registry Hold

A real-world troubleshooting case study involving Cloudflare, DNS resolution, SSL verification, registry-level domain holds and external diagnostic tools.

There are few moments more unsettling for a business owner than opening a browser and seeing:

ERR_NAME_NOT_RESOLVED

No warning.
No obvious cause.
Yesterday the website worked. Today it appears to have vanished from the internet completely.

That is exactly what happened during troubleshooting of a Swedish .se domain registered through Netim, hosted on Hostinger and routed through Cloudflare.

At first glance, it looked like a typical DNS, SSL or Cloudflare configuration problem. It wasn’t.

The real cause sat several layers higher — at registry level.

The Symptoms

The website began showing several different behaviours:

• Cloudflare “Verifying you are not a robot” screen
• 502 Bad Gateway
• ERR_NAME_NOT_RESOLVED
• DNS lookups returning:

  Non-existent domain
  

From the outside, these errors can appear unrelated. In reality, they were all clues pointing to different layers of the same problem.

Understanding the Website Stack

Modern websites are usually made up of several layers:

In this case:

When a website fails, the key is not just fixing settings at random. The key is identifying which layer is actually failing.

First Suspicions: Cloudflare and DNS

The first step was to inspect the DNS configuration inside Cloudflare.

Wildcard DNS Records

A wildcard DNS record was present. This type of record sends every possible subdomain through the configured destination.

A    *    45.84.207.9

Wildcard records are not always wrong, but they can cause confusion. They may send unwanted bot traffic through the site, trigger security systems unnecessarily and make troubleshooting harder.

The wildcard record was removed.

Incorrect FTP Proxying

An FTP record was also being proxied through Cloudflare.

CNAME    ftp    malindas.se    Proxied

Cloudflare does not proxy FTP traffic in the normal web proxy. FTP records should normally be set to DNS only.

SSL/TLS Mode

Cloudflare SSL/TLS mode was checked. The recommended setting for this kind of setup is:

Full (strict)

This ensures:

• HTTPS from the visitor to Cloudflare
• HTTPS from Cloudflare to the hosting server
• Certificate validation between Cloudflare and the origin server

Important: Cloudflare’s Flexible SSL mode can cause redirect loops, mixed HTTPS behaviour and confusing failures. For a properly configured hosting account with SSL installed, use Full (strict).

The Critical Clue: NXDOMAIN

After checking the visible Cloudflare configuration, the domain still failed. The decisive test was a nameserver lookup:

nslookup -type=ns malindas.se

The result was:

*** can't find malindas.se: Non-existent domain

This changed the diagnosis completely.

A hosting problem does not normally produce this result. A Cloudflare SSL problem does not normally produce this result either.

NXDOMAIN means the domain is not currently being published properly in DNS.

The Real Cause: Registry-Level serverHold

The registrar later confirmed that the domain had been placed on serverHold by the Swedish .se registry.

This is a registry-level block. It sits above Cloudflare, above Hostinger and above the DNS records visible in the Cloudflare dashboard.

A serverHold status means:

• The domain still exists
• The registration can still be active
• But the registry refuses to publish DNS for the domain

In practical terms, the website disappears from the internet until the hold is removed.

Why Registries Apply serverHold

Domain registries may apply a hold when they cannot verify the registrant information associated with a domain.

For a company-owned domain, this can include checking:

• Legal company name
• Organisation number
• Country
• Company registration status
• Registrar-held registrant data

In this case, the registrar requested proof of incorporation for the company associated with the domain. Once the required documentation was supplied and verified, the hold was removed.

How the Domain Was Checked After Unblocking

Once the domain was unblocked, DNS began resolving again. A normal lookup returned Cloudflare edge IPs:

nslookup malindas.se

Name:    malindas.se
Addresses:  2a06:98c1:3120::5
            2a06:98c1:3121::5
            188.114.96.5
            188.114.97.5

This confirmed that Cloudflare was active and proxying the domain correctly.

Healthy Cloudflare Configuration

After recovery, the recommended Cloudflare DNS setup was kept simple:

Recommended Cloudflare settings:

• SSL/TLS: Full (strict)
• Always Use HTTPS: Enabled
• Automatic HTTPS Rewrites: Enabled
• Bot Fight Mode: Disabled unless specifically needed
• Wildcard DNS: Avoid unless there is a clear reason

Useful Diagnostic Tools

During troubleshooting, several external tools were used to verify DNS, SSL and domain health.

These tools are extremely useful when diagnosing website and domain problems.

Together, these tools provide visibility into different layers of a website stack: DNS, SSL, registry status, indexing and global accessibility.

How to Check if a Domain Has This Problem

If a domain appears to have disappeared, run these checks.

Check basic resolution

nslookup example.se

Check nameservers

nslookup -type=ns example.se

Check domain status

Use your registrar’s control panel or a WHOIS/RDAP lookup to check for statuses such as:

• serverHold
• clientHold
• pendingDelete
• expired

If serverHold is present, DNS troubleshooting will not fix the problem. The hold must be removed by the registry or registrar process.

Final Recovery Checklist

Once the domain is restored:

• Verify nameservers are correct
• Confirm Cloudflare SSL mode is set to Full (strict)
• Remove unnecessary wildcard DNS entries
• Ensure www redirects correctly
• Check the SSL certificate rating
• Verify the website resolves globally
• Confirm registrant information matches company records
• Ensure website footer/company information matches registry data

Lessons Learned

• Do not assume every outage is a hosting issue.
• Check DNS resolution before changing Cloudflare settings.
• Check nameserver delegation if DNS fails completely.
• Look for registry statuses such as serverHold.
• Keep registrant information accurate and consistent.
• Make sure company details match across registrar, registry, website footer and official company records.
• Use Cloudflare Full (strict) SSL mode.
• Avoid unnecessary wildcard DNS records.

Final Thoughts

This incident looked like a Cloudflare problem, then a DNS problem, then a hosting problem.

In the end, it was an administrative verification issue at registry level.

That is the important lesson: not every website outage is caused by the website.

Sometimes the domain itself is blocked from being published. When that happens, the only real fix is to satisfy the registry’s verification requirements and have the hold removed.

Once the registry hold was lifted, DNS began resolving again and Cloudflare resumed normal operation.

This case study is intended as a practical explanation of domain troubleshooting across registrar, DNS, CDN and hosting layers.