Cloud DNS Security – How to Protect DNS in the Cloud

Originally published by Sysdig here.

Written by Brett Wolmarans, Sysdig.

When using DNS in the Cloud, security cannot be overlooked. This article is for cloud architects and security practitioners who would like to learn more about deployment options for DNS security and some security best practices for DNS in the Cloud.

You will learn DNS best practices for DNS security, and see the advantages of a cloud approach for DNS. The three main requirements for DNS are:

• Reliability
• Performance
• Security

In this article, we begin with DNS basics, then move on to the topic of DNS in the Cloud. Next we will dig deeper into DNS security, and finally finish with some recommendations to help you decide on a “Build vs Buy” approach for your DNS needs.

Let’s look at DNS basics. Readers who are quite familiar with DNS and just want to learn about DNS in the Cloud may wish to skip ahead.

What is DNS?

As you may know, DNS is short for Domain Name System. As originally defined in 1987 by Paul Mockapetris, and augmented later on by no less than 45(!) other RFC’s the DNS is the phone book of the Internet (for those of us who remember phone books).

When it comes to actually connecting to a website, instead of a phone number, we use a DNS client to ask a DNS server the IP Address of that website. And instead of a contact name, we look up the Fully Qualified Domain name (also known as the hostname) for example www.sysdig.com and if DNS does it’s job, we receive as an answer the IP address for www.sysdig.com, and now we can connect.

How does a DNS query work under the Hood?

DNS isn’t just for phones and PC’s. It is also used by Internet-connected kitchen appliances such as fridges or coffee makers! Let’s start with a diagram to show the basic steps of a simple DNS lookup.

The DNS is organized in a hierarchy, at the top of this are root servers, below that the top-level domains (.com, .net, .org), as well as country domains. Root servers are located all around the world, and must be architected in a robust, bomb-proof manner.

As far as the transport protocol, UDP port 53 is your friend but lately also TCP port 853. We don’t see the DNS lookups from our apps or web browser, so here is one from the command line using dig as the DNS client.

Note: I considered going with nslookup, but at Sysdig, we prefer dig!

Earlier I touched upon the privacy issues of unencrypted DNS being monetized without your knowledge. Fortunately, relatively exciting developments like EDNS, Client Subnet indication, and of course DNS over HTTPS (DoH) and DNS over TLS (DoT) are making things better including functionality and privacy.

DNS is very big. According to the Verisign Domain Names report the first quarter of 2022 closed with 350.5 million domain name registrations across all top level domains (TLD’s). Of which there are approximately 1262 TLD’s including the original 8.

DNS Use Cases & Architectures

There are two main DNS server use cases and two main deployment architectures.

1. As an internal DNS server for everything we need to resolve inside our organization. Such as (and notice how archaic some of this sounds) file servers, mail servers, print servers and thousands of other types of devices that make the traditional organization network tick.
2. As an Internet facing DNS server for queries coming from the Internet. In a remote-work, post-covid SaaS world, this may handle not only our customers, but our employees as well.

And of course, most organizations are going to have both of these use cases. Sometimes combined on the same server, some using separate servers. Using DNS Views or “Split DNS” is a DNS best practice for this.

The two main deployment architectures are

1. Build your own DNS infrastructure. This approach was the only choice for the first twenty or so years of the Internet, and has been a mixed report card. A DIY approach to DNS generally speaking, difficult to get right, especially at scale. But now we have choices.
2. Use DNS in the Cloud. Leveraging DNS as a service has been an option for at least the last ten years and more and more this is being embraced. Many reasons make this a viable first option, not least of which being everything is moving to the cloud.

In this article, we will focus on DNS in the cloud.

DNS in the Cloud Architecture

Looking at the basic high level architecture of hosted DNS providers, a common theme emerges. Internally, each of these providers has some of their own secret sauce but that is out of scope for this article and for the most part it’s not actually public information.

Publicly documented information on how these providers have build their DNS service reveals a common, edge network, anycast architecture that looks like the following:

With Anycast, globally dispersed DNS servers advertise a single identical IP address which propagates out via the magic of BGP. Layer 3 routing then naturally causes DNS queries to arrive at the closest server. This provides redundancy, performance, reliability, and the lowest latency.

