Two Critical Ways to Prevent Developers from Breaking DNS

As enterprises lean further into strategic initiatives involving cloud adoption, we're seeing and feeling an increase in operational issues involving broken DNS. From Robinhood to Bunny to Salesforce: the impacts are global.

Today, organizations are grappling with a paradigm shift. The network has always been critical, but the previous approach involved keeping it static. Now, as technical innovation becomes a much more impactful differentiator, organizations must keep the network reliable while also applying an immense amount of change to it. Think: new application development, mergers and acquisitions, global sprawl – the list goes on.

We, as an industry of technology professionals, haven't fully figured out how to do this seamlessly, and it shows. The analyst firm Enterprise Management Associates (EMA) identified that the following business issues plague nearly all large enterprises as direct outcomes of dysfunction between their development and networking organizations: significant downtime, application rollout failure and delays, customer loyalty issues, and more.

While EMA’s research certainly highlights several actionable areas, below are two DNS-specific recommendations for technology leaders to act on when it comes to how developers interact with the network. These will ultimately reduce the chances of creating significant DNS-related issues.

Stop expecting the developer to be a DNS expert

By and large, the developer isn’t writing code to orchestrate DNS operations. Rather, they are orchestrating the deployment of an application which requires changes to DNS.

Knowing this, what technology leaders (and, by extension, vendors) must provide to developers are higher-level APIs that software tools like Terraform call for, as opposed to vendor-specific APIs that require knowledge of how all the underlying gears work. An IT help desk ticket that requires a developer to know the nuances of what they’re asking for is even worse.

The challenge and purpose of today's IT department is to make previously implicit information explicit so that technical and business logic can be built into safe and effective automations. When you rely on a developer to make the exact right call, or even when you rely on a domain expert downstream to hand-pick for the developer based on their implicit knowledge of the network, you risk operations and slow down innovation.

Design the DNS architecture to avoid siloing

While the world of public DNS (i.e., the internet) is governed by the delegation of authority that facilitates the rapid identification of an authoritative answer, large enterprises have largely passed on that best practice. Many of today's large enterprise networks are a rat's nest of disparate on-premises zones, cloud instances, and orphan zones, often connected by a fragile set of distributed forwarding rules.

As an enterprise grows, acquires new IP real estate, consumes more cloud, etc., technology leaders must do the work up-front to ensure that complexity is accounted for in the architecture. Accomplishing this is a matter of:

Otherwise, developers will do what they've done before. In the past, this has meant hard-coded IP addresses in applications. Today, with modern and often cloud-native applications, it may mean siloed DNS. Regardless of the "era," developers may willfully circumvent processes and requirements meant to ensure security and reliability and create sub-optimal paths that significantly drive up costs. They’re not bad people (heck, I consider myself to be one of those developers), but their incentives are aligned to encourage that sort of behavior – especially: ship.

The role of IT, and technology leaders, in the coming years, will consistently be defined by how accessible services can be made to end-users. To do so, IT will seriously need to re-evaluate its current infrastructure to best respond to essential questions like, can we democratize access to DNS in a safe way? Allow developers to meet their goals securely and rapidly without impediments. Otherwise, they will continue to do what clearly doesn't work.

Andrew Wertkin is Chief Strategy Officer at BlueCat.