f5fridayMost of the time when we think about (and honestly, talk about) “programmability” of app services (in the network) we end up illustrating its potential by using load balancing or perhaps app security.  That’s because the possibilities seem endless for those services, with countless examples to be found.

But the power of programmability associated with app services – the “software defined” piece of Software Defined Application Services (SDAS) – is not relegated to just load balancing and app security. It can also be applied to other app services, like DNS.

I know, DNS is not often associated with app services but it is. It’s use today is almost exclusively to direct users to the right location of an app on the Internet. It’s an app service, translating IP addresses into much more interesting (and memorable) host names.

And it’s vulnerable. Right now.

The Internet (or at least parts of it) got pretty upset by the notice that BIND (probably the most ubiquitous DNS implementation on the planet) was vulnerable to CVE-2015-5477. It would probably get more attention (and the entire Internet upset) if it had a snazzy name like “Stagefright” or “Heartbleed” but DNS is used to being left out of the spotlight that way.

It is getting noticed, however. Just not by the kind of folks you invite to the data center for a tour.

Ars Technica is reporting the vulnerability is being actively exploited and the accompanying article contains more information on how to grep through those logs to find out if you’re under attack.

Now that you know that, you might wonder what to do. Well, there is a patch – that’s always best way to address a vulnerability. 

That said, what caught my eye was a statement in an article (that shall remain nameless and linkless) claiming “There’s no specific way to protect against the attack, other than installing the patch immediately.”

Actually, there is. Which brings us to the point of this post: programmability.

BIG-IP DNS is just as programmable as the other app services that make up the “Availability” services in F5 Synthesis. Those are load balancing and global server load balancing, if you were wondering. DNS is critical, CRITICAL I say, to availability. Without DNS most mobile apps would simply stop working because they depend on importance data path programmability 2014DNS to locate its data-center counterpart for login and status updates and what-have-you. Without DNS most people would assume the Internet was broken because they don’t actually memorize the IP addresses of the sites they frequent.

And when that DNS is either served directly by or virtualized by BIG-IP DNS, well, it’s also programmable. It’s got a full set of DNS related rules that can aid in just the situation we find ourselves in today: a vulnerability that threatens it.

A very short rule (really, it’s 6 lines and that’s counting the closing braces required) will simply reject any DNS “TKEY” request. Go ahead, you can check it out right here on DevCentral. 

That’s important to know in case you can’t patch immediately for any number of reasons that often cause delays in patching platforms – especially in large organizations. The blast radius from a patch gone bad in the network to any critical service (like DNS) can be daunting enough to encourage a more cautious approach. That’s one of the reasons programmability is an invaluable tool in the security toolbox – because it allows for immediate virtual patching of a vulnerability until the service or platform or application is patched through normal channels.

The ability of organizations to use programmability of app services to respond to threats like this (and others) is important. The majority of respondents in our State of Application Delivery 2015 report (spoiler: and again in our upcoming 2016 report) placed a high level of importance on just this capability and no doubt they take advantage of it to tailor application services to address the unique challenges every organization eventually faces – as well as the shared challenges posed by vulnerabilities across the application and infrastructure stacks.