To be more precise, the domain name resolution is a translation process between the domain name that people use while writing in their browsers and the site’s IP addresses. You need the IP address of a site to know where it is located and load it.

A website could have both IPv4 and IPv6 addresses, and the DNS resolution of a domain name will ask for both of them. The IPv4 address will come in the form of a DNS A record, and the IPv6 will come in a DNS AAAA record.

Let’s get into the details, and see how it works, shall we?

Domain name resolution – Why is it important?

In the world of the Internet, the addresses don’t contain streets and cities. They have numbers and symbols. There are two types of addresses: IPv4 and IPv6. In order to enter a particular website, the user needs to get its IP. Instead of remembering all of the IPs of every website, we simply need to remember the domain name. The domain name is usually not hard to remember, and this makes it easier. When the user types the name of the website, the process of the domain name resolution starts.

So let’s proceed and explain the whole process of DNS resolution.

DNS resolution process

The browser of a user needs to get the IP and sends queries to the name servers. This process involves domain name resolvers. The first answer that your browser will get is the root server, then the TLD (top-level domain). The servers with the TLD of the website you want to visit (com, net, or another) will refer your queries to the next step in searching authoritative servers that know the exact IP address of the domain name. Then the domain name will be resolved.

Let’s breakdown the DNS resolution step-by-step: 

1. A user is typing a domain name like cloudns.net into their browser. The user needs an A or AAAA DNS record to resolve the domain name.
2. If your device’s cache has the IP address of cloudns.net, the domain name resolution will finish here, and the user will be able to open the website. But, if it does not, there will be more steps. The devices keep DNS records for visited sites, depending on the TTL (Time to Live) values of those DNS records. After the time they indicate, they will be deleted, and a new query needs to be performed.
3. If your computer doesn’t have the needed IP address, it will search for the answer by performing a DNS resolution query. The next destination on the way will be the recursive DNS servers of the internet services provider. They also keep a cache with DNS records of domain names that users have accessed. If the desired site’s DNS records are still there, the user will get an answer to its query and access the site. If not, there will be a series of interactive DNS queries to find the answer.
4. If the domain name resolution didn’t finish with the previous step, the recursive nameserver would search for the answer. The next step will be to ask the Root server, which is indicated with a “.” sign after the TLD (top-level domain). The Root server does not have an answer about the exact domain name, but it will provide one for the part it is responsible for – it will indicate all the nameservers for the TLD that we asked for. In our case, it will show the nameservers of .net.
5. The TLD DNS servers will have the answer of which exactly are the authoritative nameservers for the domain you are searching. The TLD servers of .net will have that information for all of the domain names that finish with .net. They will return that answer so the query can continue.
6. Now that we know where the authoritative nameserver of the domain name we want is, we can ask and get the A and AAAA records to understand the site’s IP address.
7. The Authoritative nameservers of the domain name will provide the DNS records, the DNS resolution will be made. The recursive nameserver of our ISP and our device will both save the DNS records that we obtained based on their TTL values. That way, if we soon want to visit the site again, we will save time and access the site faster.
8. Visit the site. Now with the DNS record already obtained, the user can access the site.

Do we need to care about it?

The answer is yes! For humans, the DNS resolution process is essential. And if something goes wrong, the use of the Internet by regular users would be extremely difficult. 

So we should be concerned about DNS resolution for two reasons:

1. The first one is the importance of the speed. When a user accesses your website, the DNS resolution is the first thing that happens. If your page takes too long to load and access, the user will probably leave. That’s why this process needs to be performed fast.
2. The second one is the availability. The nameserver in charge of handling your domain name needs to be trustworthy. A backup DNS service is a great technique to guarantee that your domain is always reachable by your customers.

What to do if DNS resolution is not working?

1. Check your internet connection. Many times when the domain name resolution fails, the main reason is that you are not connected to the Internet. Check your connectivity and restart your router.

2. Verify the problem is DNS-related. Before diving into DNS-specific solutions, confirm that the issue isn’t related to general connectivity. Try accessing the site with its IP address instead of its domain name. If this works, the problem likely lies with DNS resolution.

3. Obtain DNS server address automatically. Go to the network adapter and open the properties. Then search for the Internet Protocol Version 4 (TCP/IPv4) and open its properties. From there, you can click on Obtain DNS server address automatically. This will allow your computer to receive the DNS settings from the DHCP server.

4. Release and then renew the DHCP IP address. There could be an IP address conflict because of the DHCP server. What you can do as a user is to give up the IP address lease. You can do that with a command from the Command Prompt:

ipconfig /release

After that, you can renew your IP address with the following:

ipconfig /renew

Now your connectivity should be restored.

5. Flush the DNS cache of your device. You can do that by accessing the Command Prompt (as an administrator) and performing the following command:

• On Windows, open Command Prompt and type: ipconfig /flushdns
• On macOS, open Terminal and type: sudo killall -HUP mDNSResponder
• On Linux, the command varies by distribution, but a common one is: sudo systemctl restart nscd

If you had a previous IP address of a domain that is no longer available, now you have deleted it. The device performs a DNS resolution again, and it should get the new IP address.

6. Disable any VPNs or proxies. VPNs and proxies can redirect your network traffic through different servers, which may cause DNS resolution issues. Try disabling them to see if that resolves the issue.

7. Check your hosts file. The hosts file on your computer can override DNS and manually map domain names to IP addresses. Ensure there are no incorrect entries that could be causing conflicts.

• On Windows, this file is located at C:\Windows\System32\drivers\etc\hosts
• On macOS and Linux, it’s at /etc/hosts

