DNS server not responding? See what to do before you lose your patience.

No access to websites, applications, or cloud services, and users are flooding the helpdesk with tickets? In the logs, the message "DNS server not responding" repeats like a mantra? Before you start blaming the hardware or the internet provider, it's worth checking step-by-step where the problem really lies. This guide will show you what to do when the DNS server isn't responding, how to make an accurate diagnosis, and what to implement so that this situation doesn't happen again in a week

Before you start looking for fault in the infrastructure, do something that may sound trivial – check the basic connectivity with the network and the DNS server. In many cases, especially in office environments with a high turnover of devices and configurations, the problem turns out to be trivial: an incorrect IP address, a missing default gateway, or simply no signal. Tools like ping, ipconfig /all, or tracert can show in a few seconds whether the problem lies on the local network side, or if you need to dig deeper.

If the workstation doesn't see the server at all, it doesn't necessarily mean that the DNS server is not working. Often it's a matter of incorrectly assigned data by DHCP, sometimes a switch failure, and it happens that someone simply unplugged the cable from the patch panel and didn't tell anyone. Before you call the administrator or restart half the server room, run a test with an alternative DNS – e.g., Google 8.8.8.8 – and check if the queries return. This will allow you to immediately determine whether it's a problem with the DNS servers in the corporate network, or with the connection in general. DNS communication errors are very often the result of congestion on the local network, not a real failure of the name system.

If everything on the network side seems to be in order, and yet the DNS server is not responding, you need to go deeper – into its configuration. Especially in environments using Microsoft DNS or BIND, it's worth looking at the zone files and records.

A missing A record for an important domain, incorrect CNAME entries, or unsynchronized data between the primary and backup server can cause the client not to receive a response – even though the service is technically working.

This is where the typically engineering analysis begins. AXFR verification, checking TTL, or caching policies – all of this can lead to a situation where the primary DNS server does not respond, although it is seemingly available. The problem often comes to light only after using nslookup with parameters indicating a specific DNS – and then a lack of authority or a bad zone delegation appears. It also happens that recursion is disabled or blocked by an ACL, preventing local devices from accessing external addresses.

An error in one PTR entry can stop entire applications that use reverse DNS logic, and an oversight in the configuration of NS records can cause queries to be directed into the void. For administrators who inherit an environment from someone else – this is a particularly sensitive poin.

Not every DNS failure is a blackout. Sometimes the DNS server is not available not because it has crashed, but because it responds with such a delay that for the application it looks like a timeout. And here the issue of performance arises. High latency, overload of one node, too little RAM or CPU used 100% by other processes – all of this can bring the DNS service to its knees.

It is worth implementing response time monitoring and system logs – Event Viewer in Windows, querylog in BIND, or tools like Zabbix and Nagios allow you to detect what is causing the slowdown. If the logs show a lot of queries from one source, it may even be a symptom of a DDoS attack on the DNS layer. Query loops, which bombard the server from the internal network, generating unnecessary load, are also quite common.

A good practice is also to analyze the cache and so-called scavenging – if the DNS server stores old entries with outdated data, it will respond incorrectly, even though its logic is working correctly. Client applications may therefore report that the device or resource "DNS server" is not responding, even though it is physically fully operational. In such cases, only a full analysis of the load, entry rotation, and cache policies helps.

You don't always have to go to the server right away. If there are a few reports, and they are not massive – it's worth starting with the workstations. Often, the user gets the message "DNS server not responding" because the system cache contains old, incorrect entries, or the network card driver was installed in a version from two years ago and no longer handles the current methods of handling DNS over HTTPS.

• A simple ipconfig /flushdns command can restore full functionality in a second.

• In turn, a test via nslookup or dig on the 8.8.8.8 DNS can dispel all doubts – if the query goes through with an external DNS, and not with the company's, then you know where to look.

Interestingly, systems with a large number of local entries in the hosts file can also block DNS queries, especially if the file is modified by malicious software or developer tests.

It is also worth paying attention to changing network permissions – some firewalls block UDP port 53, which for DNS means complete silence. This is a typical case in environments that have recently implemented new security policies. Then the user does not know what to do when the DNS server is not responding, because everything else on the network works. And that's when it's worth starting with the client before you jump to the infrastructure level.

Every administrator knows that one flushdns today is another ticket tomorrow if you don't solve the problem at its source. In companies where DNS is a critical service (and it almost always is), it is worth taking care of the redundancy and resilience of the system. A minimum of two DNS servers in different locations, configured with Anycast and supervised by a load balancer (e.g., F5 BIG-IP DNS), is no longer "good practice", but an absolute necessity.

In addition, there are security measures: DNSSEC protects against response spoofing, DNS over TLS or HTTPS encrypts queries and prevents eavesdropping on public networks, and real-time DNS analytics allow you to catch anomalies before they do damage. A well-set RPZ policy will block connections to malware domains before the user clicks a suspicious link.

This all sounds like advanced engineering – and it is, to some extent. But if you don't plan an architecture with resilience in mind today, tomorrow you'll see another report that the DNS server is not available, and the CRM won't start because it can't resolve the license server's domain. The cost of downtime is then counted in thousands – and often it was a matter of one entry in the ACL.

The fact that DNS works today does not mean it will work tomorrow. And that is why every company – regardless of its scale – should have a DR (Disaster Recovery) plan for its DNS infrastructure. It sounds serious, but it's about the basics: documentation of all DNS servers, description of zones, records, TTL policies, and replication. This is the first step to not having to look for everything from scratch in the event of a failure.

In the next stage, it is worth carrying out tests. Not just backup – simulation of the failure of the main server and checking whether the backup actually takes over the traffic. Automation of zone and configuration restoration (e.g., through PowerShell scripts or Infrastructure as Code tools) allows you to reduce the reaction time from hours to minutes. And that's when the IT team gets a "DNS server not responding" report – instead of panic, there is a checklist and peace of mind.

The worst situation is one in which DNS goes down, and you don't even have a list of what the last state of the records was. This is not a question of "how to fix the DNS server", but "can it still be restored?". Therefore, it is better to think about it earlier – when it is still working – than later, when everything depends on one copy from yesterday's backup