- \n
- User Enters a Domain Name<\/strong> <\/li>\n<\/ol>\n\n\n\n
You type \u2018example.com\u2019 into a browser. <\/p>\n\n\n\n
- \n
- Check Local DNS Cache<\/strong> <\/li>\n<\/ol>\n\n\n\n
Your device first checks its local DNS cache to see if it already knows the IP address for the domain and if found, it uses that address immediately. If not found it sends a DNS query to a DNS resolver, typically operated by your internet service provider (ISP) or a public DNS provider like Google. <\/p>\n\n\n\n
- \n
- Query Recursive DNS Resolver<\/strong> <\/li>\n<\/ol>\n\n\n\n
The DNS resolver acts on your behalf. If it doesn\u2019t have the answer cached, it will query the DNS system step by step to find it. The resolver will ask a root server where to find information on .com domains. The root server then replies with the address of the Top-Level Domain (TLD) DNS server for .com. <\/p>\n\n\n\n
- \n
- Query the TLD DNS Server<\/strong> <\/li>\n<\/ol>\n\n\n\n
The resolver then asks the .com TLD server who to query for the DNS records of example.com<\/em>. The TLD server responds with the IP address of the authoritative DNS server for example.com<\/em>. <\/p>\n\n\n\n
- \n
- Query the Authoritative DNS Server<\/strong> <\/li>\n<\/ol>\n\n\n\n
Finally, the resolver asks the authoritative server for the IP address of example.com. <\/em>This server responds with the actual IP address (185.151.30.182), which is then sent back to your browser <\/p>\n\n\n\n
The resolver sends the IP address back to your device, and your browser can now initiate a connection to that IP address (usually over HTTP or HTTPS). <\/p>\n\n\n\n
![\"how](\"https:\/\/www.20i.com\/blog\/wp-content\/smush-webp\/2025\/07\/DNS-Poisoning-Hijacking_inner.png.webp\")
<\/figure>\n\n\n\nHow Does DNS Cache Work? <\/h3>\n\n\n\n
DNS caching is a mechanism that temporarily stores the results of previous DNS lookups to speed up future requests for the same domain name. <\/p>\n\n\n\n
Instead of querying the entire DNS hierarchy every time, your system will use the cached IP address, greatly speeding up the process, reducing latency and reducing DNS traffic. <\/p>\n\n\n\n
As DNS records are liable to change, DNS cache will only be stored for a set time, determined in seconds by the DNS record\u2019s TTL (Time To Live). <\/p>\n\n\n\n
TTL for DNS records are controlled by the operator of the domains nameservers, and the this is commonly set to 14400 seconds (4 hours) in the industry. The TTL given out by our nameservers is 3600 seconds (1 hour), so if you’re making a change to your records on our nameservers it won’t take long to propagate. <\/p>\n\n\n\n
There are different methods for storing DNS cache: <\/p>\n\n\n\n
- \n
- Browser cache – <\/strong>Most modern browsers store DNS records for a short period of time. <\/li>\n<\/ul>\n\n\n\n
- \n
- Operating System –<\/strong>If the browser does not have the relevant record, it will query your OS via the system resolver. <\/li>\n<\/ul>\n\n\n\n
- \n
- Recursive Resolver Cache<\/strong> (Public DNS or ISP) – ISPs and public DNS resolvers, like Google store their own DNS cache directly from the requested domain\u2019s nameservers. This cache is served on a much larger basis and can be used by anyone using their DNS resolvers. <\/li>\n<\/ul>\n\n\n\n
![\"dns](\"https:\/\/www.20i.com\/blog\/wp-content\/smush-webp\/2025\/07\/dns-spoofing.png.webp\")
<\/figure>\n\n\n\nBenefits of DNS caching: <\/h4>\n\n\n\n
- \n
- Faster website load times <\/li>\n<\/ul>\n\n\n\n
- \n
- Reduced DNS server load <\/li>\n<\/ul>\n\n\n\n
- \n
- Improved resilience to temporary DNS outages <\/li>\n<\/ul>\n\n\n\n
- \n
- Lower latency and bandwidth usage <\/li>\n<\/ul>\n\n\n\n
Concerns with DNS caching: <\/h4>\n\n\n\n
- \n
- Stale or outdated records if the TTL is too long <\/li>\n<\/ul>\n\n\n\n
- \n
- Propagation delays when DNS changes are made (like moving to a new server) <\/li>\n<\/ul>\n\n\n\n
- \n
- Subject to DNS cache poisoning attacks if not properly secured <\/li>\n<\/ul>\n\n\n\n
DNS Poisoning (Spoofing) <\/h3>\n\n\n\n
DNS poisoning is when an attacker inserts corrupt DNS data into a resolver’s cache and is how they achieve DNS spoofing. <\/p>\n\n\n\nThis causes the DNS server to return an incorrect IP address, redirecting traffic, often to malicious sites. <\/p>\n\n\n\n
The attacker can also manipulate the process by sending a forged DNS response to the resolver before the legitimate answer arrives. <\/p>\n\n\n\n
If successful, the resolver accepts the fake response and caches it, associating the domain with a malicious IP address. <\/p>\n\n\n\n
The fake IP address is cached, and all future requests from users to that domain are sent to the attacker\u2019s server. <\/p>\n\n\n\n
DNS Hijacking <\/h3>\n\n\n\n
DNS Hijacking is where an attacker takes control of DNS settings, either by compromising a DNS server, modifying DNS records, or altering a user\u2019s local DNS configuration. <\/p>\n\n\n\nAn attacker can achieve this through different means: <\/p>\n\n\n\n
- \n
- Router compromise – <\/strong>The attacker gains unauthorised access and changes DNS settings directly on the victim\u2019s router. <\/li>\n<\/ul>\n\n\n\n
- \n
- Malware – <\/strong>Installed on the victim\u2019s device to alter local DNS configurations. <\/li>\n<\/ul>\n\n\n\n
- \n
- Registrar attack – <\/strong>The attacker gains access to a domain registrar account and changes authoritative DNS records, affecting everyone worldwide querying the domain. <\/li>\n<\/ul>\n\n\n\n
- \n
- Man-in-the-middle attack (MiTM) – <\/strong>Attacker intercepts DNS requests directly on a compromised network and responds with false data in real time. This is more common on unsecured Wi-Fi networks, such as free, public Wi-Fi. <\/li>\n<\/ul>\n\n\n\n
![\"dns](\"https:\/\/www.20i.com\/blog\/wp-content\/smush-webp\/2025\/07\/dns-cache-graphic.png.webp\")
<\/figure>\n\n\n\nDNS poisoning, spoofing and hijacking can have devastating impacts on anyone who falls victim to it. <\/p>\n\n\n\n
By redirecting to malicious websites, the attacker can trick victims into entering sensitive data into a seemingly legitimate website. <\/p>\n\n\n\n
This data will be sent directly to the attacker and can be used to defraud the victim, steal further sensitive data, or extort the victim later. <\/p>\n\n\n\n
Additionally, the malicious website can infect the victim\u2019s computer with malware, causing further damage, data loss, and opening the victim\u2019s computer up for persistent attacks later. <\/p>\n\n\n\n
These attacks can also have huge implications for the owners of the manipulated domain. If a company’s DNS was targeted, this can damage the brand reputation and cause a loss of trust with clients. <\/p>\n\n\n\n
How to Protect Against DNS Poisoning and Hijacking <\/h3>\n\n\n\n
How we protect you<\/strong> <\/h4>\n\n\n\n
At 20i, we don\u2019t believe that you should have to pay extra for security features, so we include an extensive security suite<\/a> with our Reseller<\/a> and Managed Cloud Hosting<\/a> services. <\/p>\n\n\n\n
As a reseller, this is something that you can advertise as your own and provide to your customers for free to distinguish yourself from mediocre hosting providers. <\/p>\n\n\n\n
DNSSEC<\/strong> <\/h4>\n\n\n\n
We allow you to enable and configure DNSSEC<\/a> (Domain Name System Security Extensions). This digitally signs DNS records, ensuring their integrity and authenticity. <\/p>\n\n\n\n
Security Patches<\/strong> <\/h4>\n\n\n\n
We continuously monitor our platforms and implement any security patches long before they can be exploited. <\/p>\n\n\n\n
2FA<\/strong> <\/h4>\n\n\n\n
20i accounts support 2FA (Two-Factor Authentication) through Google and Microsoft authenticators. This can also be enabled and enforced on sub-user and StackCP accounts. <\/p>\n\n\n\n
Firewall & Brute Force Prevention<\/strong> <\/h4>\n\n\n\n
Our firewall<\/a> will automatically block any known bad actors trying to access a 20i account, and we are continuously updating this list. Our built-in brute force prevention systems<\/a> will also prevent anyone from trying to brute force their way into a 20i account. <\/p>\n\n\n\n
How to Prevent DNS Spoofing & Hijacking <\/p>\n\n\n\n
Strong Passwords and 2FA<\/strong> <\/h4>\n\n\n\n
The first step to minimising unauthorised access to your account is by setting strong passwords with as many characters and variations as are permitted. On top of this, ensure you use 2FA<\/a> to add an extra layer of protection to your account. <\/p>\n\n\n\n
Trusted DNS Resolvers<\/strong> <\/h4>\n\n\n\n
Only use trusted DNS resolvers, like Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222) on your computer. When using trusted DNS resolvers, the likelihood of DNS poisoning or hijacking occurring at the public resolver level decreases significantly. <\/p>\n\n\n\n
Virtual Private Networks (VPN)<\/strong> <\/h4>\n\n\n\n
VPN services ensure that your connection is encrypted from end to end. Using an encrypted connection will greatly reduce the likelihood of a MiTM attack and therefore DNS poisoning and hijacking via these means. <\/p>\n\n\n\n
Antivirus and anti-malware software<\/strong> <\/h4>\n\n\n\n
Using trusted antivirus, anti malware and security software on your computer will greatly reduce the chance of your device being compromised. This will practically eliminate the likelihood of a DNS attack occurring through malware.\u00a0<\/p>\n\n\n\n
Conclusion <\/h3>\n\n\n\n
- Man-in-the-middle attack (MiTM) – <\/strong>Attacker intercepts DNS requests directly on a compromised network and responds with false data in real time. This is more common on unsecured Wi-Fi networks, such as free, public Wi-Fi. <\/li>\n<\/ul>\n\n\n\n
- Registrar attack – <\/strong>The attacker gains access to a domain registrar account and changes authoritative DNS records, affecting everyone worldwide querying the domain. <\/li>\n<\/ul>\n\n\n\n
- Malware – <\/strong>Installed on the victim\u2019s device to alter local DNS configurations. <\/li>\n<\/ul>\n\n\n\n
- Router compromise – <\/strong>The attacker gains unauthorised access and changes DNS settings directly on the victim\u2019s router. <\/li>\n<\/ul>\n\n\n\n
- Subject to DNS cache poisoning attacks if not properly secured <\/li>\n<\/ul>\n\n\n\n
- Propagation delays when DNS changes are made (like moving to a new server) <\/li>\n<\/ul>\n\n\n\n
- Stale or outdated records if the TTL is too long <\/li>\n<\/ul>\n\n\n\n
- Lower latency and bandwidth usage <\/li>\n<\/ul>\n\n\n\n
- Improved resilience to temporary DNS outages <\/li>\n<\/ul>\n\n\n\n
- Reduced DNS server load <\/li>\n<\/ul>\n\n\n\n
- Faster website load times <\/li>\n<\/ul>\n\n\n\n
- Recursive Resolver Cache<\/strong> (Public DNS or ISP) – ISPs and public DNS resolvers, like Google store their own DNS cache directly from the requested domain\u2019s nameservers. This cache is served on a much larger basis and can be used by anyone using their DNS resolvers. <\/li>\n<\/ul>\n\n\n\n
- Operating System –<\/strong>If the browser does not have the relevant record, it will query your OS via the system resolver. <\/li>\n<\/ul>\n\n\n\n
- Browser cache – <\/strong>Most modern browsers store DNS records for a short period of time. <\/li>\n<\/ul>\n\n\n\n
- Query the Authoritative DNS Server<\/strong> <\/li>\n<\/ol>\n\n\n\n
- Query the TLD DNS Server<\/strong> <\/li>\n<\/ol>\n\n\n\n
- Query Recursive DNS Resolver<\/strong> <\/li>\n<\/ol>\n\n\n\n
- Check Local DNS Cache<\/strong> <\/li>\n<\/ol>\n\n\n\n