Domän aktiv, sajt nere? Felsök DNS, namnservrar, webbhotell

If your domain shows Active but the website does not load, the domain registration itself may be fine while another layer is failing.

A working website normally depends on several separate components:

Domain registration → Nameservers → DNS records → Hosting server → Website configuration → HTTPS/SSL

A problem in any one of those layers can make the website unavailable.

Start by checking:

1. the domain has not expired and has no DNS-blocking status;
2. the correct nameservers are delegated;
3. you are editing DNS at the provider that actually hosts the authoritative DNS;
4. the root domain and www point to the correct website;
5. the hosting server is online and configured for the domain;
6. SSL, redirects, DNSSEC, or local DNS caching are not causing the failure.

Do not simply wait 24-48 hours for “DNS propagation” until you first confirm that the authoritative DNS configuration is correct. Waiting does not fix an incorrect nameserver, wrong IP address, missing record, domain Hold, DNSSEC failure, or offline server.

If your domain is registered at NiceNIC, start with the NiceNIC domain and DNS troubleshooting resources.

Quick Diagnosis: What Does the Error Usually Point To?

The fastest fix comes from identifying the layer before changing settings.

First: What Does "Domain Active" Actually Mean?

This is one of the biggest sources of confusion.

A domain showing Active in a registrar account usually means the registration exists and is being managed as an active product in that system.

It does not automatically prove that:

• the domain is delegated correctly in DNS;
• the authoritative nameservers respond;
• the A record is correct;
• the hosting server is online;
• the website has been installed;
• the SSL certificate works;
• DNSSEC is valid;
• www is configured;
• your application is healthy.

Also distinguish an account status such as Active from formal EPP/RDAP domain status codes.

ICANN maintains official EPP domain status codes, which can reveal restrictions such as clientHold or serverHold.

So:

"Active domain" and "working website" are not the same condition.

How a Website Actually Loads

Understanding the request path makes troubleshooting much easier.

When somebody enters:

example.com

in a browser, a simplified process looks like this:

1. the domain must still be registered;
2. the registry must delegate it to nameservers;
3. the authoritative nameservers must respond;
4. DNS must return the correct website destination;
5. the hosting server must accept the connection;
6. the server must recognize the domain;
7. the website or application must return content;
8. HTTPS must work if the browser uses SSL/TLS.

If any step fails, the website may appear down.

That means the correct troubleshooting question is not:

"Is the domain active?"

It is:

"At which step does the request stop working?"

Step 1: Check Domain Expiration and Domain Status

Before touching DNS or hosting, confirm the domain itself is healthy.

Check:

• expiration date;
• current registrar status;
• EPP/RDAP status;
• whether a Hold is present.

NiceNIC provides a domain status code guide explaining common statuses.

clientHold

clientHold is normally set by the registrar.

ICANN’s status guidance explains that a domain with this status is not activated in DNS.

In practical terms, the domain may stop resolving even though the registration still exists.

If you see clientHold:

1. check the registrar account;
2. review notices or required actions;
3. identify the specific reason;
4. follow the applicable recovery process.

Do not try to fix clientHold by changing your hosting server.

serverHold

serverHold is set at the registry level.

It can also prevent the domain from resolving.

Because the registry controls the status, the registrar may need to investigate or coordinate with the registry rather than simply remove the status directly.

NiceNIC explains the difference in ClientHold and ServerHold Explained.

Important

clientTransferProhibited is different.

That status normally blocks transfer.

It does not by itself mean the website should stop resolving.

Do not assume every “Prohibited” status causes downtime.

Step 2: Check Which Nameservers Are Actually Active

A domain does not use DNS records from every control panel where you can type them.

It uses records from its authoritative DNS provider.

The authoritative provider is determined by the domain’s active nameserver delegation.

For example:

Registrar

NiceNIC

Nameservers

alice.ns.cloudflare.com bob.ns.cloudflare.com

Active DNS provider

Cloudflare

In that setup, changing A or MX records inside an unrelated DNS panel will not change the live DNS.

Cloudflare’s current documentation defines authoritative nameservers as the servers that hold the definitive DNS records for a domain and provide the final answer during DNS resolution.

