Maintaining visibility into DNS-related activities is crucial for organizations to ensure the security and performance of their web-based applications. Cloud engineering teams must use tools to effectively monitor and analyze DNS queries to protect from DNS-based attacks and optimize performance for genuine requests. DNS Query logging for Amazon Route 53 hosted zones addresses this challenge by offering a solution to collect, store, and analyze DNS data. This solution empowers cloud engineering teams to enhance security posture, optimize performance, and improve overall DNS management. In this note, you will learn how to enable DNS Query logging using Amazon Route 53 and Amazon CloudWatch log groups. This use case follows DevOps best practices by creating the required AWS cloud resources using Terraform (IAC) and automating the deployment using GitHub actions.

If you are interested and want to follow along, please refer to the GitHub repository: kunduso/add-aws-elb-ec2-private-subnet-terraform. Please note the branch name is add-dns-query-r53.

This note expands on a previous use case, where a static web page was securely accessed over HTTPS (port 443) through a custom domain name instead of the default load balancer DNS. That setup was achieved using Amazon Route 53 for DNS management and Amazon Certificate Manager (ACM) for SSL/TLS certificate management attached to a load balancer to ensure secure, reliable access to the application.

When DNS query logging is enabled for an Amazon Route 53 hosted zone, it captures detailed information about the DNS requests made to the hosted zone. The logs, which include data such as the queried domain name, the query type (e.g., A, AAAA, CNAME), the source IP address, and the response code, are then sent to an Amazon CloudWatch log group. The information in these logs allows cloud engineering teams to monitor DNS traffic in real-time, analyze query patterns, and detect potential security threats, such as DNS-based attacks or unusual traffic spikes.

Additionally, following security best practices, Amazon CloudWatch Logs must be encrypted using a KMS (Key Management Service) key to maintain its confidentiality and integrity. Security best practices also dictate that the KMS key must be configured with a specific permission policy tailored to its intended usage. This practice ensures that only authorized users and services can access and use the key for encryption and decryption operations.

Tying these security best practices together and building on the previous use case, this use case involves: 1. Creating a KMS key and attaching a KMS key policy 2. Creating a CloudWatch log group and encrypting it with the KMS key 3. Configuring DNS query logging for the Amazon Route 53 hosted zone to Amazon CloudWatch logs Please check AWS-Docs for details on enabling DNS query logging via the Console.

Note: AWS requires the CloudWatch log group Logs and the associated KMS key for DNS query logging to be created in the US East (N. Virginia) region (us-east-1). Both resources must reside in this region to ensure proper functionality of DNS query logging for Amazon Route 53 hosted zones.

Pre-requisites: Since this use case builds upon the previous use case, several AWS services have already been created. I recommend that you first review automate-amazon-route-53-hosted-zone-acm-and-load-balancer-provisioning-with-terraform-and-github-actions.

Let us dive deeper into these steps. 1. Create a KMS key and a KMS key policy As mentioned previously and in the AWS Docs, the KMS Key and the policy must be created in the us-east-1 region. The Terraform code creates an AWS KMS key and a key policy to encrypt the query logs stored in CloudWatch Logs.

2. Create a CloudWatch log group and encrypt it with the KMS key In this step, Terraform creates a CloudWatch Log Group to store the DNS query logs with a one-year retention period. The log group is configured with server-side encryption using the specified KMS key, ensuring that all stored DNS query logs are encrypted at rest for enhanced security.

3. Configure DNS query logging for the Amazon Route 53 hosted zone In this step, the Amazon CloudWatch Log group (where the DNS query logs will be sent) is associated with the Amazon Route 53 hosted zone (whose DNS queries are being monitored). With this setup, Amazon Route 53 can automatically create log streams for the DNS queries.

Each DNS query generates a log entry containing details like: - What domain was queried - When the query happened - Which edge location responded - What type of DNS record was requested - The response code

Here is a screenshot from the AWS Console. Using this information, cloud engineering teams can then create CloudWatch Alarms, perform security analysis on the DNS logs, and monitor query volumes, response times, and error codes. The final objective is to transform these raw logs into actionable insights through monitoring, alerting, and automated responses to maintain security and operational excellence.

Multiple AWS Providers Most AWS resources in this use case are provisioned in the us-east-2 AWS region, which is managed using the provider "aws" {} block. However, for DNS query logging, the CloudWatch log group and the KMS key must be provisioned in the us-east-1 region. To handle this, a separate provider with an alias, aws.us-east-1, is used to specifically manage the CloudWatch log group and KMS key in that region. Please refer to the official Terraform documentation for more details on configuring multiple providers in Terraform.

That brings us to the end of this note. If you have any questions or feedback, please use the comments section below. This note is part of a series on elastic load balancing, Amazon Route 53 hosted zones, and Amazon Certificate Manager.

To learn more, please click on the links below. Add an application load balancer to Amazon EC2 using Terraform Add an application load balancer to Amazon EC2 instances in a private subnet Create an Amazon EC2 Auto Scaling group and load balancer using Terraform and GitHub Actions Automate Amazon Route 53 hosted zone, ACM, and Load Balancer provisioning with Terraform and GitHub Actions Attach AWS WAF to load balancer using Terraform and GitHub Actions