The message "DNS server not responding" almost never means DNS itself is broken: in most cases the cause is a cache, a resolver, or the zone's settings.

A one-minute check

Before touching any settings, it helps to find out whether the problem is on your side or the domain's. Three quick checks separate one from the other.

Open any other website — if it also fails to load, the issue is not this domain's DNS but your own network.
Check from another device on the same network — if the site opens there, the problem is in that one device's cache.
Switch to mobile internet — if the site opens, the cause is the network or router, not the domain's DNS zone.

Symptom, cause, action

The table below helps quickly place your exact situation.

Symptom	Likely cause	What to do
The site does not open only for you	An old record is still in the local cache	Flush the DNS cache on your device
The site does not open for anyone	An error in the zone record itself or on the server	Check the record directly against the authoritative server
The site opens by IP but not by name	The problem is specifically in DNS, not on the server	Check the A record and whether it matches the server's address
The error happens only in one browser	That browser's cache or an extension	Clear the browser cache or open the site in another one
The problem started after changing NS servers	Old records have not yet expired by TTL	Wait for the TTL to expire and check the records again

Flushing the DNS cache

The DNS cache is stored not only at the provider's resolver but also on the device itself. If a record has changed and the old value is still cached locally, flushing it fixes the problem instantly.

ipconfig /flushdns                    # Windows
sudo dscacheutil -flushcache          # macOS
sudo systemd-resolve --flush-caches   # Linux with systemd-resolved

Checking from outside

If the cache is flushed and the site is still unreachable, it helps to ask not your own resolver but the domain directly — that shows whether the zone answers at all.

dig example.com @8.8.8.8            # Query to a public resolver
dig example.com @ns1.example.com    # Query to the zone's NS server

A recent change of NS or records

If the error started right after changing NS servers or editing records, the cause is almost certainly TTL. The old value lives in other caches for exactly the time stated in the record, and will not update before it expires.

The timing and how to speed up the check are covered in the article on DNS propagation; how to change NS servers correctly is covered in the article on changing NS servers.

When the cause is on the internet provider's side

Sometimes the domain's DNS is fine, but the resolver of your own internet provider is temporarily not responding or responds with an error. This is an external cause that cannot be fixed through the domain's settings.

The proof is simple: a query to a public resolver (as in the example above) succeeds, while a query over the regular connection does not. That is a reason to contact the internet provider, not the domain's DNS hosting.

What to gather before contacting support

A ready description speeds up handling the request many times over. It helps to state: the domain itself, exactly what fails to open (the whole site or a specific feature), the output of the dig command, and from which address or network the check was made.

The more specific the question, the faster the cause is found — an abstract "the domain is not working" needs a separate clarification before the check can even begin.