Important NiceNIC Rule: NiceNIC DNS Requires NiceNIC Nameservers

NiceNIC provides free DNS management tools.

But the NiceNIC DNS Services guide explains an important requirement:

NiceNIC DNS Manage tools are used when the domain is using NiceNIC's default nameservers.

If you use external nameservers:

• Cloudflare;
• your hosting company;
• another DNS provider;

manage DNS records there instead.

This is one of the first things to check when somebody says:

"I changed the A record in NiceNIC but nothing happened."

The actual domain may not be using NiceNIC DNS at all.

Step 3: Verify the Nameservers Match the DNS Provider

Compare:

Nameservers configured at the registrar

with:

Nameservers assigned by your DNS provider

They must match the intended configuration.

For example, if Cloudflare gives you:

abby.ns.cloudflare.com

mark.ns.cloudflare.com

but the registrar still has old hosting nameservers, the Cloudflare DNS records are not authoritative yet.

Likewise, if the registrar points to NiceNIC default nameservers but you are editing DNS at another provider, those edits will not control the live domain.

If you need to change nameservers at NiceNIC, follow How to Update Domains' Nameservers.

Nameserver Update Failed or Rejected?

Some registries validate nameservers before accepting them.

NiceNIC’s current nameserver documentation notes that a registry may reject nameservers when they:

• are not properly configured;
• do not respond correctly;
• are not authoritative;
• fail registry technical validation.

If the update is rejected:

1. do not keep resubmitting the same invalid nameservers;
2. ask the DNS or hosting provider to confirm the nameservers are operational;
3. verify they are authoritative for the domain;
4. try the update again after the configuration is corrected.

This issue is especially important with TLDs that perform strict nameserver validation.

Step 4: Check the Authoritative DNS Records

Once you know which provider is authoritative, inspect the actual website records.

The most common records are:

A Record

Maps a hostname to an IPv4 address.

Example:

example.com → 203.0.113.10

If the hosting provider says the correct server IP is:

203.0.113.50

but your A record still points to:

203.0.113.10

the domain can be fully registered and the website can still go to the wrong server.

AAAA Record

Maps a hostname to IPv6.

An incorrect AAAA record can create a confusing situation:

• users or networks preferring IPv4 may work;
• users preferring IPv6 may fail.

If your hosting provider does not support the IPv6 destination configured in DNS, review the AAAA record.

CNAME Record

Often used for aliases such as:

www.example.com → example.hostingplatform.com

If the root domain works but www does not, a missing or incorrect CNAME is one of the first things to check.

Root Domain and www Are Separate Hostnames

This causes many website problems.

These are different DNS names:

example.com

www.example.com

Configuring one does not automatically guarantee the other is configured.

Possible situations:

When setting up a website, test both.

Step 5: Do Not Blame "DNS Propagation" Before Checking the Authoritative Answer

“DNS propagation” is often used as a general explanation whenever something does not work.

That can waste time.

DNS changes are not normally pushed to every resolver worldwide simultaneously.

Instead, recursive DNS resolvers cache answers.

Each cached record has a TTL — Time To Live.

Cloudflare defines DNS TTL as the amount of time a resolver can continue serving a cached DNS record before querying the authoritative server for a new copy.

This means:

If the authoritative DNS already has the correct new value, some users may temporarily continue receiving the old cached value until their resolver's cache expires.

That is a caching issue.

But:

If the authoritative DNS itself still has the wrong value, waiting will not fix it.

How Long Does DNS Propagation Take?

There is no single universal number.

The time users continue seeing older DNS data can depend on:

• previous TTL;
• resolver cache;
• negative caching;
• nameserver delegation caching;
• local network;
• ISP resolver;
• DNS provider behavior.

Some changes can become visible quickly.

Others can remain inconsistent until existing cache entries expire.

So avoid treating:

"24-48 hours"

as a guaranteed technical rule for every DNS update.

A better question is:

What answer does the authoritative nameserver give, and what is still cached elsewhere?

Why Does the Website Work for Me but Not Someone Else?

This is a classic caching symptom.

Different users may use different recursive resolvers.

For example:

• your home ISP may already have the new DNS answer;
• another user's ISP may still cache the old answer;
• a corporate network may have another cache;
• a VPN may use another resolver.

During a DNS transition, one user may see:

new website

while another still sees:

old website

or:

DNS error

This does not automatically mean the authoritative configuration is wrong.

Check DNS from more than one resolver or network.

What Is Negative DNS Caching?

Resolvers can also cache the fact that a DNS record did not exist.

For example:

1. you query new.example.com;
2. it does not exist;
3. the resolver caches the negative answer;
4. you create the record;
5. the same resolver may temporarily continue returning the old negative answer.

Cloudflare’s current DNS troubleshooting documentation explains that negative cache entries can persist until the applicable negative-cache TTL expires.

So creating a missing record does not always make every resolver immediately forget the previous NXDOMAIN result.

Step 6: Understand Common DNS Error Messages

NXDOMAIN

Usually means:

The requested DNS name does not exist according to the DNS answer.

Possible causes:

• record missing;
• wrong authoritative nameservers;
• delegation problem;
• typo;
• incomplete DNS setup.

SERVFAIL

Usually means the resolver could not successfully complete the DNS lookup.

Possible causes include:

• DNSSEC validation failure;
• authoritative DNS problem;
• broken delegation;
• nameserver failure.

Do not treat SERVFAIL as the same problem as NXDOMAIN.

DNS Timeout

Possible causes include:

• authoritative nameservers not responding;
• network connectivity problem;
• firewall issues;
• DNS provider outage.

Step 7: Check DNSSEC if You See SERVFAIL

DNSSEC protects DNS data using cryptographic validation.

But an incorrect DNSSEC configuration can make a perfectly registered domain fail to resolve on validating resolvers.

One common migration problem is:

1. DNSSEC is enabled;
2. the domain uses old DNS provider A;
3. DS records for provider A exist at the registrar/registry;
4. nameservers change to provider B;
5. provider B uses different DNSSEC keys;
6. old DS records remain;
7. validation fails.

The result can be:

SERVFAIL

even though the A record itself looks correct.

If the issue began after:

• changing nameservers;
• changing DNS providers;
• enabling DNSSEC;
• changing DNSSEC keys;

check:

• current nameservers;
• DS records;
• DNSKEY records;
• whether the active zone is correctly signed.

Do not randomly delete DNSSEC records without understanding which provider is authoritative.

Step 8: If DNS Resolves Correctly, Check the Hosting Server

Suppose:

example.com

correctly resolves to:

203.0.113.50

and that is the IP your host provided.

DNS may be working correctly.

The next layer is the hosting server.

Check:

• hosting account active?
• server online?
• web service running?
• firewall allowing HTTP/HTTPS?
• correct virtual host/domain configured?
• website files deployed?
• application running?
• database accessible?

At this point the registrar may have nothing to fix.

A Ping Test Does Not Prove the Website Works

ping can be useful for basic network troubleshooting.

But it does not prove:

• DNS works globally;
• HTTP works;
• HTTPS works;
• website application works.

Some servers block ICMP/ping while still serving websites normally.

Conversely, a server can respond to ping while the website application is broken.

Use the error symptom, DNS result, and HTTP/HTTPS behavior together.

Step 9: Check Whether the Server Recognizes the Domain

A server can be online but still show the wrong website.

This often happens on shared hosting or virtual hosts.

For example:

DNS correctly sends:

example.com → 203.0.113.50

but the hosting account has not added:

example.com

as a domain/site.

The server may then return:

• default hosting page;
• wrong website;
• 404;
• 403;
• "domain not configured" message.

Ask the hosting provider to confirm that:

• the domain has been added to the account;
• the correct document root is configured;
• the site is enabled.

Why Does the Wrong Website Load?

If another website appears, check:

1. A / AAAA records;
2. CDN or proxy configuration;
3. hosting virtual-host configuration;
4. whether the server IP is shared;
5. whether the domain has been added correctly at the host.

The fact that “something loads” does not prove DNS points to the correct website.

Step 10: Check HTTP vs HTTPS

Try both:

http://example.com

and:

https://example.com

If HTTP works but HTTPS fails, the issue may be:

• missing certificate;
• expired certificate;
• certificate not covering the hostname;
• incomplete SSL installation;
• HTTPS listener not configured;
• redirect loop;
• proxy/CDN SSL mode mismatch.

This is no longer primarily a domain-registration problem.

It is normally:

• hosting;
• SSL;
• CDN;
• web-server configuration.

Certificate Name Mismatch

A certificate must cover the hostname being requested.

For example:

a certificate for:

example.com

may not necessarily cover:

www.example.com

unless the certificate includes both names or an appropriate wildcard.

So if:

https://example.com

works but:

https://www.example.com

does not,

check both:

• DNS for www;
• SSL coverage for www.

Too Many Redirects

If the browser reports a redirect loop, check:

• HTTP → HTTPS redirects;
• www → root redirects;
• root → www redirects;
• CDN proxy rules;
• CMS settings;
• application base URL.

A common example:

CDN forces HTTPS

while:

origin server redirects HTTPS back to HTTP

creating a loop.

This is not fixed by changing the registrar.

What Do HTTP Error Codes Tell You?

If the browser reaches a server and receives an HTTP status, DNS may already be working.

403 Forbidden

The server received the request but refuses access.

Check:

• permissions;
• security rules;
• web server configuration.

404 Not Found

The server is reachable but cannot find the requested page.

Check:

• document root;
• URL;
• application routing;
• website deployment.

500 Internal Server Error

The web application/server encountered an internal problem.

Check:

• server logs;
• application;
• PHP/runtime;
• database;
• plugin or code errors.

A registrar normally cannot fix application-level 403/404/500 errors.

Website Works on One Network but Not Another

Possible causes include:

• resolver caching;
• negative DNS caching;
• IPv4 vs IPv6 differences;
• ISP routing;
• local DNS;
• corporate firewall;
• CDN/WAF restrictions.

Test:

• Wi-Fi;
• mobile data;
• another public DNS resolver;
• another geographic network where practical.

If everyone except one network can access the website, do not immediately change the authoritative DNS.

The problem may be local or resolver-specific.

Browser Cache vs DNS Cache

These are not the same thing.

Browser cache

Stores web resources such as:

• HTML;
• CSS;
• JavaScript;
• images;
• redirects.

DNS cache

Stores DNS answers mapping hostnames to destinations.

Clearing your browser cache does not necessarily clear:

• operating system DNS cache;
• router cache;
• ISP resolver cache.

Likewise, flushing local DNS does not remove cached DNS data from an upstream ISP resolver.

What If Both Website and Email Stop Working?

That is an important diagnostic clue.

If:

• website stops;
• email stops;
• other domain-based services stop;

at roughly the same time, check the shared layers first:

1. domain expiration;
2. clientHold / serverHold;
3. nameserver delegation;
4. DNS provider availability;
5. DNSSEC.

Do not start by reinstalling the website.

A shared domain/DNS failure can affect many services at once.

What If the Website Fails but Email Still Works?

This often suggests that:

• DNS is at least partially functional;
• MX records still work;
• the problem may be limited to website A/AAAA/CNAME records;
• hosting may be unavailable;
• HTTPS or application configuration may be broken.

This symptom helps narrow the problem.

What If Email Fails but the Website Works?

The website A/CNAME records may be fine while mail-related records are wrong.

Check:

• MX;
• SPF;
• DKIM;
• DMARC;
• email provider setup.

Do not change the website A record to fix an email-routing problem.

Registrar vs DNS Provider vs Hosting Provider: Who Should Fix It?

This is why knowing who controls each layer matters.

For a broader explanation, read Domain Registrar vs Web Hosting.

NiceNIC DNS: Where Should You Make Changes?

Use this rule.

If Your Domain Uses NiceNIC Default Nameservers

Manage DNS through NiceNIC.

You can:

• add A records;
• add CNAME records;
• configure MX;
• configure other supported records.

See the NiceNIC DNS Services guide.

If Your Domain Uses External Nameservers

Manage DNS at the external provider.

Examples:

• Cloudflare;
• hosting provider;
• corporate DNS;
• another managed DNS service.

Do not create duplicate DNS records at NiceNIC expecting them to affect the live domain.

Can You Use Cloudflare Without Transferring the Domain?

