Public DNS Servers VS ISP-Hosted DNS
Here in Hackercombat.com, we continue to educate our readers about the importance of DNS in their daily lives. In fact, we have written about this same subject at least on a monthly basis: Vulnerabilities in DNS exists, and we must address it, securing DNS from hackers, and DNS exploit to cause Internet disruption. The list goes on, especially due to the fact that ISPs are not taking any active action on their end to address the flaws. As we have mentioned earlier here in Hackercombat.com, Domain Name Service is not a profit-center for Internet Service Providers, they often see it as a cost of running the business. All they need to do is to host their own DNS servers for use by their customers (automatically configured in their customers’ modems), but no incentive to make it better, for it to perform at its tip-top shame, let alone introduce features that will restrict common DNS exploits from happening.
The cache DNS server maintains the name resolution results as a temporary cache to improve name resolution performance and at the same time reduce the load on the authoritative DNS server. If the domain name is already cached, the cache DNS server returns the contents to the user as it is. If the cache name is not cached or the expiration date has expired, the authority DNS server is inquired again. Responsible for returning the results to the user and then caching the results for the future. In this way, the cache DNS server caches the results obtained from the authoritative DNS server and makes name resolution more efficient. But what if you could have your cache DNS server cache some bogus responses from some external source? A cache DNS server that has a fake cache will return the injected fake results in response to name resolution requests from users. And all access for all users who refer to that name while the fake result is cached will be directed to the fake site.
This flaw was already fixed by public DNS vendors such as Google (8.8.8.8), OpenDNS (208.67.222.222), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) many years ago, but sadly remain as a real problem with ISP-hosted DNS servers. This type of attack technique that directs user access to fake sites by caching fake responses in the cache DNS server. The attacker sends spoofed data to the cache DNS server as a response from an authoritative DNS server. If the data arrive earlier than the real data and is determined to be real, fake information that is “poison” to the cache DNS server can be injected as a cache. When performing DNS cache poisoning using this method, an attacker must send a name resolution request to the cache DNS server, and then send a fake response from the outside at an appropriate time. A well-managed cache DNS server is usually configured to reject DNS queries from outside the organization. There are also ways to abuse the sending and receiving of email. An attack that sends a mail with a specific mail address to the sender (From or Sender) and prompts the mail server software to resolve the name is also possible.
A reliable and competent network administrator will first and foremost end the use of ISP-hosted DNS. He can set up an internal DNS within the boundary of the corporate network (for the purpose of resolving internal IPs to specific subdomains), and redirect external DNS look-ups to known public DNS mentioned earlier (Google DNS, Cloudflare DNS, OpenDNS or Quad9 DNS). A Network administrator worth his salt deserves to be free from network trouble caused by the weakness of the ISP-hosted DNS. Domain Name Service is the backbone of the whole Internet infrastructure, as nobody wants to navigate the TCP/IP networks through the use of IP address only. IP addresses were designed to simplify packet switching for machines, domain names were invented for humans to use.
Also Read,
How To Deal With DNS Vulnerabilities?