How to Avoid DNS and DNS Spoofing Poisoning

DNS “spoofing” and “poisoning”. The name literally conjures up the kind of thoughts that hold network administrators up throughout the evening. What if he leaks my RNDC key? Inside my perimeter, might there be a rogue DHCP server? Does the Lizard Squad have an attack scheduled for Christmas?

With the new ‘Net Neutrality’ law, most of what we know now about DNS, address protocol, and packet priority is being redefined. Instead of being a party to the hoopla that is partisan politics around the issue of THAT, let me assure you that there are many different mitigation techniques to not only protect your own network against DNS poisoning, but still working towards a harmonious kum-by-ah solution that in the end, can end up resolving (pun intended) the DNS plight. So, let’s leave the alarm system quiet, and get down to what DNS poisoning is, why it’s still around, and one of the best ways to fix it.

What is DNS poisoning/spoofing?

Domain name system (DNS) cache poisoning, also known as DNS spoofing, is a computer hacking method in which traffic through compromised cached data/files is maliciously diverted to the computer of a victim.

The first thing to understand about DNS ‘poisoning’ is that the Internet providers were very conscious of the problem. DNS queries are basically “cached” or stored in a database that can be queried to point names such as ‘hotmail.com’ or ‘google.com’ to their appropriate IP addresses in almost real time.

Can you imagine having to remember a string of numbers to get to your appropriate WWW (or GOPHER – if that’s your thing) tools instead of a fancy name? It will be very difficult to recall 321.652.77.133 or 266.844.11.66 or even 867.53.0.9. [Note: I’ve confused REAL IP addresses here with really false ones. Still try to keep a step ahead of Armageddon’s AI. Within every octet, real IP addresses end with the numerical value of ‘255.’].

Related Topics to Kubernetes

• How to Safely Drain a Node in Kubernetes – (Kubernetics)
• How to Delete a Service in Kubernetes – Complete Guide
• Setting up Windows Container Service on a Kubernetes Cluster
• Kubernetes Cluster Deployment on CentOS (and Other Linux)
• Kubectl command – How to Add or Remove Labels to Nodes in Kubernetes
• 10 Interview Questions on Kubernetes for SDET/Devops Set-03 (ReplicaSet in K8S)

No, it would be next to difficult to recall strings of numbers. But luckily, we have the DNS mechanism because of Al Gore (sarcasm) that gives us [relatively] simple names to know how to get to our favorite resources.

Basically, the Internet runs DNS. Without it, it could be traversed only by the most uber-geeky of computer scientists. Number strings are actually not how information is defined by humans. They support, but in fact, what distinguishes us from our imminent robotic overlords is words and language.

It’s because of this that the DNS (Domain Name System) was developed as the Internet started to expand. To help us, with little anguish, get from one side of the planet to the other. Because of the computing limitations (particularly storage and bandwidth) at the time, however, the early versions of DNS simply used a “distributed” text file for name resolution.

For EVERY SINGLE HOST that existed on the ‘Net back then, think “blockchain” It was a nicer and friendlier spot, and it worked well with that method. Until it didn’t, and some good ARIN and ICANN people came along and started the system that we’re using today: DNS.

DNS takes a name (e.g. yahoo.com) in its simplest explanation and looks at the locally configured ‘Nameservers’ for the answer to the question:’ What is yahoo.com’s IP address? ‘. Once a response is found, it is transferred back to the requesting client, and the TCP protocol’s routing and magic kicks into gear, and the peasants rejoice.

Related Posts

• Digital Transformation: Future of Enterprises | Predictions | Challenges
• Enterprise Applications Provide advanced Experiences for Digital Reality Features
• Digital Transformation: From a single blockchain to a combination of blockchains
• API Applications are Imperative in Communication Technology
• Internet of Everything (IOE) New Business Model WiFi
• 3 Driving Forces of Enterprise Digital Transformation
• Analysis of 5G Edge Computing & New Infrastructure
• 5 Real Opportunities of Digital Reality Technology
• Edge Computing Business Model Value Chain

Except that often there are issues that cause the peasants to NOT rejoice, and that the vile idea of DNS is cursed by network engineers. You see, since DNS emerged at a time when nothing was theoretically feasible in “real-time”; DNS responses were logged into a locally stored “cache” or database on the DNS server that issues the question to support performance and allow Functional networks.

When the ‘Netizens were sweet and jolly folks, that’s all well and well, but it didn’t take long for the Web to grow and, well, DNS cache can sometimes be the weakest point on your network.

Over the years, we have seen quite a few DNS protocol vulnerabilities exploited, the most primitive being the HOSTS file. This is *not* an article detailing the mitigation of a HOSTS file attack. It’s been the “standard” strategy for solving DNS issues for entirely too long, and plenty of information on how to eliminate this type of “attack” is already available.

This has everything to do with re-thinking the manner in which networks are built. In your home as well as in your business. If it’s a two-bedroom apartment you share with your family, or a corporation with 50,000 workers, some of the holes in DNS can (and have) caused not only loss of income, but loss of health or freedoms in extreme cases.

Without going too “truther” on you, let’s just accept the fact that it becomes very difficult to verify almost anything with a “targeted attack” vector like DNS cache poisoning.

If analyzing ‘dig’ reports and looking at PCAPS is your idea of a nice time on a Tuesday evening, let’s look at how a few quick design decisions can save you some headaches and maybe secure your own network before it goes out to the nastiness that the World Wide Web can be.

What is a DNS spoofing attack?

Essentially, all a DNS spoofing attack requires is a target. This can be a ‘Authoritative Name Server’ (easily accessed by doing a WHOIS domain on any Internet domain) and a weak point on the DNS cache hosting scheme.

