The modern e-threat landscape (threatscape) has, once again, changed. We are no longer besieged by new (and dangerous) malicious strains, but by truisms. The e-thereat scenery is always on the move; no point in denying that.

While in college, I took a Computer Sciences class. I remember sitting there, hearing all about the finer points of bits, bytes, octets, and data arrays, when someone seated in the back popped a question to the teacher: “is there such a thing as an unhackable device?”. The teacher’s answer was mind-blowing: “What would be the point of having something around that can’t be hacked?”

Skipping ahead a bit, years later, I finally understood what the teach meant – how can you ‘do’ if you can’t undo it? How can you tell what’s normal and what’s abnormal if you don’t have a baseline comparison? This zigzagging down memory’s lane does have a point, one that has very much to do with today’s topic, which is Secure DNS and DNNSEC.

So, every armor has its chink and every chink helps us improve that armor; the e-threat landscape is evolving because that what’s it supposed to do.  Now, on to our topic – what is Secure DNS? Why do you need it? What does it do, and, of course, the question that has tormented our minds since the dawn of time – will it blend?  (a roaring shout out to Tom Dickinson for the best 3 A.M videos ever made!). Let’s get started.

DNS vs. Secure DNS. Cybersecurity concerns and predictions.

Inevitably, you will always stumble upon the phrase: “don’t rely on antiquated and/or traditional antivirus”. What I personally find fascinating in all this marketing malarkey is that in the long-forgotten days of yore (basically the Stone Age of computers) malware was cured by an antivirus solution.

True that some malicious variants like worms, trojans, viruses, and any ‘file-based’ malware, would have faced its untimely demise at the hand of an antivirus. However, as the Internet evolved (yeah, I’m really going there), so has malware. Right now, the only people bothering to name, bag, and tag malware are those from MITRE; everybody else is looking for ways to get rid of infections previously thought to be impossible.

Heimdal™ Security is one of the few cybersecurity vendors & developers that go to great lengths to keep track of malicious strains – and no, I’m not saying that because I work there or something. Anyway, the latest fad in data-stealing thingamajigs is the ‘tainting’ of the DNS records or the server itself. If you want to learn more about DNS attacks, I highly encourage you to read Bianca Soare’s article on DNS spoofing.  For now, we’re going to stick to Secure DNS and DNS Security. Before we get to that, here’s a refresher on DNS.

‘There and back again.’ A DNS Tale

DNS, which is short for Domain Name System (forgive the cap Obvious moment) is the Internet’s phonebook, matching human-readable resource addresses with machine-readable addresses. Why is this useful? Because remembering the numerical string of a website’s IP address is just not practical. It’s easier to type in “youtube.com” or “google.com”.

As you know, machines don’t care too much for fancy names, just 1s and 0s. So, to make things easier, the DNS was introduced. Its purpose is to translate human fiddle-faddle into something machines can make out. As far as the tech side of DNS is concerned, it’s pretty arid, but I did manage to get a hold of simple-to-remember, easy-to-digest explanation of how DNS works and why we need it. Here it goes.

Let’s assume that you want to navigate to a website called www.example.com. To do that, your machine needs to know the website’s IP address. We know, by fact, that the IP address associated with www.example. com is 192.172.9.4, but your machine doesn’t know it just yet. The first place it will look for the address is its own cache. See, after every (successful) address resolution, your machine stores the IP address in the local DNS cache.

Resolved addresses are usually stored there between 24 and 48 hours. If the IP address associated with www.example.com is not found in the local cache, your machine will go ahead and ask the ISP Server. Since the aforementioned node has better things to do than DNS resolutions, it will pass the question along to its Resolver. The ISP’s resolver will query its own cache, which also called the Resolver Cache – no shift, Sherlock?! – to look for the IP address associated with www.example.com.

If it’s there, it’s going to send back the answer to the ISP server which, in turn, will bounce the answer back to your machine. Still, if the IP address has not been cached by the ISP’s resolver, it will go ask the Root Name Server for the IP Address. Root Name Servers are these all-knowing and all-powerful Internet soothsayers that hold root zone records and are able to direct requests to the authoritative name server for TLD (top-level domain). Fun fact: there are 13 root name servers in the world, 12 of them being held by private companies.

Actually, there are more than 13 RNSs, but that’s a topic for another time. So, if the ISP resolver doesn’t know the IP address for www.example.com, it will ask the RNS. Because RNS isn’t much of a talker, it will tell the ISP’s resolver to ask the appropriate Top-Level Domain server – .com, .org, .net, .mil, etc. are top-level domains.

After the RNS sees that the ISP Resolver’s query contains a .com TLD, it will tell the resolver to ask the .com TLD server. The resolver pops the questions to the .com TLD server. In turn, the .com TLD server will instruct the resolver to inquire with the .com Authoritative Name Servers (Santa TLD’s little helpers).

Finally, the .com Authoritative Name Server holding the record with the IP address for www.example.com will reply to the ISP resolver, telling it the IP associated with that human-readable address. Phew! Now that the game of digital 21 questions is over, it’s now time to get back to the client aka the machine popping the question in the first place.

