Effectiveness of Flushing DNS Cache to Prevent DNS Cache Poisoning and Spoofing

Situation arises when one new developer self-host DNS and use own computer for temporary or permanent hosting DNS. It is mostly a misconception that flushing DNS of localhost provide good immunity. In This Article, We Will Clarify Whether Regular Flushing DNS Cache to Prevent DNS Cache Poisoning and Spoofing is Sufficient to Provide Them an Acceptable Level of Security. The DNS vulnerabilities unfortunately reaching zenith with wider adaption of Docker by relatively new developers with feeble idea around Container Security and DNS Security. In order to make this article useful resource to wider audience, we will discuss the basics, share resources to flush DNS cache, describe the available mythologies for protection from the vulnerabilities Domain Name System (DNS) protocol and finally come reach a conclusion.

Basics of Flushing DNS Cache

Cache poisoning really need involving the cache of server which is part of the domain name system. DNS Cache poisoning is possibly one of the most prominent and dangerous attack on DNS resulting in a DNS resolver caching of invalid or malicious mappings of IP addresses. Cache poisoning is dangerous because they enable the attacker to add false mappings to the cache of vulnerable DNS resolvers, overwrite existing mappings, which can be enough bad for a new developer. If host, user, administrator is same person, situation becomes complex. The methods large operators and administrators can use for network protections and attack identification of the Domain Name System (DNS) protocol often not suitable for the relatively new developers or an average user to implement.

Needed Theoretical Background to Understand Flushing DNS Cache Mechanism

Browsers need IP address of a domain or URL, either IPv4 or IPv6 so that it can connect and complete the task. Each time a user visits a domain or URL via browser, the browser checks local file(s) named DNS Cache to find any entry against the IP address of the URL. If the record is present, the browser will use it. If the record is not present, then browsers will query to DNS server to procure the IP address. This process is known as DNS lookup. The DNS cache is created on localhost and also ISP’s DNS server. The goal of this process is to decrease the amount of time spent in querying. Computers on a network gives priority to the local file to check entry. Depending on the operating systems, refreshing with new IP against a domain or URL. Also, this process depends on the accuracy of DNS resolution.
Domain Name System (DNS) is a globally distributed dynamic database which provides a way to map between the domain names and corresponding IPv4 and IPv6 addresses. It also serves the similar purpose for the mail exchange information (MX records), name server information (NS records) etc which are defined in Resource Records (RRs). The Resource Record information is divided into zones and arranged for retrieval through the global DNS architecture. DNS can use UDP or TCP.

If for the domain example.com, the legitimate IP is 100.11.12.13, then on localhost the DNS cache will hold record kind of in this manner:

Within a limited time span, in two scenario –

• If example.com changes the IP address from 100.11.12.13 to 100.11.12.14 for reasons in planned manner as part of system administration
• If someone deliberately manipulates the legitimate IP against example.com to own desired IP
  then the localhost will return undesired or non-updated result from DNS Cache. Question of DNS Cache Poisoning and Spoofing arises in second scenario.

In the first scenario, the user essentially not face security issues as the change is legitimate by owner or administrator of example.com. Flushing DNS Cache resets the localhost cache, thereby the operating system query on ISP DNS server. If ISPS DNS server is manipulated with malicious intention, then the scenario is complex. DNS Cache Spoofing and DNS Cache Poisoning are similar malicious but in case of spoofing different methods used to poison the DNS cache.

Methods of Flushing DNS Cache in Different Operating Systems

Unfortunately, the problem in real life is inability to detect when one unused is under attack i.e. the record is manipulated by some malicious program. In such case, browsers may throw errors mimicking common networking error to the end user. For example, a Windows computer may throw error like we described in one previously published article with solution to completely reset the system to make it normal.

In normal situation, in order to flush DNS, the users of MacOS X, GNU/Linux and Windows need to follow official documentation of the respective operating system or may follow standard, well written guide like this one to find how to flush DNS in various operating systems, and their different versions. Such guides, methods are easier to perform by a regular user, it is expected that a developer should know them as part of work.

Available Methods to Prevent DNS Cache Poisoning and Spoofing

Unfortunately, the list of available preventive methodologies to the ordinary end user is too less:

1. Flushing DNS
2. DNS Cache Locking can be configured to >90%. Cache locking allows to control overwriting information in the DNS cache.
3. Using DNS Socket Pool enables a DNS server to use source port randomization while issuing DNS queries.
4. Regular update of firmware and software of security of the systems current

Most of the other common methods are either for the system administrators as user or administrator of the servers.
Server should be the one and only interface between the network and Internet behind a robust firewall, using Domain Name System Security Extensions (DNSSEC) to add more security to the DNS protocol. The period of each entry in DNS cache should be set to short allowing DNS records to be fetched more frequently to keep updated. This means setting shorter TTL and possibly longer time to connect to website by the users. DNSSEC introduced absolute time into DNS. Recursion is enabled by default for BIND versions 9.5 and older. The configuration need to be tweaked in the named.conf configuration file. UDP protocol as such, can be easily spoofed. It is practical to try to avoid wherever possible. Using recommended features of router and firewalls to ensure higher security. It is vital to ensure are protected by a DDoS mitigation service. Monitoring name servers for unexpected behavior, using PKI to server, using hardened operating system, implementing specialist DNS appliance are part of genuine efforts.

Conclusion

Our major concern in increasing usage IoT devices and container based solutions. DNS unfortunately has already known major security issues which needs to be addressed. Threats including Man in the middle attacks, DNS cache poisoning usually take place because of fault within the authentication system and also deficit in integrity in the DNS transaction process. Flushing DNS only addresses issues with local DNS cache. DNS cache poisoning is difficult to detect, can last until the TTL, or till administrator realizes. Definitely, flushing DNS addresses some common issues but it is a toy to mitigate the risk of a DDoS attack.

As such, usage of flushing DNS remains within few known applications including while initially pointing domain towards host or changing host. Even if flushing DNS temporarily solves the issue, the system needs to be checked for possible presence of malicious code.