8. Update your DNS records. If you’re managing a domain and have recently changed DNS records, it might just be a matter of waiting. DNS propagation can take up to 48 hours.

9. The last resort is to contact your ISP and tell them the problem. There is a chance that it is related to its equipment or software, and it can fix it. Or maybe it is blocking some websites on purpose. You can at least try to find an answer from it.

DNS Monitoring: Keeping Resolution on Track

DNS resolution is a silent yet critical driver of the digital world, translating domain names into IP addresses. DNS monitoring services amplify this process’s reliability by offering continuous oversight. These services rapidly identify and help rectify resolution delays or failures, ensuring users can always reach their online destinations.

DNS monitoring checks are essential in validating the seamless operation of DNS resolution, crucial for uninterrupted internet navigation. By querying specific hostnames against expected responses, these checks can swiftly flag a DNS resolution process as operational (UP) or problematic (DOWN).

For example, monitoring might run a command like:

If the response matches the expected IP, the DNS is considered healthy. This proactive measure ensures DNS performance remains robust, which is vital for network reliability and the overall user experience.

In the event of discrepancies, debugging tools, including Traceroute, assist in tracing the issue to its source, allowing for quick resolution. Thus, integrating DNS monitoring checks is a strategic move to bolster network stability and maintain consistent service delivery.

Why do we need recursive servers?

Theoretically, authoritative nameservers are enough to keep the DNS resolution process running. You can think that the only kind of DNS servers we need is authoritative, but imagine how much load they will need to take if all the complete queries get to them.

For decreasing the load and increasing the speed, there are recursive servers (DNS resolvers) that keep the DNS records with the information needed to access a particular website for a defined period of time. This time is called TTL (time to live), and the process is named DNS cache. There are such recursive servers in the internet service providers that keep the information for many websites for the period of time defined by the TTL.

To make it easier to imagine, it generally functions as a name server, acting as a go-between the customer and the authoritative DNS server. However, without it, you won’t be able to access any website that you want to reach on.

Why DNS Resolution Times Matter and How to Improve Them

DNS resolution times are a key factor in overall website performance, as they determine how quickly a user can begin accessing a webpage. If this process takes too long, it can significantly delay page load time, creating a poor user experience. Delays have a negative impact on e-commerce and business sites, where faster loading speeds directly affect sales and user engagement.

Several factors influence DNS resolution speed are the following:

• Server Proximity: The closer the authoritative DNS server is to the user, the faster the response. Many DNS providers use Anycast routing, which directs queries to the nearest server, reducing latency and speeding up resolution times.
• Caching Efficiency: When DNS records are cached effectively, repeat queries can be answered instantly from the cache, avoiding the need for a full DNS lookup. Time to Live (TTL) values determine caching duration – longer TTLs reduce query frequency for stable sites, while shorter TTLs allow for more frequent updates.
• DNS Provider Choice: A reliable, high-performance DNS provider often has better infrastructure and caching policies, as well as multiple server locations worldwide, which can reduce resolution time. Providers typically offer faster, more secure DNS resolution than ISP default options.

How DNS Resolution Works with IPv4 and IPv6 Addresses

When domain resolution occurs, it can return either IPv4 or IPv6 addresses or both, depending on the server’s configuration and the client’s capability to use either protocol. This flexibility ensures that DNS can adapt to the gradual transition from IPv4 to IPv6, supporting both legacy systems and modern networks.

The two address types serve distinct purposes:

• IPv4 (Internet Protocol version 4): IPv4 is the older protocol that uses 32-bit addresses, resulting in about 4.3 billion unique IPs. DNS A records are responsible for mapping domain names to their corresponding IPv4 addresses. However, with the explosive growth of internet-connected devices, IPv4 addresses are in short supply, which is where IPv6 steps in.
• IPv6 (Internet Protocol version 6): IPv6 was developed to provide a vast address space, using 128-bit addresses that allow for 340 undecillion unique IPs. This address space is critical for the future of the internet, as more devices connect daily. DNS AAAA records are responsible for returning IPv6 addresses for a domain. Additionally, the newer version of IP offers benefits beyond capacity, including better routing efficiency and improved security features.

Conclusion

DNS is a very useful system that saves a lot of time and makes our lives easier. After this article, you will know better what happens when you open a web page, how exactly the DNS resolution works, and what it means a domain name resolution.

The post What is Domain Name Resolution? appeared first on ClouDNS Blog.

Now let’s see the second word – propagation. To propagate, it means to spread ideas, opinions among people and places (Cambridge Dictionary). So DNS propagation is about spreading the DNS records’ changes through the vast network of DNS name servers.

What is DNS propagation?

It is the time it takes, from updating your DNS records in the Primary Zone in the Authoritative name server, and actually spreading this new information (a new DNS A record that points to a new host (IP address), change in a host and a service, or another) to all of the DNS recursive servers. When you make the changes in your DNS records, they will get instantly updated in the authoritative servers. It will take extra time, for the data, to be modified in all the recursive servers along the way, depending on the TTL values of the DNS records. The recursive servers have cache memory that temporarily stores the data.   

The connection passes through many recursive servers, including those in your internet provider (ISP). All of them have TTL (Time to live) which defines for how long they will keep the DNS cache with the DNS records. The DNS cache exists mostly for load balancing so that it won’t be so heavy on your nameservers and to make the whole process faster.

When a user uses their browser to open a web page for the first time, he or she will send a request all the way to an authoritative server. If it is not for the first time, the request will get an answer on the way in a recursive server, and if the data is still up to date, the user will get his answer quicker.