Without too much effort, anyone may change the cache of that DNS server, and begin pointing traffic from ‘yahoo.com’ (or any other desired host) to anywhere else on the internet (or even more devious, the local LAN).

The key issue with this is that using DNS’s ubiquity to provide ‘spoofed’ or ‘hijacked’ responses will contribute to a plethora of: phishing attacks, SPAM, password leaks, attacks on social engineering, political upheaval, etc.

It has the power to ruin not only the day of the desired goal, but also nearly everyone else on that road. The good news? Even with these flaws being well-known there are some things a savvy network and/or systems architect or engineer can do to make those peasants remain in a constant state of “rejoice” instead of “revolt”.

The first step to prevent a DNS attack: filter your DNS servers

And now, what does it mean? “Filter”? Well, DO NOT allow your DNS server to respond over port 53 on the Internet in the most simple sense. This is rule #1. Simply do not let your DNS servers answer Internet DNS queries. Unless you are running an ICANN-registered ACTUAL name server and manage your own reverse zone (maybe less than 10 percent of the Internet hosts in the world fit this criteria) – just do it.

Trust me. Your visibility is far more constrained now that you’re not answering DNS requests. The localized attack vector is, however, not fully removed. This is where you just need to determine the DNS requirements and consider using stuff such as RNDC encryption, stub zones, and reducing the TTL values on your local DNS server (s).

Commercial goods are there that can do something for you. Infoblox is, for instance, solid. There are hundreds of suites called “DNS/DHCP Security” that make this task MUCH simpler. But they are costly, and not every person will be able to justify their costs. Yet you can do even more!

This is an example of an protected network. Note the additional safeguards that you can provide to your users through the implementation of a DNS security suite. But cost is not the only barrier; keep reading to ensure that with your DNS infrastructure you have considered the realistic design principles.

Check if Authoritative Name Server matches what is locally resolved

The basic concept behind these attacks is that there is little or no “check” process in DNS queries. In the early days of the Internet, in order for the traffic to flow, several requests needed a legitimate check of the PTR (or ‘reverse’) records.

This can still be used by SMTP servers, but it is becoming a rarity. IRC also does, oddly enough. The advantage of this “check” is that the DNS packet is marked as invalid if the ‘authoritative’ name server gives a response different from what is locally resolved.

It has been “spoofed” and, luckily, this will be seen by most TCP/IP stacks and will not handle the traffic. For a poisoned DNS cache, this isn’t the perfect option, but it does help. Too bad it’s not a normal HTTP request operating procedure. At least not yet.

Conclusion

This is, in conclusion, a dilemma that could actually take hundreds of pages of repetitive text to completely clarify and solve.

Instead, I will just include a checklist that can be considered by any experienced systems engineer or engineer to help protect their DNS infrastructure and keep their overall network health in far better shape. If enough people begin to pursue some of these principles, the DNS poisoning attack will begin to lose its strength. And nowadays, believe me, it has a lot of strength…

Checklist for DNS assault prevention

1. Get your own DNS servers set up and managed. It really isn’t that difficult. For a tiny network, too. BIND or Windows DNS can be configured in less than 30 minutes (securely and correctly). It’s MUCH better than the hosted DNS alternative.
2. Don’t address DNS requests on port 53 over the WAN (or any other port for that matter)
3. Use RNDC keys if you MUST answer at port 53. Rotate them sometimes.
4. Set a low value for your TTLs. I like fifteen minutes. Anything that doesn’t lose efficiency on your network. This way, if you are hot from a cache poison, it will only be a “problem” for a short period of time.
5. DISABLE ‘FILE RESOLUTION’ HOSTS’ ON YOUR CLIENTS AND SERVERS!!!
   
6. Build your PTR zones and manage them properly. It’s repetitive and dull, but VERY necessary, even for local realms. Particularly for traffic via SMTP.
7. Consider using STUB areas, or domains that could easily be hacked, for widely accessed domains.
8. Use DNS forwarders ONLY on DNS servers that are confirmed. So many individuals only go to the ‘Root Servers’ and this is not ideal. Many of them do not respond, and you may end up creating your own poisoned cache with a localized routing table attack. Don’t just do this. Speak and use their servers for your ISP. Also, spot-check them using ‘dig’ regularly.
9. Except from your one and only DHCP server on your network, block DHCP on your firewall. You lose all control of your DNS and DHCP protection if a ‘rogue’ DHCP server is allowed to infiltrate your network. Not to mention, it’s time consuming and frustrating to track down a “rogue” DHCP server.
10. Know the workings of DNS. Learn more than at the surface level, but also at its center level (which I’ve covered a little here). When you do so, inside your own network structure, you can see how some of the inherited vulnerabilities can be avoided.
11. Cluster your capital with your DNS. Many of our current DNS problems arose from a time when computing resources were extremely finite, and performance was very low. This is no longer really the case. Shorter TTLs will increase the I/O of your database, but not so much that you will notice many of your users. Do the testing yourself. You would probably be a bit shocked that your latency or I/O on your DNS infrastructure is not really impacted by getting more ‘close to real-time’ performance.

Topics related to DNS Spoofing Poisoning

• how to prevent dns spoofing
• dns cache poisoning attack tutorial
• dns spoofing attack
• dns cache poisoning example
• dns spoofing attack example
• dns spoofing kali – DNS Spoofing Poisoning
• dns spoofing vs dns poisoning
• explain dns spoofing with example

The Internet is made up of Several different protocols. DNS is one of those that is vital to our’ always-connected’ world’s proper functioning and core values. Providing a simpler landscape with improved network policies is an ideal to be followed by every technological expert. Do not become the “lazy admin” who, with the results of a DNS poisoning attack, costs your family or business. Feel free to contact me, as always.