Based on this, we have constructed this view of the high-level architecture for DNS in the Cloud:

A cloud DNS provider deploys a fleet of DNS Servers on a global anycast edge network, and offers DNS as a service to their customers. Customers use an API or Web Interface to configure their zones and delegate their domain to the Cloud DNS provider. The DNS provider takes care of replicating the customer configuration across the entire fleet of servers.

After that, the flow is as follows.

1. DNS Queries are routed to the closest DNS server, based on the magic of Anycast
2. A cloud DNS server consults the customer configuration for the FQDN (Fully Qualified Domain Name) being queried.
3. The cloud DNS server usually adds health checking and geolocation to the algorithm. This ensures that an answer which is returned points to a resource which is “healthy” meaning up and available.
4. A DNS answer is returned, for a healthy resource with low latency relative to the original query

Shared Responsibility Model

If we zoom in we see a Shared Responsibility model for DNS in the Cloud.

• The hosted DNS provider is responsible for the deployment, upkeep, security, digital security, performance, and reliability of the DNS servers themselves
• The customer is responsible for their specific configuration:
  • Domains including domain registration.
  • Zones and Records, mapping FQDNs (Fully Qualified Domain Names) to cloud resources such as VMs or hosted Zones.
  • Administration user accounts.
  • Health check configurations for Resources (including the frequency and the timeout interval).
  • Geolocation Records for Resources

DNS in the Cloud Capabilities

DNS in the Cloud (also known as hosted DNS, or DNS as a Service) is an alternative approach to DIY, and has key benefits.

Note: DNS in the Cloud is not where you stand up BIND on your AWS EC2 instance. DNS in the Cloud means you outsource the DNS hardware, software, and for the most part, the DNS Security. There is no BIND or other DNS software to maintain, there is no OS or VM to maintain. The DNS engine is abstracted from you, you only need to handle your side of the shared responsibility model.

DNS in the Cloud opens the door to many optimizations ( such as for Anycast covered earlier ). On a modern web page, every image, add button, widget, link, icon, and other embedded content may have a unique hostname, and a top-level page, for example www.cnn.com requires over 100 DNS lookups to load the page!

And thankfully DNS is the Cloud is really fast, look at how many of these give you single-digit millisecond response times? You can try this out for yourself from several different geographic locations at https://www.dnsperf.com/

Source: https://www.dnsperf.com/

Benefits of DNS in the Cloud

DNS in the Cloud benefits go beyond low latency, security and reliability. Here are the major benefits of DNS in the Cloud:

• Security. More on this below, but essentially you outsource the DNS server itself, you don’t have to worry about keeping your BIND or other DNS software patched and secured to prevent the latest hack, you don’t have to worry about DDOS attacks taking down your DNS server, or any of the other nasty vulnerabilities and attacks that would affect a DNS server that you have to care and feed. Arguably the most famous DNS software bug in all of recorded history is of course the Kaminsky attack first announced by the late Dan Kaminsky at BlackHat 2008.
• Performance. DNS in the Cloud is really, really fast. Due to hundreds of DNS instances and Anycast, this is going to be faster than anything you’ll ever achieve standing up your own Internet facing DNS servers. There’s some interesting testing that has been done comparing cloud hosted DNS performance that you can read about.
• Tribal Knowledge. If your hosted DNS in the cloud is on your cloud provider, for example in the case of AWS, there is powerful integration capability. For example, Route53 knows about AWS resources, so you can leverage AWS-specific perks such as health checks against load balancers, routing rules based on the services, and more.
• Pricing. DNS as a service such as Route53 is so affordable and performant, it has been used for creative ideas like using it as a really cheap and powerful database server!
• Reliability. More than just Anycast, Fault Tolerance, Scale, and Reliability share top honors with performance when it comes to DNS requirements. DNS in the Cloud is without a doubt going to be more reliable than anything you could build yourself, unless you have the budget of a massive web cloud provider. As an example of how reliable hosted DNS can be, AWS Route53 is the only AWS service that offers a 100% uptime SLA. If there is an outage, this may actually manifest as refund credits on your AWS bill, so you may need a backup provider to get closer to true 100% uptime. See more later on stacking multiple providers for greater redundancy.