Basically, the DNS propagation depends on the TTL in the DNS records.

How much time does DNS propagation usually take?

The DNS propagation could take 48 hours or even 72 hours. It depends on the TTL values, and when was the last time your recursive DNS servers got their update, the name servers at TLD level, and the recursive servers at the ISPs. A recursive server won’t search for updates until the DNS records that it has in the cache memory expire.

Why the DNS propagation takes so long? 

4 factors really affect the DNS propagation speed:

1. The domain name registrar. When you buy a domain name, you get it from a domain name registrar. You will get a domain name with the TLD (top-level domain) you have chosen. The name servers will be there, and you will get their IP addresses. When you get a managed DNS, you need to make the change in this TLD’s name servers. The time it takes to update there is out of your hands and is usually up to 48 hours. 
2. The TTL values of the DNS records. This part we already mention a few times. The TTL value shows the time that recursive servers should keep the DNS records in their memory before updating. If you have the TTL value of an A record at 30 minutes, for example, it will take up to 30 minutes to propagate the change, depending on the last time it updated before.  
3. The recursive servers of the ISPs (internet service providers). Not all recursive DNS servers are the same. The ISPs have their own, and they could ignore the TTL values of your DNS records and keep them for longer. Why? Because they want to have less DNS traffic. So the ISPs recursive servers could be the bottleneck of your DNS propagation. 
4. The DNS cache of the users’ computers. When a visitor enters a website, the DNS records for this site will be saved on his or her computer, the time that the TTL value indicates. So, if you are a site owner and you want to visit your site, to which you recently change the IP address, you will need to flush the DNS cache. Then you can visit the site with its new IP address. The users will need to wait until the DNS propagation comes to them or flush the DNS tool.  

How to make the DNS propagation faster?

Yes, you can, and it is simple; you need to lower the TTL period of the DNS records. If you want to know more about it, you can read our article about TTL, where we recommend different duration for various DNS records. You will still need to wait for the expiry period that was set before. All the DNS caches need to expire and the recursive servers to refresh.

You can also force a zone transfer, and that way, push an update to all of the Secondary DNS servers. 

Just take into consideration that a lower TTL value for your DNS records will mean more DNS queries to the Authoritative name servers. This uses more server’s resources.

*Take a look at the previous point. You can’t control the DNS propagation when we are talking about the recursive servers of the ISPs and in the case of change on the TLD level.

How to check the DNS propagation?

It is an easy process. We will show you two ways, depending on your OS.

Windows 10
First, on Windows OS, you will need to open the Command Prompt. There you can use Nslookup on your web site. Just write:

 nslookup YOURWEBSITE.TLD

*Change YOURWEBSITE.TLD with your domain name.

It will perform a lookup for an A or AAAA record and show your website’s IPs, and you can see if they have already changed.

Linux (Ubuntu, Debian, CentOS, etc.), and macOS 

For Linux OS, you can perform a dig command. Open your Terminal, and you can write: 

“dig YOURWEBSITE.TLD” command. You will get similar result like the nslookup command on Windows OS – the A or AAAA record and the current IP addresses. 

*Put your domain name on the place of YOURWEBSITE.TLD.

ClouDNS Free DNS tool

With the ClouDNS Free DNS tool, monitoring DNS propagation has never been more straightforward. It allows you to check the propagation of DNS records by selecting the specific DNS records and the corresponding resolver. Whether you’re updating A, AAAA, CNAME, MX, or any other DNS records, ClouDNS’s tool provides real-time insights into the status of DNS propagation across different locations globally. It’s designed for both beginners and advanced users who require detailed DNS information with ease of use. Simply navigate to the tool, enter the domain you wish to check, and let ClouDNS handle the rest.

ISP and TTL impact on DNS propagation

When you initiate a web address lookup, the query traverses from your local ISP-provided DNS resolver through a network of servers, culminating at an authoritative nameserver. However, if ISPs opt to extend the caching of DNS records beyond their set TTL, this can lead to unnecessary delays in DNS propagation. Conversely, setting appropriate TTL values is crucial; a longer TTL will mean slower updates globally, while shorter TTLs can ensure rapid propagation for frequent DNS changes. For critical services, a TTL as low as 30 seconds is recommended, though testing for recognition of ultra-low TTLs by resolvers is always a prudent step.

How to Troubleshoot DNS Propagation Issues

If you’re experiencing delays or problems with DNS propagation, here are several suggestions to fix them:

• Verify the Correct DNS Settings: Ensure your DNS settings (A, CNAME, MX) are correct at your domain registrar.
• Check Nameserver Configuration: Confirm that your domain is pointing to the correct nameservers, especially after migrating to a new DNS provider.
• Use DNS Propagation Checkers: Use multiple DNS propagation tools to check whether your records are updating globally.
• Flush Local and Server Caches: Sometimes, local caches (on your device or web servers) can hold old DNS information. Flush DNS caches on both local machines and web servers.

How does DNS caching affect DNS propagation?

While DNS propagation primarily depends on the time taken for DNS updates to spread across all servers, DNS caching plays a significant role in the experience of end users. Recursive DNS servers, ISPs, and even local devices cache DNS records to avoid overwhelming the authoritative DNS servers with requests. This caching system can delay updates for users who already have cached records, even if propagation has occurred on the DNS network. To ensure users receive updates quickly, you can prompt them to clear their DNS cache or wait for the cache to expire based on the Time to Live (TTL) value.

How DNS Propagation Affects Website Visitors

DNS propagation can result in visitors seeing different versions of your website depending on their location and when they access it. During this process, some visitors may:

• Be directed to the old IP address of your website while others see the updated one.
• Experience temporary downtime or slow access, especially if they are served outdated DNS records from cached resolvers.
• Face email delivery issues if your MX records have changed, but their ISP has not yet updated its cache.

This uneven experience will gradually resolve as DNS records are fully propagated.

Conclusion

Now you understand the essence of DNS propagation and its significance. Patience is key during this process, but with the tools and insights provided, you can efficiently monitor the status of your DNS updates. Remember, effective DNS management is foundational to ensuring your online presence is robust and reliable.

The post What is DNS propagation? How to check DNS propagation? appeared first on ClouDNS Blog.

What is DNS cache?

The DNS cache (also known as DNS resolver cache) is a temporary DNS storage on a device (your computer, smartphone, server, etc.) that contains DNS records of already visited domain names (A records for IPv4 addresses, AAAA records for IPv6, etc.). It keeps those records, depending on their time-to-live (TTL). 

Each time you visit a website, its addresses will be saved inside this temporary database of records to facilitate a later revisit. 

Basically, the DNS cache is how your device is trying to save effort and time and skip a long DNS lookup by answering a DNS query with a DNS record that is already inside the temporary DNS cache. 

Why do we need a DNS cache?

We need DNS cache to get a faster response for DNS query for domain names that we have already visited recently in the past. 

Both the device that the user is using (his or her computer) and the multiple DNS resolvers that the request reaches, have DNS cache and they can resolve the domain if it is still in their cache memory. If not, the DNS query will need to follow the long way to the root server who will direct to the TLD servers and then they will direct to the authoritative name server for the domain name to finally get the answer.

What is TLD?

How does it work? 

Each time a user performs a DNS lookup, its device will first check inside the internal DNS cache that is part of the OS. There is a table of DNS records inside the DNS cache, their values, and the time they could be kept (TTL). The TTL value is set by the DNS administrator of each domain name, and it is the time limit that each DNS record has. After the time runs out, a new query is required. 

If the DNS query can be resolved from the DNS cache, the user will get their answer, and they can visit the site they desired. 

If not, the query will travel to a recursive DNS server. There are many DNS recursive servers out there. Like for example, there are inside your Internet Service Provider. They also have a cache that works in the same way. If the answer can be found there, the user will get it and resolve the domain. 

If not, the query will travel to an authoritative nameserver to get the answer. 

When it gets the answer, the DNS record or records will be saved in each of the DNS caches of the recursive DNS servers on the way and inside the user’s device, too, for the period that the TTL value indicates. 

Next time a new query starts for the same domain name, your device will repeat the process. If not so much time has passed, there is a high chance that the DNS record your device needs is still inside this temporary memory, and the query gets answered instantly. 

Types of DNS Caches

DNS caches operate at multiple levels in the network to speed up domain name resolution and improve performance. The main types include:

Browser DNS Cache: Web browsers like Chrome and Firefox maintain their own DNS caches to speed up browsing. This allows them to bypass the operating system’s cache and external DNS servers for previously visited sites. Browser caches can be cleared manually or typically reset when the browser is closed.

Operating System DNS Cache: The OS on your device caches DNS records for faster access during subsequent queries. If a record is found in the OS cache, it’s used immediately; if not, the query is forwarded to an external DNS resolver. This cache is more persistent than the browser’s and can be flushed using command-line tools.

ISP DNS Cache: ISPs maintain their own DNS caches to serve multiple users. When you query a domain, the ISP’s resolver checks its cache first. If the record is available, it’s returned quickly; otherwise, the resolver retrieves it from an authoritative DNS server.

Recursive DNS Server Cache: Recursive DNS servers, whether from ISPs or third-party services, cache records they retrieve from authoritative DNS servers. These cached records are used to answer subsequent queries, reducing the need to access the authoritative servers frequently and speeding up resolution.

How do I check my DNS cache?

You can see the DNS cache of your device with a very easy command on Windows, a bit harder on macOS and Linux.

Windows

1. Open the Command Prompt application by pressing windows+R.
2. Write cmd and press Ok.
3. Inside it, write the following command “ipconfig /displaydns”, and you will see all the DNS records of the sites you have visited. 

macOS

1. You will need to open the Console application.
2. There you will enter the following “any:mdnsresponder”.
3. Now go and open the Terminal application and enter the following command “sudo killall -INFO mDNSResponder”. You will be asked for your password. After that, you will need to get back to the Console application, and you will see the list of DNS records. 

Linux

There was no OS-level DNS caching, so it is a bit harder to display it. Depending on the software you are using, you might find a way to see it. For example, if you are using NSCD (Name Service Caching Daemon), you can see the ASCII strings from the binary cache file. It is located in /var/cache/nscd/hosts, so you can run “strings /var/cache/nscd/hosts” to display it.

If you are using Ubuntu 20.10, Fedora 33, or later, Systemd is responsible for the DNS. 

1. First, open the Terminal and write this command “sudo killall -USR1 systemd-resoved”.
2. Then run another command to export the log message to a basic .txt file with this command “sudo journalctl -u systemd-resolved > ~/dns-cache.txt”. 
3. Wait until the file is created and then open it with “less ~/dns-cache.txt.

Flush (clear) DNS cache

You can flush the DNS cache and that way to delete all of the DNS records from the local cache in your OS or web browser. Both can have different caches, so you will need to delete them both. 

Deleting the DNS cache might resolve problems with the domain resolution of a site or any other problem related to the outdated DNS records still in your cache. 

