The DDI market displays strong growth. The importance of good and thorough DNS, DHCP and IP address management has been well established by now. Now it’s time to take the next steps. How do you get even more value out of DNS data? We discussed this this with Martin van Son, Senior Account Executive at Infoblox.
The importance of a properly functioning DNS (and BGP) was clearly demonstrated recently when Facebook’s services were unavailable for hours. An employee of the company made a mistake in the configuration, after which DNS and BGP got so confused that everything went wrong and users of Facebook, Whatsapp and Instagram had to find something else to do as a pastime.
As a result, DNS was extremely visible in the news for a while, even if it was not necessarily for the most positive reasons. Mind you, Facebook’s DNS system in itself cannot be blamed in this case. It’s not as if that didn’t work well, the input was simply not good. Perhaps with deeper integration between DNS and other components, the misconfiguration could have been caught though. In any case, you can’t blame Facebook’s problem on the DNS or the BGP.
Good year for DDI
Besides the Facebook outage, DDI has received increasing attention in recent years anyway. Last year was a “bizarre year in terms of turnover” for Infoblox, says Van Son. Whereas Infoblox had to make the market for a long time, DDI has now really definitely become established. As an example, he cites the fact that the VNG (Association of Netherlands Municipalities) has recognized that DDI is an essential component in the infrastructure for a municipality.
The transition to the cloud and the services that go with it has been a major factor in the increasing popularity of optimally designed DDI. For example, if you are a global company and you want to use Microsoft Office 365, you also want to provide everyone with an optimal user experience. Then you can’t get away with having all your employees use a centralized DNS. For employees who are located at a great distance from that central point, that results in a lousy experience. Among other things, the latency is much too high.
Tip: Also read our article where we explain what Infoblox does.
Decentralization
As mentioned briefly above, the decentralization of the work environment plays an important role in the adoption of DDI services. This partly explains why the past year has been so good for Infoblox. After all, many organizations had to start operating in a much more decentralized manner at once. In order for everything to run optimally, it was important to look at how cloud services could be used optimally, regardless of where employees were located. The architecture of the past, however, was centralized, Van Son points out, whereas it should now be decentralized.
The shift from centralization to decentralization is one of the main reasons why organizations don’t just select one of the major public cloud providers to set up their DNS. As we saw in the Microsoft Office 365 example above, you’d rather not have everyone worldwide accessing the services through one single Microsoft data center, for example in Frankfurt. “You want to have the services on-premises and the management in the cloud,” as Van Son puts it. In addition, you risk a lock-in if you start buying your DNS from a public cloud in addition to all kinds of other services.
DNS as a security layer
Originally, DNS hasn’t necessarily focused on providing security. Yet you can use it quite effectively for that purpose. A good example is a (local) Response Policy Zone (RPZ). With an RPZ it is possible to block accumulating traffic on a DNS based on the reputation of providers. This prevents bad domains from being routed and thus causing further damage.
A DNS can also block new domains by default for a limited time. You often see that bad domains exist for a very short time. They come on the air, do their thing for a short time, and disappear again. By making sure that new domains cannot be used right away, and by checking them carefully first, you stop a substantial part of the wrong domains.
The information Infoblox uses to assess domains in this way comes from several sources. First of all, of course, from the DNS registrars, who assign the domain names. In addition, however, Infoblox also makes use of hundreds of passive DNS nodes. These basically do nothing, but see all queries pass by. A passive DNS also stores historical data about domains. All this data is fed to ML algorithms, in order to also be able to detect the more subtle security threats.
VPN vs DNS
A final example of the use of DNS as a security layer has to do with securing home workers. This is obviously still very relevant and will continue to be so. If we are serious about hybrid work, we also need continued secure solutions for working remotely within an organization’s environment. Traditionally, organizations have used VPN for this.
VPN, however, is old technology, that organizations should avoid. With the rise of SaaS applications, its usefulness is diminishing. After all, you don’t have to go through a VPN tunnel for that. That also means that it doesn’t protect employees, even if they do connect to the corporate environment. In addition, VPNs are increasingly the target of attacks. Especially unpatched and sometimes unmanaged VPNs are vulnerable. Finally, the purchase of a VPN license for each employee can become quite expensive. You can, of course, decide to purchase only a limited number of those licenses. However, that doesn’t make sense from a security standpoint.
To allow employees to connect securely, you don’t necessarily need VPN. You can also use DNS. Infoblox has BloxOne Threat Defense in its portfolio for this purpose. This service redirects the home worker’s DNS through the Infoblox cloud. There, the service ensures that a home worker cannot (accidentally) connect to websites where phishing, ransomware and other malware originate. You can also block certain types of content there based on policies. Furthermore, BloxOne Threat Defense continuously monitors whether connections remain secure. If lookalike domains appear, for example, this service sees that too.
Making DDI data more broadly relevant
So far, we’ve talked mostly about things that are at the core of what you might call traditional DDI. That is, the data that Infoblox collects, and Infoblox uses to develop and offer products and services for and to its customers. This was necessary for a long time, because the market for DDI had to be developed. As a result, Infoblox first needed to demonstrate why DDI is important. However, that market is now real, so Infoblox can focus on additional uses of the the data that organizations have at their disposal via DDI.
One important consequence of Infoblox’s broader focus is automation. Infoblox wants to feed DDI data (especially DNS) into other (security) solutions. In this way, Infoblox (or at least the data that customers collect with Infoblox) moves a bit down the network stack. For example, Infoblox can pass on the severity scores it compiles when it blocks DNS queries. Tools like Aruba Clearpass or Cisco ISE can then take advantage of that, to name a few examples.
Is the market ready for automation?
The above, however, is easier said than done. Infoblox may have an API, but that’s not enough. There are so many security vendors that it is virtually impossible for them to realize all the integrations themselves. In order to partially compensate for this, Infoblox builds connectors for the larger platforms in the market. Of course, the company cannot do that for all suppliers, just as these other cannot do that either.
The type of automation Infoblox pursues is quite fundamental. This begs the question whether the market is ready automation between all kinds of security layers. Consider RPA for a moment. That has only took off properly a couple of years ago. Bear in mind that RPA in general is fairly low-level. That has a lot to do with automating repetitive tasks, like extracting data from documents, to put that data into the right fields of another piece of software. The impact if things go wrong is then manageable. With security-related issues, certainly higher up in the stack, things are different. Van Son sees that too, he says. Ultimately the final decision lies with the customers themselves, Infoblox can only try to make it as simple as possible.
Future: Other role for Infoblox?
Infoblox, then, has great ambition for DDI. They want to make their expertise around DDI more broadly relevant. This also means that the role of the company as a whole changes. You can see what Infoblox offers at the moment as a kind of telephone directory of the Internet. This guide tells traffic where to go. In addition, it would also be nice if you could also get insights on how to get there. “Infoblox is now the first thing, but also needs to move towards the second,” Van Son indicates.
This doesn’t mean Infoblox evolves into an SD-WAN vendor, he immediately adds, but it does want to start using the cloud more to get much more out of the rich DNS data. This obviously improves their products and services, but also makes them more relevant to organizations. SASE will no doubt play a role in this, as evidenced by the acquisition of Snaproute last year.
What the future holds for Infoblox (and for DDI data in general) is unclear. Van Son obviously doesn’t want to give away too much on that. With the emphasis on automation around DNS as a security layer and the desire to become not only a telephone directory but also a Google Maps including directions, we can expect plenty of developments. Both from Infoblox as a company and from the use of DDI data in general.
3 hours ago
