2/5/2018 10:30:25 AM
DNS security and why mobile app developers should care
https://appdevelopermagazine.com/images/news_images/DNSSEC-Chat-with-NS1-App-Developer-Magazine_mjbpicmt.jpg
App Developer Magazine
DNS security and why mobile app developers should care

Android

DNS security and why mobile app developers should care


Monday, February 05, 2018
26,625

DNS security is a big deal but not very well understood when it comes to software development. This discussion with NS1 helps shed light on DNSSEC and what developers need to know about it.

DNSSEC is a DNS security extension specification for securing information provided by DNS. DNS has been a part of the global internet since the 1980s, but its authentication mechanisms are fairly weak. As a result, DNS is vulnerable to a form of attack called cache poisoning. Cache poisoning is a man-in-the-middle attack that implants false DNS information to redirect end users to malicious websites, either to download malware or to steal log-in credential or credit card information. Cache poisoning can also be used by attacker to cause downtime and service outages by having the DNS direct users to resources that don’t exist. In either case it is bad for your users and bad for your brand.

DNSSEC was developed to improve these authentication controls by digitally signing data to assure its validity. In some instances, DNSSEC is a requirement for some new top-level domains (TLDs), such as .banking and .insurance. In other cases, DNSSEC may be a requirement in service level agreements (SLAs). In short, DNSSEC is a best practice that helps protect businesses and their customers from cache theft, loss and downtime.

Here's what NS1's CEO Kris Beevers has to say about the role of DNS in application delivery, the evolution of DNS and the role of DNSSEC in maintaining the integrity of web applications.

Why does a networking technology like DNS matter to application development?


Beevers: In simple terms, you can think of domain name system (DNS) like the Yellow Pages of the Internet. DNS translates URLs like www.google.com into the IP address where they are hosted to remove a layer of complexity for end users. DNS was originally designed to provide this simple phone book function for an internet in which applications were monolithic and hosted in one location.

Today’s applications are globally distributed and multi-tiered. These distributed application architectures make it possible to deliver high performance to millions of users around the world. However, many real time factors such as network conditions, server load, localized outages, and capacity issues – all play into end user experience. The DNS look-up is the first decision the network makes in connecting a user to an application. That DNS look-up determines which of many available points of presence the individual user will be connected to. By building the intelligence into that decision to direct the user to the point of presence that will deliver the best quality of experience possible, DNS can help application developers achieve their performance goals. This ability to make intelligent decisions at DNS look-up time is what differentiates traditional DNS platforms from NS1’s modern, intelligent DNS.

What are common approaches to improving application delivery with DNS?


Beevers: Just as traffic conditions on city streets and on highways change constantly, so do latency and throughput conditions of different paths on the internet. Navigation apps for drivers have evolved from using simple distance based approaches to using real time traffic conditions - saving drivers countless hours. Similarly, a modern DNS incorporates real time network traffic conditions to choose the best route for the end user. Where a traditional DNS technology is like Mapquest, modern DNS platforms are much more like Waze.

Modern, performance driven DNS platforms have a rich set of tools that application engineers can use to improve application delivery. These include techniques such as:

  • Routing users to the best performing (lowest latency) CDN. This allows engineers to take advantage of using more than one CDN provider in their infrastructure.
  • DNS can intelligently balance workloads across multiple data centers. This ensures users are directed to locations with available capacity and prevents localized spikes in user demand from overwhelming the local point of presence.
  • Using “sticky routing” to improve performance by sending returning users back to the location where their information is likely to be cached.

Finally, a foundation of application performance is availability, and if the DNS is not available neither will be any of the applications the DNS points to. It is a truism that if your DNS goes down so does your online business. A best practice is to deploy a redundant DNS architecture to ensure no interruption in service if one of the DNS systems goes down.
A redundant DNS solution may still come from your primary provider as long as they offer a single-tenant solution that operates on completely separate infrastructure (servers, networks, data centers) from their primary DNS services.

