2016: Everything connects to something: Make sure it’s the right thing with a smarter DNS infrastructure.
Despite my views on IT predictions I do feel honor bound to read the various predictions out there. Wearables, virtual reality, machine learning, artificial intelligence, autonomous transport, lightsabers (ok, the last one is actually just a more elegant weapon for a more civilized age). In summary: lots of cools stuff, all of which will need to be interconnected to realize it’s full potential (except the lightsabers, although the Star Wars universe unaccountably seems to lack WiFi). It feels as if the days of anything being isolated and unconnected are over and gone (at least for now).
In the world of connected everything managing the connections from client to server is an essential component of any service. Because the client needs to connect to a service that is:
- Safe – not a malicious man in the middle, compromised or completely fake (IoT phishing anyone?)
- Working - not over loaded, failed or malfunctioning
- Performant – this might mean geographically near, or simply having enough capacity to service the connection, or being able to use the optimal connection style for the client.
So how are we going to do all this? A key component is going to be DNS. DNS is the system that allows clients to find and connect to servers. Without DNS we are back to the world of hard coded IP addresses – which is a place no-one wants to go. To an extent, a DNS server has a simple job – it (mainly) answers questions for name resolutions – e.g. “what is the IP address of www.f5.com?”. The trick is to make sure it gives you the best answer to any question, and one you can rely on. Your DNS layer, as much as any part of your infrastructure, needs context and credibility. I’m betting you rarely guess an answer to an important question. I’m also betting you don’t you want your DNS server doing it either.
The context comes from knowing where the client is coming from (although there is some extrapolation here, since most requests will come from other DNS servers), and the state of the potential resources that the client could connect to. You’re going to need to have accurate and relevant checks on availability and capacity to decide where to send a client. You might need to know the nearest physical location to the client and the network they are on. Since you can configure every client type to ask for a different variant of the address (e.g. “what is the address of mydevicetype.mycompany.com?” you can provide an individual, optimized endpoint for each device type ( possibly using an advanced application and network proxy like a BIG-IP ).
The credibility comes from the ability to cryptographically sign the DNS response – using the same kind of certificate based system that powers TLS. It’s called DNSSEC. With a signed response, you can be assured that clients (whether these are devices, VR helmets or the car transporting you) are connecting to where you want them to, not to where someone else wants them to.
So, if you want to be sure that your clients are connecting to the right places, then build a DNS layer that has context and credibility. You might even want to take a look at F5 BIG-IP DNS to do it with.