Cleaning it will also hide the list of the visited sites on a DNS level. That way, you can hide sites that you don’t want to show you visited. 

It can also be useful if you have any suspicion of DNS poisoning. In case somebody manipulated a DNS record in your DNS cache, deleting it will eliminate the potentially dangerous records. 

The negative part of clearing the DNS cache is that you will need to obtain the IP addresses of all websites that you need again. No site you recently visited will be saved after the DNS flush, and the first DNS resolution for each site will take longer. 

Let’s explore how to flush the DNS on different OSes and browsers. Remember, you will need to clean it both on OS level and browser level. 

Windows 

The process of flushing the DNS in Windows is straightforward. 

1. Open the Command Prompt application and type the following command: “ipconfig /flushdns”.
2. Upon successful clearance, you will see a confirmation message: “Windows IP Configuration. Successfully flushed the DNS Resolver Cache “. 

macOS 

1. On macOS, to delete the DNS cache, you will need first to open the Terminal application. 
2. Then you will need to enter this command “sudo killall -HUP mDNSResponder”, press Enter and write your password. You will also need to clear the DNS cache of the browser you are using. Check Safari if it is your choice. 

Linux 

There is no DNS caching by default on all of the Linux distros. 

If you are on the latest Ubuntu 20.04 LTS or later, you can open the Terminal application and execute the following command “sudo systemd-resolve –flush-caches”. You will need sudo privileges to do it. 

NCSD. If you are using NCSD, you will need to perform this command inside the Terminal “sudo /etc/init.d/nscd restart”. You will need to confirm your password for the command. 

DNSMASQ. The command for dnsmasq DNS cache is “sudo /etc/init.d/dnsmasq restart”, followed by password typing. It will restart the service. 

BIND. In the case of BIND, you will need a few commands: “sudo /etc/init.d/named restart”, then “sudo rndc restart”, and finally “rndc exec”. With that, you have to finish the DNS flushing. 

Google Chrome 

You need to put the following in the address bar “chrome://net-internals/#dns”. Then click on Clear host cache. IF you are using Edge, change chrome to edge from the previous text, and if you are using Opera change it to opera. 

Firefox 

1. Find the icon with 3 lines located on the top right corner and open Firefox’s menu.
2. Then search for Options (preferences). 
3. Inside it, you will see Privacy & Security. Click on it.
4. Go to History and click on Clear History by selecting Everything.
5. Finally, Clear Now. 

Safari 

1. First, Open the Safari browser.
2. There navigate to Preferences > Advanced. 
3. Click on “Show develop menu in menu bar”. 
4. Then go to the menu bar, Develop > Empty Caches. The shortcut is ⌥⌘E. You will need to restart the browser in the end. 

What are the reasons to flush DNS? 

There are various circumstances where flushing your DNS cache might be necessary, primarily related to security issues, technical glitches, or safeguarding personal data. Here are some of the main reasons.

1. You want to protect against DNS spoofing

DNS spoofing (DNS cache poisoning), is a type of attack where cybercriminals manipulate the information in your DNS cache to reroute you to incorrect websites. In some instances, they may lead you to a fake site that looks like the site you intended to visit, hoping you’d unknowingly provide sensitive data like your online banking credentials.

2. You receive a 404 error not found

Suppose you’ve stored the DNS data of a website, which later changes its domain or host. If so, it’s possible your locally stored DNS data may not get refreshed instantly, causing you to receive HTTP status code for Error 404: Not Found or see outdated versions of the site. While your DNS cache will ultimately be updated, you can expedite the process by clearing your DNS cache at your convenience. 

Suggested article: What are HTTP status codes 301 and 302 Redirects?

3. You see outdated information

Changes to DNS records might take 24 to 48 hours to spread across all global servers. This process is known as DNS propagation. Due to this, cached information may become old and lead to problems with websites or apps. Websites may not display correctly or may show old images and text. Cleaning your browser’s cache can help, but it’s not always a complete fix. 

4. You wish to maintain the privacy of your browsing activity

Most people associate internet user tracking with cookies. However, your DNS cache, which functions like a digital directory, storing data of your frequently visited websites, can also expose your online behavior. Regularly flushing your DNS cache is a proactive measure to prevent your browsing history from being accessible to data gatherers or potential online threats.

DNS spoofing (DNS cache poisoning)

As we explained, DNS spoofing is a malicious attack that aims to edit or replace DNS records inside the DNS cache of the targeted device (server or personal computer). The new or modified DNS records have changed data like the IP address, and they will resolve the domains to the new IP addresses. That way, the attackers can direct the traffic to a fake site, where they can steal the users’ personal data. Everything happens in the background, so if the fake site where the user is redirected really looks like the original, it is easy to cheat the user and get the result. 

The DNS spoofing can happen with a spam message that has an executable code that can perform the injection. 

Another way is the man-in-the-middle attack, where the bad actor is in the middle between the user and a DNS resolver. It passes modified information, pretending to be sending normal packets of data. The user gets DNS records from the attacker. 

A user can evade such an attack by using a VPN for encrypted communication, not clicking on suspicious messages, and opening infected attachments.

 Conclusion 

The DNS cache is a useful method of saving resources, both on your local system and on multiple servers. It is a fast method of DNS resolution that saves time for everybody. Yes, it is a target for DNS poisoning attacks, but there are various methods to protect the DNS cache. 

The post DNS cache explained  appeared first on ClouDNS Blog.

What is a flood attack?

