One place for hosting & domains

      DNS Server Not Responding Error? Here’s How To Fix It (13 Ways)

      Unlike many problems that affect websites, the DNS Server Not Responding error seems pretty descriptive. Clearly, some distant server isn’t playing ball and it’s blocking you from visiting a particular website.

      But what exactly is a DNS server and why is it misbehaving? In a strange way, the information provided by the error message is only useful if you already know what it means.

      To help you resolve this issue, we decided to take a deeper look at the DNS Server Not Responding error, and all the possible causes. Keep reading to find the answers you’re looking for!

      What Does The “DNS Server Not Responding” Error Mean?

      To understand this error, we first need to take a quick look at DNS, or domain name system.

      DreamHost Glossary

      DNS

      The Domain Name System (DNS) protocol keeps records of which domain names correspond to specific IP addresses. DNS enables you to browse the web by typing in regular URLs instead of IP addresses.

      Read More

      Whenever you ask your browser to connect to a website, a DNS server has to convert the domain name (e.g., mysite.com) to the numeric IP address (four numbers separated by three periods, for example, 127.0.0.1) of the hosting server. This is where the site actually lives; the domain name is simply a pretty title that is easier for humans to remember.

      DNS Server Not Responding error occurs when, for some reason, your browser can’t make contact with the server that handles the domain name to IP address translation.

      There are three underlying reasons why this could be happening:

      • The DNS server is down or unreachable: There is something wrong with the server itself, or its network connection.
      • You have connectivity issues: Often due to an outage somewhere between you and the server, including network issues.
      • The DNS record for the domain name is incorrect or missing: This means the DNS server doesn’t know which IP address to point the domain name to.

      3 possible issues with DNS server not responding error: DNS server is down, connectivity issues, DNA record error or missing

      In order to fix the error, we need to work through a checklist that covers all three possible causes.

      Fixing The DNS Server Not Responding Error

      If the DNS Server Not Responding error appears only on your site, it might be because your domain name isn’t configured correctly.

      • Make sure your domain name hasn’t expired.
      • Check that you have an “A record” and it contains no typos.
      • If you made changes recently, give them time to propagate.

      If none of this helps, or you see the error on other websites, here are all the ways you can fix a DNS Server Not Responding error:

      1. Try Using A Different Browser

      Strictly speaking, switching to another browser won’t fix DNS issues. But it can reveal what has gone wrong.

      Every browser maintains a cache, where content is stored temporarily for quick access. The problem is that your browser cache might have stored the wrong DNS records. If this happens, you will get the same error message whenever you try to revisit the same page.

      DreamHost Glossary

      Cache

      A cache is a temporary data storage layer that is designed to improve data access speeds by reducing the time needed to read and write data from a permanent data storage location.

      Read More

      By moving away from your default browser, you will be using a different cache, and each browser has its own default DNS servers. In addition, you will bypass other issues like extensions that block connections.

      2. Check The Site From A Different Device

      If you’re still seeing an error on a particular website after changing your browser, try swapping to a different device. This will ensure that some other unexpected issue in your local system isn’t causing the problem.

      If you don’t have access to another desktop computer, simply pull out your phone and try to visit the page in question. If this doesn’t fix the error, it’s also worth connecting to a different network or switching to data.

      3. Restart Your Computer

      Another way to deal with cache-related problems is by restarting your device. This will flush all DNS records from your machine, so your device will have to perform a live DNS lookup when you visit the problematic page.

      Restarting your device also renews its IP address and clears the DNS request queue, which can be enough to fix certain connectivity issues. It could be enough to clear the error.

      Get Content Delivered Straight to Your Inbox

      Subscribe to our blog and receive great content just like this delivered straight to your inbox.

      4. Restart Your Computer In Safe Mode

      Sometimes, software and related drivers on your device are the cause for the blocked DNS connections. To test for this issue, it’s a good idea to boot up your device in Safe Mode:

      Windows:

      1. On the sign-in screen, click Restart while holding Shift.
      2. Select Troubleshoot > Advanced options > Startup Settings > Restart.
      3. After restart, press 5 or F5 to start up your device in safe mode with networking.

      screenshot of the startup settings in windows highlighting the restart button in the lower right-hand corner

      Mac: Hold Shift as you power up.

      screenshot of a mac starting up in safe mode

      iOS / Android: Press and hold the power button, and then tap the down volume control after the screen lights up.

      screenshot of a ios mobile phone power selector settings highlighting the safe mode option

      In this mode, your machine will revert to default settings and only the most essential drivers. If the problem sites load normally while in Safe Mode, it means that either third-party software or drivers are causing incompatibility issues.

      This is definitely bad news, because the only way to track down the precise cause is by testing your apps, one by one. That said, it’s most likely to be something like a VPN, or security software causing your headaches.

      5. Turn Off Antivirus Software And/Or Your Firewall

      Antivirus applications and firewalls protect your device by monitoring traffic. From time to time, these tools sometimes meddle too much with your internet connection and end up causing DNS server errors.

      As such, it’s a good idea to switch off your antivirus program and/or firewall protection temporarily, to test whether they are causing the problems.

      If this resolves the problem, make sure to turn your protection back on. Then, look through the settings to find anything related to DNS that may be causing your troubles. If your chosen software package includes support, it may be worth reaching out to your provider for help.

      6. Turn Off Your VPN

      VPNs, or virtual private networks, provide an extra layer of online privacy by routing data to your device through an encrypted tunnel. So far, so useful. The issue is, the tunnel might be bypassing your default DNS servers.

      To test this idea, switch off your VPN and try to visit the page where you had the DNS server issue. If this resolves your problems, restart the VPN and take a peek at the settings. You’re looking for controls related to DNS filtering. If you need a helping hand, try contacting your VPN provider for support.

      7. Flush DNS Cache

      You don’t necessarily need to restart your device to flush the DNS cache. You can do it manually instead:

      1. Press Win + R and type in the “ipconfig /flushdns”.
      2. Then, hit Ctrl + Shift + Enter to run the command prompt.
      1. Open the Terminal, and type in “sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder”.
      2. Press Enter.
      3. Input your admin password when prompted, and press the Enter button again.
      • iOS: Turn Airplane Mode on and back off again.
      • Android
      1. In Chrome, type “chrome://net-internals/#dns” into the search box.
      2. Select DNS on the left, and then tap Clear host cache

      By flushing your DNS cache, you will force your device to re-query the DNS server for each site you visit. This ensures you have updated mappings of domain names to IP addresses — an essential first step in network diagnostics.

      8. Restart Your Router

      Network connection issues are a common cause of DNS server errors. One easy way to fix this kind of problem is by restarting your internet router.

      Switch it off and unplug the power cable for around 30 seconds. This should clear any corrupted DNS entries that have been stored in the router cache, and renew your connection.

      At the same time, it’s worth checking that your router’s firmware is up to date. Outdated firmware can cause connectivity issues that prevent DNS lookups. In combination, these steps might fix your problem.

      9. Disable IPv6

      Internet protocol is the system that creates a unique IP address for every device on the internet. The current version is IPv6 (Internet Protocol Version 6), which has gradually replaced IPv4 over the past few years. It is now the default option.

      However, not every network and DNS server has been updated to IPv6.

      If you use this version to request a particular web page, you might only receive a DNS Server Not Responding error. Similarly, systems that are in hybrid mode can experience technical troubles in juggling both systems.

      For this reason, it’s worth temporarily switching off IPv6 to see whether you can access a website via IPv4.

      The exact process depends on your platform, but it usually involves:

      1. Visiting the network settings on your device.
      2. Selecting your active connection (usually Ethernet or Wi-Fi).
      3. Accessing the advanced options via Advanced, Properties, or i.
      4. Toggling IPv6 off, and saving your changes.

      screenshot of windows DNS settings options to toggle IPv4 and IPv6 on and off

      Lastly, you will need to restart your device to test whether this potential solution has worked. If you see no improvement, reverse the process to switch IPv6 back on — this can help you to maintain better performance as you move between different networks.

      10. Change The Default DNS Server

      Normally speaking, your device connects to a DNS server provided by your ISP (Internet Service Provider). If you’re having DNS issues, it might be because this server is misbehaving. The solution here is to switch to a different server.

      Organizations like Google and Cloudflare provide public DNS servers that anyone can use. Some people prefer using these servers because they can speed up page loading. In other cases, people use an alternative DNS server for privacy reasons.

      Some of the most popular alternate DNS providers include:

      • Google: 8.8.8.8 and 8.8.4.4
      • Cloudflare: 1.1.1.1 and 1.0.0.1
      • OpenDNS: 208.67.222.222 and 208.67.220.220

      Here’s how to switch your DNS server address.

      Windows:

      1. Navigate to Control Panel > Network Connections > Properties. 
      2. Under Preferred DNS server, enter the IP address of your preferred DNS server.
      3. Under Alternate DNS Server, put in the address of your backup server, and save your changes.

      screenshot of windows IPv6 properties calling attention to the use the following DNS server addresses text boxes

      Mac:

      1. Navigate to System Preferences > Network and select your primary internet connection in the sidebar.
      2. Click Details (or Advanced on older Macs) then select DNS.
      3. At the bottom of the DNS servers list, click the + button and enter your new DNS address.
      4. Make sure to click Apply before leaving the Network screen.

      screenshot of windows IPv6 properties calling attention to the use the following DNS server addresses text boxes

      iOS Mobile

      1. Navigate to Wi-Fi settings (they might be under Network & Internet)
      2. Find the DNS settings…
      3. On iOS, tap the i icon, then Configure DNS.
      4. Select Manual < Add server to update DNS.

      screenshot of an ios mobile phone configure DNS settings screen

      Android Mobile

      1. On Android, open Settings > Connections > More connection settings.
      2. Tap on “Private DNS” and choose “Private DNS provider hostname to change the DNS server.

      screenshot of an android private DNS setting screen

      Once you have finished changing your DNS server settings, restart your device before trying to access the internet. This will ensure that the new DNS settings are adopted, giving you a chance of beating those pesky errors!

      11. Update Network Adapter Drivers

      A network adapter driver is a piece of software that allows an operating system to communicate with a network adapter. This is the small card in your device that handles internet connections.

      If the driver software isn’t regularly updated, it can start to create problems. Likewise, a driver that is corrupted, or incompatible with a new network adapter, is likely to create headaches.

      One possible symptom is — you guessed it — the kind of DNS error we’re trying to fix.

      Many devices update their network drivers automatically; macOS handles this chore behind the scenes. On Windows, you can take control of the adapter settings yourself:

      1. Visit Device Manager.
      2. Right-click Network Adapter.
      3. Select Update Drivers from the drop-down menu.

      If possible, it’s a good idea to connect to the internet via an Ethernet cable when updating your drivers. The reason is simple: you’re updating the piece of hardware you need in order to download the update. Interruptions due to poor Wi-Fi signal can mess up the process.

      Once you have updated your drivers successfully, restart your device and see if DNS is working properly.

      12. Disable Secondary Connections

      Some devices have more than one network adapter. For example, wired and wireless connections use different adapters.

      In most cases, you only need to use one adapter at a time. Switching off all secondary connections is a good idea because they can cause problems with DNS requests.

      To do this, visit the network settings on your device and turn off all live connections other than the one you’re using (e.g., If you’re connected via Wi-Fi, disable the Ethernet connection.)

      It’s also worth checking whether you have a virtual network adapter running. This is a digital service that allows multiple connections via the same physical adapter. It’s a feature used by VPNs, allowing you to tunnel some traffic through the private network, and some through a regular internet connection.

      To make sure a misbehaving virtual network adapter isn’t causing your problems:

      1. Open Control Panel > Network Connections.
      2. Right-click on the virtual adapter you want to switch off, and select Disable.
      3. Confirm you want to disable the adapter. This will take it offline.
      1. Open System Preferences > Network.
      2. Select the virtual adapter in the left sidebar, and click the gear icon.
      3. Select Make Service Inactive to disable the adapter.
      1. Find the VPN settings on your device.
      2. Tap the i or gear icon.
      3. Switch off the adapter.

      Once again, try to reload the malfunctioning page to see if the DNS error message has cleared.

      13. Disable Peer-To-Peer Feature (Windows)

      No luck? Don’t worry, there is one more potential fix you can try.

      Windows has a peer-to-peer feature, which helps to reduce the amount of bandwidth needed while downloading updates. Rather than forcing your device to swallow all the data in one big lump, this option splits updates into individual pieces. The PC that receives these pieces can then share them with others on the same network.

      This is obviously a useful feature. But as you might have guessed already, Windows P2P can interfere with the DNS lookup process. Switching it off can help you to diagnose errors:

      1. Navigate to Settings > Windows Update.
      2. Next, click on Advanced Options > Delivery Optimization.
      3. Toggle the switch labeled Allow downloads from other PCs.

      screenshot of the windows delivery optimization settings screen found under windows update where you can toggle allow downloads from other PCs on and off

      You will then need to restart your computer to test, once again, whether the DNS error has cleared. Fingers crossed!

      Frequently Asked Questions

      Still have questions? You’ve come to the right place. Here’s a little extra detail on fixing your DNS settings, and a closer look at why failures happen:

      How Do You Reset Your DNS Server?

      After following the various troubleshooting steps above, you may decide that you want to go back to the domain name servers you originally had.

      To achieve this, simply retrace the exact steps mentioned in #10 — but this time, select your current DNS servers and press the little minus button to remove them. After a restart, your device should then revert to the default ISP DNS servers.

      What Causes A DNS Failure?

      In simple terms, a DNS failure happens when your browser cannot convert a domain name to an IP address. However, there can be many different underlying causes.

      The DNS process offers access to over 1 billion internet hosts. That’s one mighty “phone book.” So, it’s almost inevitable that the system will have some flaws.

      Most DNS problems that people encounter are caused by issues with internet access or software on their device. Actual failures are most commonly caused by server outages or incorrectly configured domain names.

      Set Up Your Site Correctly With DreamHost

      If you want to avoid seeing DNS errors pop up on your website, you might want to switch to DreamHost.

      Our hosting panel makes it really easy to configure your site correctly and manage all your domain names on a single page. If you ever get stuck, our Technical Support team is available 24/7 to provide help — and that’s on every single plan.

      Sounds good? Sign up today to give it a try for yourself!

      Get Content Delivered Straight to Your Inbox

      Subscribe to our blog and receive great content just like this delivered straight to your inbox.

      Advanced Troubleshooting DNS Problems


      The most common DNS error is a simple typo, whether it’s from the client or the server. Typos and other incorrect DNS data cause many problems. Even when data is correct, DNS can still be a difficult protocol to troubleshoot.

      The DNS process starts at the client, which queries a specified upstream DNS server. The upstream DNS server could already have the answer in its cache. In which case, an IP address is answered and the query is resolved. If not, it queries further upstream until a successive answer is given, which is authoritative for the query. The Top Level Domain (TLD), such as a .com, .net, or org, may be the root authority for a query. Authoritative servers on a local network may also be the correct resolver.

      Possible causes of unsatisfied queries include:

      • No network circuit path from the client to the specified DNS server.
      • The specified DNS server might not have the query credentials needed.
      • The cached information on the specified DNS server could be out of date.
      • The specified DNS server may have no upstream path to a TLD server.

      Fortunately, there are a variety of tools available for Windows, macOS, and Linux used to troubleshoot DNS problems. Most DNS troubleshooting tools focus on tracing the circuits to a DNS resolver or querying DNS servers for a correct response.

      Tracing the Resolver Network Circuit

      Clients must be able to reach the DNS server with a query. The most common failure is an interruption in the network circuit between the client app and the desired DNS server.

      Each client declares a default DNS server for DNS queries. If the address of the default DNS server is incorrect, or points to an unavailable resource, there can be no resolution to the request. In this case, the requesting application receives an error, or simply hangs. The IP address of the default DNS server must be known to troubleshoot further.

      The IP address of the default DNS server is found in the properties of the network adapter in use. To find yours, follow the instructions below for your operating system:

      Windows

      1. Right-click the network icon in the Notification Area of the Taskbar.

      2. Choose Network and Internet Settings.

      3. Select your network adapter.

      4. Scroll down to reveal the settings for that network adapter.

      macOS

      1. Click the network icon in the Menu Bar.

      2. Click Network Preferences.

      3. Select your network adapter.

      4. Click Advanced.

      5. Click DNS to reveal the settings for that adapter.

      Linux

      In Linux, the location of the desired DNS server depends on the values set in the resolver configuration file located at /etc/resolve.conf.

      To find these values via the command line, enter:

      cat /etc/resolve.conf
      

      To find these values via the GUI in Ubuntu 22.04 LTS:

      1. Click network icon in the GNOME Panel.

      2. Select your network adapter.

      3. Click <adapter/connection/device> Settings.

      4. Click the gear icon next to your chosen adapter/connection/device

      Knowing the desired address helps trace the circuit to determine if the desired DNS server can be reached.

      Circuit Testing with Ping

      Troubleshooting the network communications circuit uses common tools like ping. Many queries fail because there is no network circuit to the desired DNS server. The ping command line tool is universal to all operating systems and does not require administrative rights.

      Open a command line and use ping to determine if the IP address responds. In this case, the public DNS server for Cloudflare (1.1.1.1) is cited:

      ping 1.1.1.1
      

      Or:

      ping cloudflare.com
      

      When a reply is returned, queries can be made to the server, in which case, skip to the next section.

      If there is no reply using ping, then the circuit is unusable and the requested resolver is not responding. This can be because it’s under attack, dead, or offline. Specify another resolver/DNS server and repeat the attempt.

      An unusable circuit, or route to a DNS server, means that an Internet connection is down for the host making queries. If the circuit is up, another DNS server can be used, and must be placed in the host’s settings. Reset the host to restart the network stack and read the new DNS server entry. Such alternate DNS Internet servers are 1.1.1.1 for Cloudflare, and 8.8.8.8 for Google.

      Note

      The traceroute command line tool is also handy in network circuit analysis. It uses either an IP address or a Fully Qualified Domain Name (FQDN) to show latencies between the host and the desired IP address/FQDN.

      Tracing Resolvers with NSLookup

      Windows, macOS, and Linux contain the command line tool, nslookup (Name Server Lookup). It performs a query on a known address, using the default DNS resolver, unless another resolver is specified.

      nslookup google.com
      

      Renders:

      nslookup google.com
          Server:  one.one.one.one
          Address:  1.1.1.1
      
          Non-authoritative answer:
          Name:	google.com
          Addresses:  2607:f8b0:4004:c19::8a
                    2607:f8b0:4004:c19::71
                    2607:f8b0:4004:c19::8b
                    2607:f8b0:4004:c19::64
                    64.233.177.138
                    64.233.177.139
                    64.233.177.102
                    64.233.177.101
                    64.233.177.100
                    64.233.177.113

      Here, the default nameserver is Cloudflare.com’s public DNS server (one.one.one.one), with an IP address of 1.1.1.1. It uses a cached (non-authoritative) answer for the queried server (google.com). It then renders three lines of IPv6 addresses and six lines of IPv4 addresses.

      When there’s a working network circuit available, nslookup permits changing the nameserver so that entries among differing nameservers can be compared. When a TLD FQDN entry is changed, it can take as long as 48 hours to be uniform among nameservers/resolvers. This is because non-authoritative servers cache entries using a Time-To-Live (TTL) variable for speedier response. The answer is delivered from cache, without looking up the answer on the next higher-level server. When the cache expires on DNS servers/resolvers/nameservers, a request from a higher authority renews the cached and delivered answer.

      Start of Authority (SOA)

      Every domain used publicly in DNS has a registrar. The registrar keeps a record of ownership, which may not be visible to the public. The entry in this record that must be made public is the IP address(es) of its nameservers. The nameservers/resolvers, in turn, are the guardians of the DNS for TLDs.

      An organization that hosts a domain generally also contains its nameserver, and is the SOA for the domain and any subdomains underneath it. TLD resolvers such as .com, .net, and .org, are highly controlled. They are only accessible through other servers using the DNS Security Extensions (DNSSEC) authentication and security protocol.

      Hosting organizations like Linode may also use other Content Distribution Networks (CDNs) who provide a presence where heavily-used sites manage IP and DNS access. CDNs are not covered by this guide, because their troubleshooting often requires tools that only the CDNs can provide. Nonetheless, these sites must respond appropriately when a host makes a query.

      Dig

      The most popular client-side DNS query tool beyond nslookup is dig (Domain Information Groper). The dig app must be downloaded to Windows as part of the
      bind package, which also includes an optional DNS server. The dig command is included with most versions of macOS and Linux.

      The dig tool allows specific DNS records to be queried. This includes MX (mail), A records (domain), TXT records (specifically recorded details), and other host records included in the SOA nameserver.

      An example of the dig output shows its command line configuration:

      dig linode.com
      

      The output looks similar to:

      ; <<>> DiG 9.16.30 <<>> linode.com
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54592
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
      
          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags:; udp: 1232
          ;; QUESTION SECTION:
          ;linode.com.                	IN  	A
      
          ;; ANSWER SECTION:
          linode.com.         	300 	IN  	A   	69.164.200.202
          linode.com.         	300 	IN  	A   	72.14.191.202
          linode.com.         	300 	IN  	A   	72.14.180.202
      
          ;; Query time: 62 msec
          ;; SERVER: 1.1.1.1#53(1.1.1.1)
          ;; WHEN: Thu Jul 14 17:11:03 Eastern Daylight Time 2022
          ;; MSG SIZE  rcvd: 87

      Options for the dig command include:

      • +trace, which queries DNS servers to the SOA.
      • ANY, which finds ALL records, not just the default A record.
      • +f <filename> which calls the hosts listed in the specified file.

      The SOA can be found, and the path to it queried, to see if records match. This allows DNS resolvers along the path to the SOA to be adjusted for longer/shorter TTL caching. This accommodates records that change frequently, such as DynamicDNS records in Active Directory environments.

      Domain Transfers

      When a domain transfer occurs between nameserver registrations, it takes time to propagate to the hundreds of thousands of resolvers that might be contacted. The dig command is the handiest tool to find outdated cache or incorrect entries.

      The Hosts File

      Windows, macOS, and Linux look to a hosts file before trying to resolve a DNS address. The hosts file pre-dates DNS in many ways, and takes precedence over DNS or attempts to use a resolver.

      When present and filled in, the hosts file is the first resolver in any host. In Windows, this file is located in the \system32\hosts entry. On macOS and Linux, it’s located in the /etc/host file.

      The hosts file is canonical, meaning that it overrides any resolver and cannot be violated. When tracing odd DNS access problems, look for the presence of this file, and use a text editor to examine its contents. Entries may be administratively placed to prevent access to specific sites. It is sometimes used as a “private DNS” to control system behavior and prevent typos from permitting access to typo-based malware sites. The hosts file must be altered to allow subsequent access through a resolver to such sites.

      Walled Gardens and Captive Portals

      Walled Gardens and Captive Ports are terms for the same environment. Essentially, barriers presented by network access providers, such as “Free WiFi” services deployed in public spaces, shops, schools, and government facilities. These offerings are controlled through an access control host/router to a network, whether wired or wireless. All DNS or IP address calls are intercepted, and focused to an authorization device.

      After supplying sufficient credentials, a user is provided either confined or open access. Within the Captive Portal or Walled Garden, DNS calls are often intercepted and routed through local or cloud-based DNS servers/resolvers. They resolve requests using their own entries, which may not be the public DNS entry for a user.

      The “wall” in the Walled Garden provides confined access, typically limiting access to social media, adult websites, or other sites chosen by the provider. Although browser DNS-over-HTTPS protocols can sometimes “leap” over, or bypass, these walls, some browsers do not support this protocol.

      To regain access, re-load the network stack and use a public resolver like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8.

      DNS Poisoning

      The answers provided by DNS servers are listed in the DNS server/resolver’s tables. Access to these tables is usually highly limited. When DNS is correctly configured for host security, it limits how DNS entries can be changed.

      It’s possible to poison DNS servers intentionally with spurious entries in an attempt to hijack browser activity. When performed by bad actors, these entries can focus browser requests to malware, crypto routines, or competitors.

      Administrators regularly use dig and a file of test hosts to compare changes in entries. The value of the test is to show when the list of hosts has changed, and for what reason. A changed address in a popular site may mean its entry has been hijacked upstream, locally, or even at a TLD server. It may also mean the IP address has simply been changed administratively. Poisoned entries must be deleted where possible.

      Hosting Provider Problems

      A hosting provider, or the domain registrar, can flush DNS cache, including informing upstream/downstream providers where they’re connected. Administrators making changes in DNS entries face a problem with the cache TTL/life in both up and downstream servers. Changes can be quick to propagate where CDN and other services, such as Akamai and Cloudflare, are the stored address for downstream servers.

      Records

      Each host provides a mandatory A record that points to the IP of the receiver of domain targets. The CNAME record provides an alias for queries, allowing aliases for “www” or other common domain prefixes.

      DNS MX records point to mail. Most hosting providers run mail through an application, such as cpanel. Email entries for a domain are rejected because of missing mail-focused domain keys used in:

      • Transport Layer Security (TLS)
      • DomainKeys Identified Mail (DKIM)
      • Sender Policy Framework (SPF)
      • Domain Message Authentication Reporting and Conformance (DMARC)

      These entries must be valid, and the mail engine used must comply with the DNS records for the domain.

      Host provider email records are entered in the provider’s DNS record for a domain, or maintained separately by a domain administrator.

      Alterations

      Some host providers and registrars lock DNS records so that they cannot be changed by fraudulent or unauthorized access. To prevent hijacking and fraud, the locks placed on records require obtaining a key, providing credentials, or other verification obstacles.

      The authentication credentials needed to change DNS records should be stored carefully. A re-authentication attempt usually requires time and multiple methods of authentication to obtain. Domain hijacks occur when credentials are guessed, spoofed, or heavily attacked.

      Conclusion

      Simple typos are a huge problem. So are network outages that initially appear to be DNS problems. Verifying accuracy and the network path fixes many DNS outages. User/host configuration problems, especially an incorrect default DNS/resolver, can also be quickly checked.

      When resolvers must be checked, the toolkit can be simple. Much information can be revealed about the listings inside resolvers using nslookup and dig. Data can be compared from period to period.

      Complying with a hosting provider’s documentation allows you to keep complete records that cooperate with the provider, their services, and email.

      DNS servers are not invulnerable. They can be poisoned. It’s good practice to check important records on a periodic basis to test listing integrity, especially before users fill the support email box.



      Source link

      Register Custom DNS Name Servers


      DNS name servers (also referenced as the single word nameservers) are the backbone of the Domain Name System. They are the servers that host a domain’s DNS records, which map human-readable domain names to IP addresses.

      When registering a new domain or configuring an existing domain, you must set the FQDN (fully qualified domain name) of each name server you intend to use. This is done through your domain’s registrar. You can typically chose to use your registrar’s name servers, a third party name server, or a self-hosted name server. If you decide to use your registrar’s DNS service or a third party DNS service, that service provides you with the FQDNs for its name servers. For example, the name servers for Linode’s
      DNS Manager are ns1.linode.com through ns5.linode.com.

      If you instead decide to use your own custom name servers, you first need to create glue records on your registrar for the FQDN you wish to use with each name server. In tandem with glue records, you must also set corresponding A records with your domain’s DNS records. The last step is to configure your domain to use your new custom name servers.

      1. Configure Glue Records
      2. Create A Records
      3. Change the Name Servers for Your Domains

      This guide covers how to register a custom name server and assumes you have already configured a self-hosted DNS software on each system you intend to use.

      Before You Begin

      • You must have at least one registered domain name and be able to access the domain’s registrar. Within this domain name, determine the FQDNs you’d like to use for your custom name servers. Many applications and registrars require at least two name servers and they are typically formatted as ns1.example.com, ns2.example.com, and so on, replacing example.com with the domain you’d like to use.

      • For each name server you wish to configure, deploy your preferred DNS software on a Compute Instance or any publicly accessible server. If you are using cPanel, Plesk, or other software that automatically configures your DNS software, make sure it is properly installed.

      Why Use Custom Name Servers?

      Third-party DNS services, like Linode’s DNS Manager, are very reliable, feature-rich, highly available, and protected against attacks. For most applications, these services are preferable to self-hosting custom name servers. As with many custom self-hosted solutions, the effort to build and maintain a custom DNS name server might not be worthwhile. That said, there are some compelling reasons to chose self-hosting your own custom name servers over utilizing an existing DNS service.

      • Software integration: Many popular self-hosted software solutions, including cPanel and Plesk, can deploy their own custom name servers to automatically manage DNS records. When a user makes a change in the software, the associated DNS records are automatically created or updated without a user needing to manually configure them.

      • Greater control: A primary reason for using any self-hosted solution is to gain more granular control over a system. In the case of name servers, you can use any
        name server software supported by your system and take advantage of all of its features.

      • Vanity/Branded domain: Some third-party DNS services allow you to use your own domain instead of their standard name server domains for branding purposes, but not all have this feature. When self-hosting your own name servers, you can use whichever domain name you wish.

      Configure Glue Records

      When a domain name is resolved, your system’s DNS resolvers first query the root name server. The root then provides the name servers for the domain’s top-level domain (TLD), such as .com or .net. Then, a query is sent to the TLD name servers, which returns the authoritative name servers for the domains. The DNS resolver can then finally query an authoritative name server for the DNS record it needs. This works fine for most domain queries, such as when the DNS records for example.com are hosted on the name server ns1.linode.com. But this breaks down for name server domain resolution, where the record for ns1.example.com is hosted on the ns1.example.com authoritative name server.

      To overcome this circular resolution, glue records are needed. Glue records are set within the domain’s registrar and can map the custom domain of a name server to the IP address of that name server. To configure glue records, follow the instructions below.

      1. Obtain the public IPv4 addresses for each of your custom name servers. If they are hosted on a Linode Compute Instance, see
        Managing IP Addresses on a Compute Instance.

      2. Log in to your domain’s registrar.

      3. Configure a glue record for each custom name server. This maps the full domain of a name server to the IPv4 address for that server. The name of this feature and the instructions for setting a glue record depend on the registrar you are using. Here are the instructions for a few popular registrars, though any registrar that supports glue records can be used:

        Some registrars may require you enter the entire FQDN of the custom name server (such as ns1.example.com), while others only need the subdomain (such as ns1). Additionally, registrars like Namecheap pre-populate a dropdown list with common name server hostnames. In this case, you can likely select from the predefined list or type your own.

      After this is complete, your registrar sends the glue records to the TLD name servers associated with your domain. This process can take up to 24 hours to complete, though it is generally finished within a few minutes to an hour. See
      Verify DNS Changes.

      Create A Records

      In tandem with setting up glue records at the registrar-level, you should also create A records within your custom name servers itself. Many self-hosted software applications that manage DNS records, such as cPanel and Plesk, do this automatically – provided they are configured to use a self-managed DNS service. If this is the case, you can skip this section – even if you have yet to install the software.

      1. Log in to the administration panel or terminal for your DNS software on your custom name server.

      2. Within the domain zone file, add an A record for each custom name server. This record should point the hostname of the custom name server (such as ns1.example.com) to the IPv4 address of the name server.

      Since these steps vary greatly depending on your DNS software, please reference the official documentation for that software. For instance, for users of BIND9 (the most popular DNS software), see
      Configurations and Zone Files.

      DNS records can take up to 24 hours to fully propagate, depending on several factors – including the TTL setting, the DNS service you are using, and the caching system on the DNS resolver. In general, you can expect to see the updates within 5 minutes to an hour. See
      Verify DNS Changes.

      Change the Name Servers for Your Domains

      Once the custom name servers have been successfully registered, you can begin using them to host DNS records for your domains. To do this, add the domain inside your custom name server and then update the domain’s registrar to reflect the new authoritative name servers.

      1. Log in to your domain’s registrar.

      2. Update the domain’s name servers to use your new custom name servers (such as ns1.example.com and ns2.example.com). The name for this setting various among registrars, but it is commonly called external or custom name servers.

      After configuring the new authoritative name servers for a domain, they are sent to the TLD name servers associated with that domain. This process can take up to 24 hours to complete, though it is generally finished within a few minutes to an hour. See
      Verify DNS Changes.

      Verify DNS Changes

      Once you’ve made the changes that are needed, you can verify that the records are correct and have propagated to the appropriate servers by following the instructions below.

      1. Obtain the TLD name servers by running the following dig command, replacing com with the TLD for your domain.

        dig +short com NS
        

        This returns a list of TLD name servers.

      2. View the DNS records a particular TLD name server has for your domain by using the command below. Be sure to replace a.gtld-servers.net. with whichever TLD name server you wish to query (leaving the @ and trailing .) and example.com with your domain.

        dig +norec @a.gtld-servers.net. example.com
        
      3. To verify the glue records, examine the output’s ADDITIONAL section. There should be an A record for each of the glue records you’ve configured, pointing your custom name server domain to your IP address.

        ;; ADDITIONAL SECTION:
        ns2.example.com.	3600	IN	A	192.0.2.36
        ns1.example.com.	3600	IN	A	192.0.2.37

        If you do not see a similar output, you can query other TLD name servers. It may be that the changes have not yet propagated to all of them.

      4. To verify your domain is using your new name servers, examine the AUTHORITY section of the output. This should be a list of all NS (name server) records, which map your domain to one or more name servers. All of the name servers configured for your domain should appear here, though they are typically displayed in a somewhat random order.

        ;; AUTHORITY SECTION:
        example.com.		3600	IN	NS	ns2.example.com.
        example.com.		3600	IN	NS	ns1.example.com.
      5. Both the glue records and name servers can also be verified by running a dig +trace command, as shown below. Replace example.com with your domain and ns1.example.com with your custom name server. Repeat this command as needed for each name server.

        dig example.com +trace +additional | grep ns1.example.com
        

        Within the output, you should see at least one NS record that defines your custom name sever and an A record for your name server that points to the correct IP address of your server.

      6. The A records for your custom name server’s domain can be verified by running the following dig command, which confirms the changes have propagated to the DNS resolver used by your system. Replace ns1.example.com with the domain of your name server.

        dig ns1.example.com A +short
        

        This should output the IP address configured within the A record for that domain.



      Source link