Yes.

You can keep the domain registered at NiceNIC while using Cloudflare as the authoritative DNS/CDN/security provider.

NiceNIC documents this setup in Can You Use Cloudflare DNS Without Transferring Your Domain?.

A valid architecture can be:

These layers do not need to be supplied by one company.

What If the Problem Started After Changing Nameservers?

Check this order:

1. Did the registrar accept the new nameservers?
2. Do the new nameservers answer authoritatively?
3. Does the new DNS zone contain all required records?
4. Were the old A/AAAA/CNAME records copied?
5. Were MX, SPF, DKIM, and DMARC preserved?
6. Was DNSSEC enabled before the change?
7. Do old DS records still exist?
8. Are users seeing cached old delegation?

Changing nameservers is a larger operation than changing one A record.

It effectively changes which DNS provider has authority over the domain.

What If the Problem Started After a Domain Transfer?

A registrar transfer itself does not normally require changing hosting or DNS.

If the existing nameservers remain unchanged, the website should normally continue using the same DNS provider.

Problems can occur if:

• nameservers were changed during the transfer;
• old registrar DNS stopped after transfer;
• DNS records were not recreated elsewhere;
• DNSSEC data became inconsistent.

See the NiceNIC guide to domain transfer and nameserver handling.

What If the Problem Started After Domain Expiration?

Check expiration before DNS.

An expired domain can stop resolving even if:

• hosting still works;
• website files still exist;
• server is online.

If the domain has expired, read What Happens When a Domain Expires? before changing technical infrastructure.

A 5-Minute Troubleshooting Order

Do the checks in this order.

Minute 1: Registration

Check:

• domain expiration;
• domain status;
• clientHold;
• serverHold.

If the domain is on Hold, fix that before troubleshooting the website server.

Minute 2: Nameservers

Check:

• which nameservers are delegated;
• whether they belong to the intended DNS provider.

If you are editing DNS at provider A while nameservers point to provider B, stop and fix that first.

Minute 3: DNS Records

Check:

• root A/AAAA;
• www;
• CNAME;
• whether values match the host.

Do not assume root and www are identical.

Minute 4: Server

If DNS is correct:

• check hosting account;
• server;
• website;
• application.

Minute 5: HTTPS and Local Differences

Check:

• HTTP vs HTTPS;
• certificate;
• redirects;
• another network;
• DNSSEC if SERVFAIL appears.

This order prevents random configuration changes.

Symptom → Cause → Fix

This table should be your starting point whenever the domain registration exists but the service is unavailable.

What Information Should You Collect Before Contacting Support?

Do not send only:

"My website is not working."

Provide:

• exact domain;
• approximate time the issue began;
• whether the domain recently expired;
• current nameservers;
• recent DNS changes;
• recent registrar transfer;
• recent nameserver change;
• whether DNSSEC is enabled;
• exact browser error;
• screenshot;
• whether HTTP works;
• whether HTTPS works;
• whether www works;
• whether the root domain works;
• whether email works;
• whether another network can access it.

This often allows the correct provider to identify the issue much faster.

Common Mistakes to Avoid

"The domain says Active, so the registrar must be responsible."

No.

Active registration does not prove DNS, hosting, SSL, or application health.

"I changed DNS. I should just wait 48 hours."

Not automatically.

First confirm the authoritative DNS has the correct value.

Waiting does not fix a wrong record.

"My hosting company gave me nameservers, so I should also add the same DNS records at NiceNIC."

Not if the external nameservers are authoritative.

Manage DNS at the provider actually serving the zone.

"Ping works, so the website must be working."

No.

Ping and HTTP are different protocols.

"I can fix serverHold by changing A records."

No.

A registry Hold can prevent DNS delegation entirely.

"If SSL fails, change nameservers."

Usually not.

Identify whether DNS is correct first, then troubleshoot the SSL layer.

"If the website is down, transfer the domain."

A registrar transfer is normally unrelated to hosting outages.

Frequently Asked Questions

Why is my domain active but my website is not loading?

Because an active domain registration does not guarantee that nameservers, DNS records, hosting, SSL, or website configuration are correct.

How do I know if the problem is DNS or hosting?