Another benefit of using DNS-as-a-Service is to stay as far away as possible from the implementation details of the DNS engine. BIND of course springs to mind here. The good news is most of the major cloud DNS providers either use a customized BIND or don’t use BIND at all which removes a very big variable.

Integrated Cloud DNS

Many of us are deploying to the public cloud, and have a cloud-first strategy for business applications. So with our applications and services already in the cloud, does it make sense to have DNS that has awareness of the cloud services and can leverage them?

What is Integrated Cloud DNS?

Integrated Cloud DNS is a term I have recently come up with, because I think we needed a way to describe hosted DNS from a cloud provider that includes special hooks into the other native services. These hooks are what provide the integration.

Generally speaking, cloud patterns emphasize a loosely-coupled pattern and while we wouldn’t want to endorse tight coupling, there are of course exceptions as with any general rule.

Specifically, when the IP address you are mapping to DNS are services in your same cloud provider, firmer” coupling between DNS and these services offers some real advantages. Naturally, this is intentional on the part cloud providers because this helps drive adoption and loyalty to their native service offerings.

And then are a few forcing functions for using Integrated DNS, sometimes even if you don’t want it you’re getting DNS as a side-effect. For a specific example, think about spinning up a resource such as an EC2 instance – this automatically generates a DNS record for that resource. And probably your developers will start to use those records.

This “firm” coupling provides benefits such as:

• One less set of credentials to worry about – DNS service can take advantage of your existing Identity and Access Management (IAM) policies.
• Health Checks based on something logical rather than an IP Address, specific examples being the Instance IDs and Tags. Very useful when IP Addresses may change from time to time, but AWS EC2 Instance IDs and Tags are going to be durable for much longer than an IP address.
• Audting chagnes and Logging with existing Cloud logging mechanisms such as AWS Cloud Trail.
• Integration with existing Cloud Security controls and policies such as AWS Guard Duty.

But let’s look at specific examples to illustrate what I am talking about:

Amazon Route 53 has bespoke integrations with other AWS services including Amazon IAM, Amazon API Gateway, Amazon ELB, Amazon VPC, AWS S3 Buckets, and more. Here is a simple example, best shown visually:

Here is another example of how Amazon Route 53 integrates with Kubernetes Clusters

And when it comes to security, there are elaborate integrations for DNS Security.

Integrated Cloud DNS Compared

Two major Integrated Cloud DNS offerings are Google Cloud DNS and AWS Route 53.

Google Cloud DNS has many great features that make a case for tight coupling. As does AWS Route53. But while Route 53 has been integrated with AWS Load Balancing for many years, Google Cloud DNS is just getting started with their own load balancer integration.

Google Cloud DNS best practices are somewhat generic and not very specific but they include:

• Use conditional forwarding
• Use DNS peering
• Open Google Cloud firewalls to allow DNS traffic

Digging into AWS Route 53, like Google Cloud DNS, it has many features that you just aren’t going to get if you stand up a traditional DNS server in your VPC.

When using AWS Route 53 there are several DNS best practices that seem to be substantially more specific including:

• Setting a TTL of 60 or 120 seconds for rapid failover mechanism
• Use data-plane Route 53 health checks
• Leverage Route 53 alias records instead of CNAME records
• Always a default for Geolocation based Routing

Of course we have to include of course the very nice integration AWS Route 53 has with AWS Load Balancing.

But a more interesting example is AWS Route 53 has a tightly-coupled integration with AWS EKS Elastic Kubernetes Service for ExternalDNS. This feature requires AWS Identity and Access Management (IAM) permissions that allow Amazon EKS access to Amazon Route 53.

These tangible benefits are a DNS best practice, and would be very difficult to achieve with a roll-your-own approach, and are a great example of the benefits of tight coupling, although of course the usual trade-offs of tight coupling apply such as deeper lock-in to the particular cloud provider.

We can’t forget administrative audit logging: Like with Google Cloud DNS, any changes made in the AWS account for AWS Route 53 will be tracked. In the case of AWS, this tracking is done with CloudTrail in as close to real-time as CloudTrail gets.. Now all you need is to figure out which changes are dangerous, which may require additional solutions or tooling.

Wouldn’t you like to know if somebody in your AWS account is Associating VPC’s with a Hosted Zone, Changing Resource Record Sets, Registering Domains, or engaging in other risky behavior around your Route 53 configuration?