Before returning with the answer, the ISP’s Resolver will cache the newly-found IP address for future reference (or until the TTL says: “hasta la vista”). The ISP Resolver will pass the IP address of www.example.com (which is 192.172.9.4) to the ISP Server. After that, the ISP Server will return the IP address to the client. With the IP address in its possession, the client can finally reach the website.

The process, as it’s been described above, may seem painstakingly long but, in reality, it all happens very, very fast. That’s DNS for you.

Securing your DNS

Indubitably, there’s no way a machine as ‘cogful’ as the DNS to be impervious to cyber-aggression. Perhaps you have heard tales or ‘hearsay’ about Man-in-the-Middle Attacks, DNS poisoning, DNS hijacking, and so on. A most impressive pallet of a very dangerous and effective DNS attack, this being the very reason why developers have rolled out what’s called DNSSEC.

As you’ve probably guessed DNSSEC is short for Domain Name System Security (+Extensions) and it’s a DNS protection initiative spearheaded by the Internet Engineering Task Force. It’s called an extension because, by default, DNS queries are not secured. This could leave each one of the ‘actors’ involved in DNS resolution susceptible to one or more types of attacks. Some of the most common DNS Security extension include:

  • Cryptographic authentication of DNS data, usually with a symmetric key, since it consumes fewer network resources as compared to using asymmetric cartography.
  • Authenticated DoE (Denial of Existence). Allows the DNS resolver to tell whether or not a domain exists. At the same time, it can confirm that the yet-to-be-resolved domain does, indeed, exists.
  • Data integrity (+authentication). DNSSEC and Secure DNS – I’ll get to that in a moment – ensure authentication by binding crypto-generated digital signatures to the corresponding Domain Name Systems RRsets.  Quick clarification – as Microsoft’s DNS documentation eloquently puts it, RR (resource records) are the “building blocks of host-name and IP information and are used to resolve all DNS queries”. RRs come in various shapes and sizes: MicrosoftDNS_AType, used for name-to-address-mapping, MicrosoftDNS_MBType for mailbox records, and MicrosoftDNS_MFT Type (mail forwarding agent for the domain record). These are just a few RR types; plenty more where they came from. Furthermore, DNNSEC also covers origin authentication – provides an extra security boost. Why? Because crypto-generated digital signatures can put the servers and resolvers ‘at ease’, knowing that the data came from a trusted source.
  • Implementation of RPZs. One way to protect your recursive DNS serve is by putting in place Response Policy Zones (RPZs) – not to be confused with DMZs (Demilitarized zones) which is the logical or physical subnet that separates LAN from potentially untrusted networks. In this case, RPZs refers to laying down a set of rules regarding what your DNS queries can look and cannot look when interrogating a recursive DNS server. So, what does it do? RPZs are very useful in decreasing the chances of querying domain names that could be linked to malicious servers.

What about Secure DNS? DNSSEC and Secure DNS are somewhat interconnected, but not fused at the hip. The first refers to the methodology used to protect DNS servers, data, and clients from unlawful eavesdropping and data exfiltration. Secure DNS is the way to apply the said DNSSEC methodology.

One can consider Secure DNS the latest fad in anti-malware protection and an indispensable tool in threat intelligence. The reader should keep in mind the fact that Secure DNS should be implemented alongside the usual cyber-threat countermeasures: antivirus, anti-malware shield, firewall, email protection, and everything in between.

Secure DNS solutions for your company

From henceforth, my punchline will be “there’s plenty of fish in the sea”. Indeed, there are plenty of Secure DNS solutions on the market – some are open-source and others are subscription-based. The question at hand is “does my company really need Secure DNS?”. It’s not exactly mandatory such as GDPR, but it’s slowly making its way up. DNS-driven attacks are not as common as ransomware or botnets. Let me rephrase that: not yet. The status quo can change very fast and it’s of the utmost importance to take the necessary steps to prevent what can very well be a financial disaster for your company.

Heimdal Official Logo

Antivirus is no longer enough to keep an organization’s systems secure.

Thor Foresight Enterprise

Is our next gen proactive shield that stops unknown threats
before they reach your system.
  • Machine learning powered scans for all incoming online traffic;
  • Stops data breaches before sensitive info can be exposed to the outside;
  • Automatic patches for your software and apps with no interruptions;
  • Protection against data leakage, APTs, ransomware and exploits;
Try it for FREE today Offer valid only for companies.

The first step towards Secure DNS is DNS filtering. Not exactly a cybersecurity novelty or true DNSSEC, nonetheless essential. Heimdal™ Security Thor Foresight Enterprise employs a powerful DNS filtering engine, more than capable of intercepting malicious data packets that could harm your endpoints and network. With Thor Foresight Enterprise’s DarkLayer Guard™, you will be one step closer to achieving true DNS Security.

Our DNS filtering engine will decrease latency by relying on both local and cloud querying.  Every time your machine makes a DNS query, our DNS traffic filtering engine will inspect data packets to see if anything’s hidden in the Internet traffic. Furthermore, if Thor Foresight Enterprise picks up any unusual activity during querying, it will automatically block the connection.

Conclusion

The next gold standard or a passing cybersecurity fad? Time will tell, perhaps. However, considering the upslope evolution of malware, it’s not entirely farfetched for Secure DNS to become mandatory. What’s your take on DNSSEC and Secure DNS?

Leave a Reply

Your email address will not be published. Required fields are marked *

GO TO TOP