If DNS does not return the correct destination, investigate DNS. If DNS correctly resolves to the host but the server does not respond or returns application errors, investigate hosting.

Why does my domain work for some people but not others?

Different recursive DNS resolvers may still have different cached answers. Confirm the authoritative DNS first, then consider TTL and caching.

How long does DNS propagation take?

There is no universal fixed time. Cached results normally remain until their TTL expires, and nameserver/delegation changes can have additional caching behavior.

Should I always wait 24-48 hours after changing DNS?

No. First confirm the authoritative DNS configuration is correct. Waiting only helps when old answers are still legitimately cached.

Why does www not work but the main domain works?

www.example.com and example.com are separate DNS names. Check whether the www A/CNAME record exists and whether the server recognizes it.

Why does my domain show NXDOMAIN?

The requested DNS name does not exist according to the resolver’s answer. Check the authoritative zone, nameserver delegation, record existence, and negative caching.

What does SERVFAIL mean?

It means the resolver could not successfully complete the DNS lookup. DNSSEC failures and authoritative DNS problems are common causes.

Can DNSSEC make my website stop working?

Incorrect DNSSEC configuration can cause validation failures such as SERVFAIL, especially after nameserver or DNS-provider changes.

Does clientHold stop the website?

It can. ICANN defines clientHold as a registrar-set status that prevents normal DNS activation of the domain.

Does serverHold stop the website?

It can. serverHold is registry-set and can prevent the domain from being published in DNS.

My A record is correct. Why is the website still down?

The server may be offline, the domain may not be configured at the host, SSL may fail, the application may be broken, or an AAAA/CDN/proxy configuration may interfere.

Can I manage DNS at NiceNIC if I use Cloudflare nameservers?

Normally no. When Cloudflare nameservers are authoritative, manage DNS at Cloudflare. The domain registration can still remain at NiceNIC.

Does transferring a domain fix DNS problems?

Not normally. Transfer changes the registrar. It does not automatically correct DNS, hosting, SSL, or website configuration.

Can the website be down even though email works?

Yes. Website DNS/hosting can fail while MX and email services continue working.

Can email and website both fail because of one problem?

Yes. Domain expiration, Hold status, nameserver failure, DNS provider outage, or DNSSEC failure can affect multiple domain-based services.

Final Website Troubleshooting Checklist

Before opening a support ticket, confirm:

• The domain is not expired.
• There is no clientHold or serverHold.
• The intended nameservers are active.
• You are editing DNS at the authoritative provider.
• The root A/AAAA record is correct.
• The www record is correct.
• There are no conflicting old records.
• DNSSEC is valid if enabled.
• DNS answers are correct at the authoritative nameserver.
• Cached old answers are considered separately.
• The hosting account is active.
• The hosting server is reachable.
• The domain is configured on the server.
• Website files/application exist.
• HTTP and HTTPS have both been tested.
• SSL covers the hostname.
• Redirect rules are not looping.
• Another network/device has been tested.
• Email status has been checked as an additional clue.

The key rule is:

Do not change several layers at once. Find the first failing layer and fix that layer first.

Fix the Right Layer

If the problem is at the domain or DNS-management layer:

• Check NiceNIC's urgent domain troubleshooting guide
• Review NiceNIC DNS Services
• Update your domain nameservers
• Review common DNS change problems
• Check domain status codes
• Understand ClientHold and ServerHold
• Use Cloudflare DNS without transferring your NiceNIC domain
• Understand the difference between a registrar and hosting provider
• Check what happens when a domain expires

If the domain and authoritative DNS are correct but the website server or application is failing, contact the hosting provider or website administrator instead.

Primary Sources and Further Reading

• ICANN — EPP Status Codes
• ICANN — Framework for Registry Operators to Respond to Security Threats
• Cloudflare — Nameservers and Authoritative DNS
• Cloudflare — General DNS Troubleshooting
• Cloudflare — DNS TTL Explained
• NiceNIC — DNS Services
• NiceNIC — Why Domain Name Is Not Working
• NiceNIC — Why Your DNS Changes Are Not Working
• NiceNIC — Update Domains' Nameservers
• NiceNIC — Domain Status Codes