A flood attack, often a form of Distributed Denial of Service (DDoS) attack, aims to overwhelm a system with superfluous requests, thus preventing legitimate requests from being fulfilled. The primary objective is to make the target service unavailable, either by consuming all its resources or crashing it altogether. Flood attacks exploit the limitations of a network’s bandwidth, memory, and processing power. By sending an excessive number of requests, they can exhaust these resources rapidly, causing severe disruptions. Attackers often use botnets, a network of compromised devices, to generate the enormous volume of traffic required for such attacks, making it harder to trace and block the sources.

How does it work?

A flood attack works by sending a massive volume of traffic to a targeted server, service, or network. This traffic often appears to be from legitimate users, which makes it challenging to distinguish and filter out. The target system gets overwhelmed by this surge in requests, which eventually leads to its degradation or shutdown. Flood attacks can be executed through various protocols and methods, such as TCP, UDP, ICMP, and HTTP, each exploiting different aspects of the network’s communication process. Advanced flood attacks may use randomization techniques to avoid detection and mitigation efforts, making them more sophisticated and harder to counter.

Why is flood attack dangerous?

• Disruption of service: The most immediate impact is the service disruption. Websites may become unavailable, networks may slow down, and businesses may experience downtime.
• Financial impacts: With downtime comes lost revenue. Especially for businesses that rely heavily on online services, a few minutes of inaccessibility can translate to significant financial losses.
• Damage to reputation: Continuous attacks can tarnish a company’s reputation, causing loss of customer trust and loyalty.
• Resource consumption: An immense amount of resources, both human and technological, need to be diverted to handle the aftermath of such attacks.
• Diversion: Sometimes, attackers use flood attacks as a smokescreen, diverting attention from a more covert breach or intrusion.

How to mitigate it?

• Monitoring: Continuous monitoring of network traffic can help in early detection of unusual traffic spikes, which may indicate a flood attack. Tools like intrusion detection systems (IDS) can be invaluable.
• DDoS Protection: DDoS protection services can help mitigate the effects of a flood attack. These services often use a combination of traffic filtering, rate limiting, and other tactics to ensure only legitimate traffic reaches the target. 
• Secondary DNS: If the primary DNS server becomes overwhelmed due to a flood attack, the secondary DNS server can continue to resolve domain names, ensuring that services remain accessible to legitimate users.
• Firewalls and Routers: Properly configured firewalls and routers can help filter out malicious traffic.
  Router vs firewall
• TTL Analysis: Investigate the TTL values on incoming packets. Abnormal TTLs can indicate potential malicious traffic.
• IP Blocklisting: Identify and block IPs that show malicious activity. This prevents them from accessing your systems further.
  Whitelisting vs Blacklisting

Types of flood attack

DNS Flood Attack

A DNS flood attack specifically targets the Domain Name System (DNS) servers. The DNS is the internet’s phonebook, translating human-friendly URLs (like “example.com“) into IP addresses that computers use to identify each other on the network (like “1.2.3.4”). In a DNS flood attack, attackers send a high volume of DNS lookup requests, usually using fake IP addresses. This causes the DNS servers to try and resolve each request, leading to an overwhelming number of processes. This congestion ensures that genuine requests from real users either get significantly delayed or ignored altogether. If an attacker successfully disrupts a DNS server, it can make a whole swath of websites or online services inaccessible.

SYN Flood Attack

To understand a SYN flood attack, one must first grasp the “three-way handshake” process used to establish a TCP connection. The sequence is SYN, SYN-ACK, and ACK. In a SYN flood attack, the attacker sends a rapid succession of SYN requests but either does not respond to the SYN-ACK replies or sends them from spoofed IP addresses. The target system will keep these connections open, waiting for the final ACK that never comes. This can consume all available slots for new connections, effectively shutting out legitimate users.

HTTP Flood Attack

HTTP flood attacks take advantage of the HTTP protocol that web services operate on. In this attack, a massive number of HTTP requests are sent to an application. Unlike other flood attacks, the traffic sent looks legitimate. The requests can be either valid URL routes or a mixture with invalid ones, making them harder to detect. Because the requests look so much like typical user traffic, they’re particularly difficult to filter out. This method can exhaust server resources and cause legitimate requests to time out or receive delayed responses.

ICMP (Ping) Flood Attack

ICMP, or Internet Control Message Protocol, is a network protocol used by network devices to send error messages. The “ping” tool uses ICMP to test the availability of network hosts. In a Ping flood attack, attackers inundate the target with ICMP Echo Request (or ‘ping’) packets. The target then tries to respond to each of these requests with an Echo Reply. If the attack is voluminous enough, the target system’s bandwidth or processing capabilities may get overwhelmed, causing a denial of service.

Suggeted page: The function of ICMP Ping monitoring

UDP Flood

User Datagram Protocol (UDP) is a sessionless networking protocol. In a UDP flood attack, the attacker sends many UDP packets, often with spoofed sender information, to random ports on a victim’s system. The victim’s system will try to find the application associated with these packets but will not find any. As a result, the system will often reply with an ICMP ‘Destination Unreachable’ packet. This process can saturate the system’s resources and bandwidth, preventing it from processing legitimate requests.

Impact of Flood attacks on different industries

Flood attacks can have devastating effects across various industries, each facing unique challenges and potential damages:

E-commerce:

E-commerce platforms rely heavily on their websites for sales and customer interaction. A flood attack can cause significant downtime, leading to lost sales, decreased customer trust, and potential long-term damage to the brand’s reputation. Additionally, the costs associated with mitigating the attack and enhancing security measures can be substantial.

Suggest: Global Reach, Local Touch: The Role of GeoDNS in eCommerce Expansion