When it comes to Google Cloud DNS for GCP, and the AWS Route 53 DNS service, let’s dig into how they stack up.

Cloud DNS Compared: Google Cloud DNS vs AWS Route 53

Cloud DNS Feature	Description	Google Cloud DNS	AWS Route 53
Authoritative DNS lookup	Translates requests for domain names like www.google.com into IP addresses like 74.125.29.101	X	X
Cloud IAM	Integration with IAM provides secure DNS domain management with full control and visibility for DNS resources.	X	X
Cloud Logging and DNS Monitoring	DNS logs a record for every DNS query received from VMs and inbound forwarding flows within your networks. You can view DNS logs in Cloud Logging and export logs to any destination that Cloud Logging export supports. DNS Monitoring logs DNS queries and responses, and provides performance statistics and metrics essential to understanding how DNS is being used by our application teams.	X	X
Wide selection of Routing Policies	There can be more than one way to route a DNS query and response, and to name a few: Weighted round robin (WRR) routing policy, Failover routing policy, Geolocation routing policy, Geoproximity routing policy, and a Latency routing policy	X	X
Global IP Anycast	Enable the use of a logical nameserver, on multiple physical servers deployed worldwide	X	X
Manage DNS as code	Deploy DNS using DevOps approaches, store your Zone Files and other DNS config artifacts in GitHub or your Git-based repository of choice, and run them through a deployment pipeline just as your would any other code using Terraform which works on Akamai, GCP, and AWS, or using the cloud provider’s native methods such as AWS Cloud Formation Templates	X	X
Private Endpoints	Traffic between your virtual network at the cloud provider and your datacenter travels on the Cloud provider backbone network. These private links terminate at private Endpoints, which DNS needs to resolve	X	X
Record Types Supported	While we are probably familiar with A records such as www.sysdig.com that resolve to a single IP address, there are many different types on DNS Records	X A, AAAA, CNAME, MX, TXT, PTR, SRV, SPF, NS, SOA	X A, AAAA, CNAME, MX, TXT, PTR, SRV, SPF, NS, SOA, DNSKEY, DS, IPSECKEY, NAPTR, SSHFP, TLSA, CAA
Domain Registration		X	X
Health Checks	Health Checks originate from the DNS service, and do not depend on other services like Load Balancers. Health Checks monitor the health and performance of your web servers and other cloud resources	X

Cloud DNS Security Features Compared: Google Cloud DNS vs AWS Route 53

Cloud DNS Security Feature	Description	Google Cloud DNS	AWS Route 53
Response Policy Zone (RPZ)	Using RPZ, a network or DNS administrator can implement their own protection policies based on reputation feeds from security service providers on a near-real-time basis	X	X
Secure Transports: DNS over HTTPS (DoH)	DNS over HTTPS (DoH) encrypts communication between the DNS client and server, preventing intermediates such as ISPs and cloud providers from tracking DNS requests	X
Secure Transports: DNS over TLS (DoT)	Much like DoH, DNS over TLS (DoT) encrypts communication between the DNS client and server, preventing intermediates like ISPs and cloud providers from tracking DNS requests		(planned)
DNSSEC	Prevent many DNS attack types caused by DNS forgery with Domain Name System Security Extensions (DNSSEC)	X	X
Audit Logging and DNS Monitoring	Log every administrative change made to the DNS in real-time. DNS Monitoring alerts us if the service is degraded	X	X
Trust-based model	Prevent IP address spoofing DNS attack types by only serving content to a list of trusted nameservers	X	X
DNS Firewall	A full-featured DNS Firewall protects against DNS attack types, includes automatic detection for malware, domain generation algorithms, DNS data exfiltration (which misuses DNS to exchange unstructured data between attacker and victim), and custom block/allow lists		X Yes, subset only: Block DNS queries for known malicious domains, Monitor and control the domains that your applications can query

Stack Multi-Cloud DNS

Earlier in this article we talked about how the original highly-distributed intended deployment of the DNS has actually been consolidating, and referenced several scholarly articles of research on why this is a bad thing. The famous Dyn attack is of course what should be springing to your mind as you read this, as so many large web properties didn’t actually have a backup DNS provider.

