DNS often goes unnoticed until a website becomes unavailable. A user enters a domain name in the browser and expects the website to open. When it doesn’t, the problem may seem related to the web server. However, DNS resolution, network connectivity, firewalls, load balancers, or incorrect DNS records can also prevent a website from opening.
DNS performance and availability are important parts of maintaining a reliable server environment. Server Management Services can help businesses monitor and manage the underlying infrastructure while addressing issues that affect availability and performance.
DNS problems can also be difficult to diagnose. A website may resolve correctly from one network but fail from another. A DNS record may have changed, while some users continue receiving an older IP address because of caching.
These situations make DNS performance and high availability an important part of the overall infrastructure.
How DNS Resolution Works
When a user enters a domain such as www.example.com, the browser needs to obtain the corresponding IP address before it can connect to the web server.
A simplified DNS resolution process looks like this:
User’s Browser → Local DNS Cache → Recursive DNS Resolver → Authoritative DNS Server → IP Address Obtained → Web Server
Several caching stages can exist during this process. The browser or operating system may already have the answer stored locally, while the recursive DNS resolver can also cache the record.
If the resolver already has the answer, it does not need to query the authoritative nameserver. This is one of the main reasons DNS caching is important. If the record isn’t in the cache, the resolver must make additional queries to get the final answer.
What Causes DNS Latency?
DNS latency can have several causes, so a slow response should not immediately be attributed to the DNS server itself.
Geographical Location
The geographical location of the DNS infrastructure can affect response time. If most users are located in India and Asia while the DNS infrastructure is in North America, the first DNS request may experience additional latency.
The difference may be barely noticeable for a small website. At a larger scale, reducing unnecessary network distance matters more. This is one reason large DNS providers maintain infrastructure across multiple locations.
DNS Server Load
DNS servers generally have lower resource requirements than application or database servers, but their resource usage still needs attention.
Useful metrics during troubleshooting include:
- CPU usage
- Memory usage
- Network usage
- Queries per second
- DNS response time
- SERVFAIL errors
- REFUSED errors
- Packet loss
An increase in DNS traffic does not necessarily indicate an attack or a problem with the server. Regular traffic growth, configuration changes, reduced TTL values, and repeated queries from many clients can also increase DNS traffic.
The important factor is how the current behavior compares with normal activity.
DNS Caching and TTL
Caching is one of the simplest ways to reduce DNS traffic. Each DNS record has a TTL, or Time To Live, which determines how long the information can remain cached.
For example:
www.example.com 3600 IN A 203.0.113.10
A TTL of 3600 seconds allows the information to remain cached for one hour. During that period, a recursive resolver can respond using its cached copy instead of contacting the authoritative DNS server again.
There is no single TTL value that works for every situation. Lower TTL values can help when DNS records need to be changed frequently. During a server migration, an administrator can lower the TTL before making the DNS change.
Lower TTL values also result in more DNS requests. Higher TTL values improve caching and reduce repeated requests, but DNS changes take longer to take effect because cached records remain available.
Production applications generally do not need unnecessarily low TTL values. Lowering the TTL also does not clear records that were previously cached using a higher TTL.
Improving DNS Availability
Multiple authoritative nameservers are a basic requirement for reliable DNS. If one nameserver becomes unavailable, recursive resolvers can use another nameserver to obtain the required information.
A setup such as this provides more than one nameserver:
example.com
|
+---- ns1.example-dns.com
|
+---- ns2.example-dns.com
Having multiple nameservers alone does not guarantee high availability. If both nameservers rely on the same network infrastructure, a problem affecting that infrastructure could affect both.
Nameservers can instead be separated across different networks, data centers, providers, or geographic locations.
Geographic Distribution and Anycast
Larger services can distribute DNS infrastructure across multiple regions, such as Asia, Europe, and America. This can reduce network distance for users while providing additional redundancy.
Anycast is another technique used by large DNS networks. It allows the same IP address to be used from different network locations. The network determines where a request should be processed.
If one location becomes unavailable, traffic can potentially be redirected to another available location. Anycast can therefore help address both latency and availability. Its infrastructure-level implementation, however, is more complicated than simply using multiple DNS records.
Avoiding Unnecessary DNS Queries
DNS performance also depends on how applications use hostnames.
A webpage may use resources hosted under several different names:
example.com
cdn.example.com
api.example.com
images.example.net
analytics.example.org
Depending on caching and client-side resolver behavior, separate DNS queries may be required for these hostnames.
Using multiple hostnames is not necessarily a problem. CDNs, APIs, and third-party services often require separate domain names. During an application performance investigation, it can still be useful to examine how many external hostnames are being used and whether they are necessary.
Troubleshooting DNS Using dig
Command-line tools can provide useful information when investigating DNS issues. dig is particularly useful because it displays the DNS response along with information such as the returned data, TTL, query status, and query time.
A basic query is:
dig example.comA query can also be sent to a specific resolver:
dig @8.8.8.8 example.com
The authoritative nameservers can be identified using:
dig example.com NSA specific record type can also be queried:
dig example.com AThe query time can help when investigating latency:
;; Query time: 25 msecA single query does not establish a performance problem. Multiple queries from different networks can help reveal a pattern.
Comparing different recursive resolvers can also help identify caching or propagation issues:
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
An old record from one resolver and a new record from another can indicate caching or propagation issues. This check is especially useful after changing A, AAAA, CNAME, or other DNS records.
DNS Response Codes and DNSSEC
DNS response codes can immediately indicate what is happening.
NOERROR means the query was successful. The answer section should still be checked because NOERROR does not necessarily mean that the requested record exists.
NXDOMAIN means the queried domain name does not exist according to the answering DNS server. A mistyped hostname can result in NXDOMAIN.
SERVFAIL indicates that the resolver could not successfully process the query. Possible causes include communication problems with authoritative servers, DNSSEC validation issues, DNS configuration problems, delegation problems, and networking issues.
REFUSED means the DNS server received the query but refused to process it. The reason can depend on access-control policies and server configuration.
DNSSEC authenticates DNS responses and helps protect against certain types of DNS response manipulation. Incorrect DNSSEC configuration can cause an authoritative server to appear functional while a validating resolver refuses its response.
DNSKEY, DS records, key rollover, DNSSEC validation, and expired or invalid signatures therefore need careful attention. DNSSEC errors can make a domain inaccessible to some users.
DNS Failover and Load Balancers
DNS can also form part of a failover solution. If Server A becomes unavailable, a DNS-based solution may point future clients toward Server B.
DNS answers are cached, however. If Server A’s IP address has already been cached by a recursive resolver, changing the DNS answer does not immediately make every client use Server B.
DNS therefore cannot always provide immediate failover. Applications that require fast failover may be better suited to a load balancer or another high-availability solution.
DNS and load balancers can work together in a production environment:
User → DNS → Load Balancer → Web Server A / Web Server B
DNS provides hostname resolution, while the load balancer determines which backend server handles the application request. Keeping these responsibilities separate is better than trying to achieve the same behavior through DNS alone.
DNS Monitoring
DNS monitoring should go beyond checking whether a domain resolves. Useful monitoring areas include:
- DNS performance
- DNS availability
- SERVFAIL rate
- NXDOMAIN rate
- Nameserver availability
- Query traffic
- Differences in DNS resolution across regions
Multi-region monitoring can reveal problems that are not visible from a single location. A DNS provider may appear to perform normally from one location while users in another region experience timeouts. Regular monitoring can help identify DNS performance and availability issues before they affect users. This is also an important part of server management, where infrastructure performance and availability need to be monitored consistently.
A Practical DNS Troubleshooting Approach
A layered approach can help identify the cause when a customer reports that a website cannot be opened.
1. Check whether the domain resolves.
dig example.comIf it does not resolve, investigate DNS first.
2. Identify the authoritative nameservers.
dig example.com NS3. Query the authoritative server.
dig @ns1.example.com example.comThis helps determine whether the authoritative server is returning the expected information.
4. Compare recursive resolvers.
dig @8.8.8.8 example.com
dig @1.1.1.1 example.comThis can help identify caching or resolver-specific issues.
5. Verify the returned IP address.
The returned IP should be checked to confirm that it is the expected address.
6. Test HTTP or HTTPS separately.
curl -I http://example.comOr
curl -I https://example.comIf DNS works but the HTTP request fails, the investigation can move to firewall rules, security groups, listening ports, web server status, load balancer health, application errors, and server resource utilization.
This layered approach helps separate DNS problems from network, server, and application issues.
DNS Best Practices
A practical DNS setup should follow these guidelines:
- Keep at least two authoritative nameservers.
- Avoid placing all authoritative DNS infrastructure in the same failure domain.
- Use geographic distribution based on scale and user base.
- Choose TTL values according to how often DNS records change.
- Avoid short TTL values for stable DNS records.
- Monitor DNS latency as well as availability.
- Monitor SERVFAIL and other unusual response patterns.
- Test DNS changes on production domains.
- Keep backups of DNS zone data.
- Use version control for DNS configurations.
- Monitor DNSSEC carefully when it is enabled.
- Consider Anycast or managed DNS for larger environments.
- Do not rely on DNS alone for immediate application failover.
- Test DNS resolution from multiple networks and locations.
Conclusion
DNS may appear to have a simple role, converting a domain name into an IP address, but several layers operate behind that process. A website that cannot be accessed is not necessarily experiencing a web server problem. Checking DNS first can help determine whether the request is reaching the expected destination.
Better DNS performance can come from effective caching, appropriate TTL values, redundant nameservers, geographic distribution, and proper monitoring. Larger environments can also use technologies such as Anycast, managed DNS services, health checks, and load balancers to improve resilience.
A good DNS setup should not only provide fast resolution when everything is working normally. It should also remain available during problems and make it easier to identify the underlying cause when something goes wrong.