Finance:

In the finance sector, the availability and integrity of online services are critical. Flood attacks can disrupt online banking, trading platforms, and payment processing systems. This not only affects customer transactions but can also lead to compliance issues and regulatory scrutiny. The financial losses and impact on customer confidence can be severe.

Healthcare:

Healthcare providers use online systems for patient management, medical records, and telemedicine. A flood attack can interrupt these services, potentially putting patient health at risk. Delayed access to medical records and appointment scheduling can cause significant operational disruptions and affect the quality of care provided.

Gaming:

The gaming industry is a frequent target of flood attacks, especially during major events or game launches. These attacks can disrupt gameplay, causing frustration among users and leading to a loss of revenue for gaming companies. The competitive nature of online gaming also means that downtime can significantly impact player engagement and retention.

Conclusion

Flood attacks are among the oldest tools in a hacker’s arsenal, but they remain effective. As the digital landscape grows and evolves, so do the methods attackers employ. Regularly updating security infrastructure, staying informed about emerging threats, and employing a proactive defense strategy can go a long way in keeping systems secure and operational.

The post Flood Attack: Prevention and Protection appeared first on ClouDNS Blog.

How does Dig Command work?

Dig Command works the same way as a typical DNS query. Let’s take an A record request. If you want to see the A record, you want to know the IP address of a particular domain. The request will first check if your router has the information of many sites’ addresses in its cache. If it doesn’t have it, the request must be answered from another recursive server. The common solution is that your query will be responded from the recursive servers of your internet provider. It is possible that it doesn’t know it either. No problem, your query will go on a search for the root server. The request will go to the top-level domain like .COM or .EU, and in the end you will get the IP address from the authoritative server for the domain you were checking. 

Dig Command Syntax

Understanding the syntax of the dig command is crucial for effectively utilizing it for DNS troubleshooting and queries. The basic syntax of the dig command is as follows:

dig [@server] [name] [query type] [options]

• [@server]: Specifies the DNS server to query. If omitted, dig uses the default server specified in your system’s resolver configuration (usually defined in /etc/resolv.conf).
• [name]: This is the domain name or IP address you want to query. For example, cloudns.net.
• [query type]: This specifies the type of DNS record you are interested in. Common types include A, MX, SOA, TXT, PTR etc. If this is left out, dig defaults to querying the A record.
• [options]: Dig offers a wide range of options to modify its behavior and output. For example, +short displays only the answer section of the query. Other options include +trace for tracing the path of the query across DNS servers, +noall +answer to show only the answer section, and many more.

How to install the dig command on Linux?

First, let’s check if you already have the dig command installed. You can do that by opening the terminal and writing dig -v. If you have it, your computer will show a message similar to this one:

DiG 9.11.3-1ubuntu1.7-Ubuntu.

Many new Linux distros have it pre-installed. In case you don’t have it, you will get the following message:

dig command not found

For Linux Mint, Ubuntu and other Ubuntu-based Linux distributions you can use the following command:

sudo apt install dnsutils

If you are using Fedora or CentOS you should use:

sudo yum install bind-utils

And for Arch Linux users:

sudo pacman -S bind-tools

Understanding the dig command

Let’s start with a simple example to understand it. We will use google.com for the testing. You can try it directly with your domain, by simply replacing google.com with your domain.

dig google.com

The first line will inform you about the version of the dig command and the second about the global option.

After that, you will get technical information provided by the DNS nameserver. The header shows you what did you do and was it successful. If there is “NOERROR” that there was no problem.
You will see the answer for the EDNS.
Following line shows that by default you are requesting the A record.
You will get the answer for the A record – the correspondent IP address and you will get statistic about the query.

10 Most used Dig commands

More dig command examples:

dig google.com +short

This will show you just the IP address without any additional information. Quick and easy to use the answer that is basically the answer of an A record. 

dig google.com MX

You can query different types of records like the mail exchanger ones. MX records show the responsible mail server for accepting emails. You can see if all of the servers are working the right way and if they are responding too slowly.

dig google.com SOA

SOA – the start of authority, shows the authoritative DNS server. In this record, you see valuable information about the zone. There is only one SOA per zone. 

dig google.com TTL

TTL – time to live. It shows how long the data should be kept. You can read more about TTL HERE. People usually leave longer TTL, and that way, they lower the DNS servers’ load. When you are creating records, you can set it to a low value, if you like. Also, it is possible to set different TTL for different DNS records.  

dig google.com +nocomments +noquestion +noauthority +noadditional +nostats

Only answer query. Use it if you don’t want to receive extra information. A clear and short answer that will evade the extra statistics that you might want to skip. 

dig google.com ANY +noall +answer

Query all types of DNS records. It will show all the different types of DNS records. This will give you an overview of the domain. Later you can use the dig command for the exact DNS records that you want. 

dig -x 172.217.1.142

Reverse DNS lookup. You can also do the opposite and check the IP address. The rDNS is used for verification. The result will be a PTR record that verifies the nameserver. It is needed that a PTR record exists. Otherwise, this revers checking can’t give an answer.

dig @8.8.8.8 +trace google.com

Trace DNS Path. It will show the whole route that a DNS query takes. Every hop from a server to server. It can show you where exactly server is not working. You might be surprised how far does your query travels. Check it from different locations, and you might see where in the world you need a new point of presence to reduce the latency for the users there.

11 dig -p 5300 google.com

Specify Port Number. If you have changed the standard port 53 to another for increased security, you can make a dig command to check if it is working correctly. And of course, you can check if you have closed the standard ports, and you don’t have any “open doors” for attackers. 