So why can’t someone just implement DNSSEC on their own? What are common problems with DNSSEC?


Beevers: It may be simple to understand DNSSEC, but it is hard to implement and manage, which may have major implications for your application delivery infrastructure.

Legacy DNS solutions are built on decades old open source software called BIND that never could have anticipated how pervasive the internet has become in the way we work. Certainly no one involved with the creation of DNS more than 30 years ago anticipated software as a service or web applications as they exist today. DNS was designed as a distributed system, but it wasn’t created for dynamic services.

If you run your own authoritative DNS, then setting up DNSSEC will create more work for your IT staff or DevOps team. They will need to get up to speed of how to implement DNSSEC without disrupting service since there is no implementation support. You may also have to upgrade your server infrastructure since DNSSEC requires additional processing capacity.

A better route is to use a managed DNS provider, but first you need make sure they support DNSSEC - not all do. Most managed DNS providers who support DNSSEC have made it quite easy for their customers to implement it. This removes the burden of inhouse staff needing to become experts in DNSSEC and dramatically lowers risk. However, many providers don’t support intelligent DNS traffic management in conjunction with DNSSEC (you can have one or the other but not both). NS1 has designed its support of DNSSEC so as not to force these trade-offs on customers.

ADM: What are the challenges between secondary/redundant DNS and DNSSEC?


Beevers: Redundant DNS should be considered a best practice, and many enterprises have deployed multiple DNS networks to maximize reliability. However, many providers vary in their support for primary and secondary configurations for DNSSEC signed zones. There may be incompatibility with key algorithms, hashing algorithms and how zones transfers are supported. The solution to this is to find a provider that offers native DNS redundancy options that will meet the goals of availability, security and application performance.

Kris Beevers, CEO of NS1

ADM: How does NS1 address that?


Beevers: NS1 delivers a fully redundant DNS solution, which includes the full suite of DNS traffic management capabilities, all secured with DNSSEC, in fully isolated single-tenant deployments that are independent of NS1’s primary DNS network. It is the only available solution that combines DNSSEC, redundant DNS and DNS traffic management. However, for organizations that work with multiple DNS providers, NS1 also provides the flexibility to integrate with in-house or other managed DNS services to achieve redundancy. In these cases, static (offline) signing is an option to support dual provider set-ups.

The first generation of DNS was based on open source software, deployed on traditional servers and self-managed by enterprise IT staff.

The second generation saw the emergence of managed DNS providers. These providers recognized that enterprises would be better off outsourcing their DNS to a provider that could essentially do better and cheaper than they could. As a result, they focused on deploying DNS servers in multiple points of presence around the globe on a network designed for high resiliency and performance. However, the actual DNS server software they used was (and is) based on the same open source DNS (such as BIND) that the enterprises had deployed themselves. In short, they focused on DNS performance and uptime but they did very little to build modern software to take advantage of DNS’ position as the first, most important decision point that happens when a user clicks on a link. They continued to provide a simple, outdated phone book service when so much more could be done to improve application delivery using the opportunity afforded by DNS lookup.

As a next-generation DNS provider, NS1 provides a highly reliable, robust and high-performance DNS as do the traditional players. In fact, NS1 is a top performer in that regard, but we view that as “table stakes”. As a next generation DNS provider we don’t just deliver a phone book service. NS1 delivers a robust set of automated and intelligent traffic management controls that allow enterprises to improve application availability, performance, and helps enable modernization of their application delivery systems.

About Kris Beevers


Kris Beevers leads NS1’s team of industry experts as they create products to enable companies to use DNS to build and deliver dynamic, distributed, and automated applications that delight users. Kris is a recognized authority on DNS and global application delivery, and often speaks and writes about building and deploying high performance, at scale, globally distributed internet infrastructure. He holds a Ph.D. in Computer Science from RPI, and prior to founding and leading NS1, he built CDN, cloud, bare metal, and other infrastructure products at Voxel, which sold to Internap in 2011.