But it’s actually very easy to avoid being impacted by the next Mirai attack: Don’t put all your eggs in one basket. Use multiple cloud DNS providers.

While DNS insists on at least two authoritative name servers (NS) , those are rookie numbers and you can keep going to 4,6,8 or even more, and balance those out among multiple Cloud DNS providers. You will have to keep them in Sync of course.

So to bolster this recommendation, here is a screenshot I made of looking up the DNS servers for three large financial organizations in North America that you will probably recognize.

You can see by the responses to the dig command that the first of these outfits appears to be hosting their own DNS utilizing a DIY approach, whereas the second and third are using the “stacking” approach of have multiple DNS in the Cloud (also known as DNS as a Service) providers, giving them redundancy that may be very difficult to achieve otherwise. One of them is using both Ultradns and Akamai, and the other is using NS1 and Akamai.

DNS Attack Types and Dangers

DNS Dangers may be obvious ones like DDOS and sneaky hacks but we can’t leave out configuration mistakes that might leave DNS exposed and vulnerable, or cause an unintended outage.

The main types of DNS Dangers can be sorted into three categories:

1. Denial of Services based on volumetric DDOS
2. Hacks and exploits
3. Blunders and self-inflicted wounds

DDOS Attacks

Both Dyn and AWS Route53 have been subject to massive DDOS attacks in years past, and while these did cause disruption, just imagine what a 1.2 Terabit-per-second DDOS attack would do to your own self-hosted DNS infrastructure.

The Dyn Mirai Attack prevented DNS resolution for websites used by millions of people such as Reddit, the New York Times, Twitter, Netflix, GitHub, and AirBnb to name a few. This attack leveraged Mirai to take control of an army of IoT devices to attack Dyn from tens of millions of source IP’s. More recently in June of 2022, security researcher Brian Krebs reports on the progress of the prosecution of criminals running a business offering tools to launch DNS-based DDOS attacks.

Lots of Eggs, few Baskets

In the case of Dyn, why did “the internet” stop because a single DNS provider was under attack? In theory, DNS is supposedly fully redundant by virtue of being totally decentralized, but it turns out it is actually only pseudo-decentralized. Out of the top 500 websites according to Moz.com, 181 use one of the above 5 services as their DNS provider.

You can dig more into this topic in this great paper Evidence of Decreasing Internet Entropy: The Lack of Redundancy in DNS Resolution by Major Websites and Services by researchers at Harvard.

DNS Hacks

If DDOS is a sledgehammer, there are other DNS Attack Types that are more like a surgical instrument. It’s difficult to categorize all these DNS Attack Types, but high level you have two major categories of hacks:

1. DNS Hacks from the inside out such as DNS Tunneling
2. DNS Hacks from the outside such as DNS Spoofing and Cache Poisoning

From simple Google Dorks to find subdomains ( site:*.sysdig.com -www -store -jobs -uk ) to all sorts of cool tools on Github there are many ready-made options for abusing DNS.

DNS Hacks from the inside are exemplified by the many DNS Tunneling and exfiltration DNS attack types. Generally in these types of attacks, the hacker exploits the fact that DNS packets are almost always generally allowed out to any IP address by firewalls. As a writer at Infoblox wrote a rather brilliant take on DNS Smuggling: “DNS Data Exfiltration is like stealing a car without opening the garage door: You have to break the car down into small chunks that fit through the doors and windows, and then rebuild the car outside.” which I think is a very clever and amusing analogy.

Here’s a very simple example of DNS Smuggling (there are others):

Assuming an attacker is already inside your network, has access to a database of credit cards, but wants to send out credit card numbers out undetected.

The attacker stands up a DNS server on the Internet and registers some innocent sounding domain name like “windows-server-update-microsoft.net” which just so happens to be available for about twelve bucks at the time of this blog post.

Note: Don’t even think about registering this domain! I’m simply showing you how slippery this slope can get. You’d think Microsoft with their spare change in their couch cushions could easily afford some data scientists to run some Domain Generating Algorithms focused around the keywords “update” and “windows” and simple register all these domains ahead of time… but here we are:

On their DNS server, the attacker enables query logging so that every query gets logged. And then from their toe-hold inside the network, they run a script looping through all the credit card numbers and appending them to the DNS domain like so:

Now that you know how DNS works you can see this query doesn’t go to the windows-server-update-microsoft.net server… instead, the query goes to the configured local DNS resolver, which in turn forwards it on. And voila, when the query gets to the attackers’ DNS server, the query contents are logged.

But that’s not the only type of inside-out DNS attack. Bad actors once inside your network can target your DNS servers and try to take control of them just like they would any server. The difference being the DNS server is a much richer target than most, as once in control of this, the hacker can direct traffic anywhere they want.

By redirecting common domain names and avoiding crude and easily detected tactics such as having a special DNS name for a command-and-control server, the hacker can avoid detection.

DNS Hacks from the outside include modern side-channel attacks, and DNS hi-jacking such as Sea Turtle, but of course the most well-known is DNS Cache Poisoning.

Classic DNS Cache Poisoning and DNS Spoofing hacks have been around for decades. Mitigations such as DNSSEC have proven to not enjoy wide adoption due to clunky and problematic deployment once the rubber hits the road. Because of how painful it is to configure and maintain DNSSEC, outsourcing to a DNS cloud service which already offers DNSSEC may be a better option.

A big privacy concern is that most DNS servers don’t support encryption, leading to MiTM concerns. Today by default. DNS queries from the Firefox browser are encrypted by DoH and go to either Cloudflare or NextDNS. Yes, overriding what your operating system has configured!

The famous Kaminsky attack demonstrated how BIND’s weak validation on responses allowed an attacker to brute-force the right transaction ID, which at that time, was just a 16-bit number.

There are hacks based on domain names themselves. The sheer number of domain names form a big surface area for confusion attacks based around the text in the domain name itself, including Brand Impersonation, TypoSquatting, CyberSquatting, and Look-a-Like websites.

Domains with alternate TLD, Homoglyph Domains, Hyphenated domains, and domains with keywords like “login” or “www2” or “support” along with the brand are a a foundation to build all sorts of attacks such as domain takeover, OWASP CSRF Attacks, and Phishing.

Whole blog posts could be written on fun DNS tools such as DNS Razzle. For fun, I tried out a slightly simpler tool for domain generating algorithms (DGA) named dnstwist, and here I am running it against the domain name netflix.com to see all the permutations. This could be used for typosquatting attacks, and it’s scary to see how many there are, and it’s unlikely all of those IP addresses belong to netflix!

DNS Misconfiguration, Blunders & Outages

DNS misconfigurations and blunders run the gamut from straight-up misconfiguration mistakes to falling behind on your patching regimen. DNS is notorious for being devilishly difficult to configure. There have been so many bugs in core BIND itself, and they keep cropping up. And cropping up.

Following DNS best practices will help to avoid these situations, but there are many stories of DNS mistakes and confusion out there, such as this one.

And even though some of the biggest organizations in the world might not be immune to making mistakes from time to time, it’s still going to be far more reliable in almost all cases to outsource your DNS to a mega DNS-as-a-Service provider, as they have huge teams of people doing nothing but focusing on keeping the DNS running all the time.

As Aqsa Kashaf, Vyas Sekar, and Yuvraj Agarwal of Carnegie Mellon University wrote in Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident? It makes sense to “stack” multiple DNS providers such that if one goes down, you roll over to a backup DNS provider that is built on totally separate infrastructure. This backup could be another Cloud DNS provider, or it could even be yourself – for example in the wake of the Dyn incident, twitter.com added redundancy by deploying a private DNS in addition to Dyn.

Likewise if you could easily stack hosted DNS providers, for example have both AWS Route 53 (sometimes shortened to Route53) and Google DNS for your NS SOA records, and I personally have seen this with up to 8 NS records for critical domains in the financial industry. After all, nobody wants the DNS to fail for a banking website!

DNS security best practices

DNS is particularly vulnerable to volumetric DDOS attacks (as both the target and a pawn), can be hacked and exploited in various ways, and has a not-insignificant self-inflicted wound dimension to it in that misconfigurations (including failure to keep up with patching) can cause outages and worse.

There are some low-level, very specific DNS best security best practices such as hiding your primary DNS server behind a proxy. And you have to get those right.

But even if you get all the low-level configuration details right, you may still wind up in trouble if you don’t follow high level best practices at a tactical level. We researched the available information and came up with the following high level best DNS security best practices:

Securely Configuring and Patching

If you are building DNS infrastructure yourself, you are responsible for keeping up with CVE’s and other updates to your DNS software. Given the history of monumental bugs in DNS (BIND I’m looking at you) treat your DNS patching as you would your most critical services. Deploy DDOS protection and a DNS firewall. Use DNSSEC where appropriate and consider the privacy implications of DoH. Use multi-factor authentication (MFA) with each account that has access to the configuration, and use TLS 1.2 or higher to communicate with the administration interface.

Know your Domain Names (and who is registering them)

A really basic step is to know all your domain names, and how they map to your applications. Imagine what would happen if this got out of control. Catalog all your DNS Servers, all your zones, and your DNS architecture and topology. A great tactic is to stay on top of domain name creation in real-time by watching cloud logs as described in this blog post.

Deploy a DNS Monitoring Solution

DNS Outages can happen to even the biggest organizations. This is why just as you monitor your application uptime, you will benefit from more granular DNS monitoring as well to understand if DNS itself is causing problems as compared to other issues such as the application stack not performing or database outages. A list of DNS monitoring solutions is here but there are many others as well.

Know your DNS Security Capabilities

Know the security capabilities your existing DNS solution or service provider offers. Get your roadmap from your DNS vendor for security and confirm they are committed to keeping up with developments in DNS security. If you don’t have a DNS solution or service provider that provides security capabilities, dump them and find one that does. See our table of DNS capabilities covered earlier in this article.

Log Abundantly & Effectively

Just as you rely on logs for all aspects of your applications, you need to collect and analyze DNS logs with the same level of priority. Your DNS logs may show early indicators of threat detection and will be critical for remediation using your security information and event management (SIEM) or similar tool. Set up API and user activity logging with AWS CloudTrail.

Deploy Threat Prevention

Use a threat feed to block requests to malicious domains. Using DNS threat filtering early in the kill chain will prevent attacks from ever making a TCP SYN to your web servers. Threat feeds for DNS can also apply to how DNS affects email services. You need to deploy allow lists and block lists where appropriate and monitor DNS traffic for anomalies. Looked at from the opposite perspective, you can use services such as https://www.dnsbl.info/ to find out if other organizations are mistakenly blocking your domains.

Adopt a Cloud-First DNS Strategy

For more than a decade, cloud-first has been the recommended approach as organizations drive digital transformation and modernization. DNS is no different.

It’s easy to make the case for hosted DNS. The simplicity, security, robustness, performance, and effectiveness of DNS in the Cloud should be the default way to deploy. It’s also a good idea to consider “stacking” your DNS providers such that if another Mirai happens, you have a backup provider.

Cloud providers know many customers can’t switch off their home-grown DNS architectures overnight. AWS Route 53 even includes advanced capabilities to integrate your private DNS with AWS, known as the AWS Route 53 Resolver for Hybrid Clouds.

For some corner cases, such as high security, dark environments, and the like, 100% cloud DNS is not suitable, but it should still be your default.

Conclusion

You have seen how DNS is critical for your application and business strategy on the Internet and Intranet.

When DNS isn’t working, nothing works. Even if the services and applications you deploy on the Internet are bulletproof from an application and microservices standpoint, if DNS isn’t working, nobody can consume your services, and things will grind to a halt.

You have learned why it is important to choose the correct deployment strategy.

The most important requirements for DNS are:

• Performance
• Reliability
• Security

There are two basic architectural approaches:

• A classic DIY approach.
  • Building your own DNS is possible indeed, and in legacy environments will persist for many years.
  • Going forward, for new deployments the DIY approach may be limited to corner cases, such as high security environments.
  • Creating a highly scalable, reliable, and efficient DNS infrastructure takes time, money, and expertise.
• Leveraging Cloud DNS
  • The trend in the industry is to use this approach.
  • For most organizations and use cases, this is the best, most cost-effective path to meet DNS requirements.
  • DNS in the Cloud is growing in features and adoption rates

And while you may also have a mix of both, the Cloud-first strategy still applies.

While the decision is in your hands, DNS in the Cloud has a lot of advantages which make it difficult to go in a different direction.

No matter which method you choose, DNS best practices as shown in this article will help guide you to success.