dig _sip._udp.YOURDOMAIN.com SRV

Another record that you can check with this command is the SRV. The SRV records are often used in VoIP. In this example, we are checking the SIP service, and we will use the UDP protocol. The answer will show you the time for response and the server’s IP responsible for the SIP service. 

dig google.com TXT

To see all of the TXT records, use this command. TXT records can be used for verifications and can have different variations. For example, it can be a DMARC record. To see a particular one, you can use the following command and change the “dmarc” with the one you need. 

dig _dmarc.google.com TXT

Now you know the basics of the dig command on Linux. You can start experimenting by yourself.

We can recommend you a few more tools that can be useful for your DNS diagnostic Nslookup, Traceroute, MTR, Host, and Ping.

Conclusion

The dig command is an indispensable tool for DNS troubleshooting and analysis. Its flexibility and powerful options make it a preferred choice for network administrators and IT professionals. By understanding how to install and use the dig command, as well as mastering its syntax, you can efficiently diagnose and solve DNS-related issues. Whether you’re checking DNS records, performing reverse DNS lookups, or tracing the path of DNS queries, dig provides you with the insights needed to ensure your domain’s DNS is functioning correctly. Remember, practice is key to becoming proficient with the dig command, so don’t hesitate to experiment with different queries and options. With this knowledge, you’re well-equipped to tackle any DNS challenges that come your way.

The post Linux dig command, how to install it and use it appeared first on ClouDNS Blog.

How to check the TTL using Windows OS?

You will need to open the Command Prompt as an administrator. From there, you need to use the nslookup. Write this on the command line “nslookup -type=soa www.cloudns.net”. You will get an answer from the authoritative server with the TTL.

You can change the type of the record and look it up for A, AAAA, MX or another type.

How to check the TTL using Linux OS and Mac OS?

You will need to use the dig command.

“dig a cloudns.net” This will give you a long answer. If you want just the TTL, you can try dig +nocmd +noall +answer +ttlid a www.cloudns.net

You can check the different DNS records by changing the text on the last before the domain. For example for AAAA records it will be: dig +nocmd +noall +answer +ttlid aaaa www.cloudns.net and for the MX it will be: dig +nocmd +noall +answer +ttlid mx www.cloudns.net

The previous answers are provided by the recursive servers. If you want to ask directly an authoritative nameserver you should add “+trace” after the “dig” and it will look like this: dig +trace +nocmd +noall +answer +ttlid aaaa www.cloudns.netTTL for different DNS records

• If you want to setup different TTL for every single record you can use our Anycast DNS network!

Easy way to check the SOA TTL value

Now, let’s see how to check the SOA TTL value, which is important for understanding the duration DNS records are cached and how quickly changes are propagated across the internet. For this purpose, we will use the ClouDNS Free DNS tool, a straightforward and effective solution for DNS management and analysis.

1. Access ClouDNS Free DNS Tool
Navigate to the ClouDNS website and locate their Free DNS Tool. This tool is specifically designed for conducting DNS audits and other DNS-related inquiries.

2. Enter the domain name
In the Free DNS Tool interface, you’ll find a field to input the domain name you wish to investigate. This is where you type in the full domain (for example, “cloudns.net”). It’s crucial to ensure the domain name is entered correctly to get accurate results.

3. Choose DNS audit and Select DNS resolver
Once the domain is entered, you need to specify the type of inquiry you’re making. Select “DNS audit” from the available options. Then, choose a DNS resolver. Typically, you might have options like Cloudflare, Google, etc. The choice of DNS resolver can influence the results, as different resolvers might have different cached data.

4. Review the results
After initiating the audit, the tool will process your request and display the results. In these results, look for the SOA (Start of Authority) record section. This part of the report will include information about the primary nameserver, the responsible party for the domain, and various timers related to the domain’s DNS records.

Most importantly, locate the “Default TTL” value within the SOA record section. This number, typically shown in seconds, is the SOA TTL value for the domain. It indicates the duration for which DNS records are cached by resolvers.

Shorter or longer TTL?

Many clients prefer to set the TTL to a long period like 2 days (172 800 seconds). This will reduce the load on the DNS servers, because the queries need to be done less frequently. This can be good if you have a very limited DNS plan, but your clients won’t be happy about it. Make your clients’ experience better, with lower TTL and frequently updated records.  Shorter TTL is useful if you have a very dynamic environment.

A and AAAA records. You can set it as low as 60 seconds if you really need your clients to get the latest update, but we recommend to have it around 1-2 hours to reduce the load on the servers. You can put it as long as 12 hours or a whole day.

SOA record. Unlike other DNS records, SOA controls the speed of DNS updates. A longer TTL (e.g., 48 hours) delays updates but reduces server load. A shorter TTL (e.g., 2 hours) speeds up updates but increases server queries. Choose based on your update frequency and server capacity.

CNAME record. If you need to deliver a lot of content to different parts, you can lower the TTL but in normal conditions you can leave it to 12 hours

MX record. System that have a static IP (it doesn’t change) can put 1800 seconds or more, but the rest with dynamic IP must keep the TTL low.

TXT record. This one you don’t change a lot, so you can set it up to 12hours.

You can experiment with the TTL to see which suits you best. Remember the lower it is, the more often the recursive servers will update the information which is good for your clients. But this will signify a bigger load on your servers and more queries. You should see the results and think if you want to move to a lower or to a higher DNS plan.

30-day Free Trial for Premium Anycast DNS hosting

The post TTL and how to check TTL appeared first on ClouDNS Blog.