Articles

Route 53 Query Logging to CloudWatch: Enable and Analyze (2026)

April 18, 2026 5 min read

Route 53 query logging is a powerful tool, but most people completely miss its primary value: it’s not about what is being queried, but how many and from where.

Let’s see it in action. Imagine you’ve got a domain, example.com, and you’ve enabled query logging for its hosted zone.

{
  "eventVersion": "1.08",
  "message": "7a07978e-011d-4c1f-8b2b-7c2a4b7a1b1b: QUERY_LOG_DATA - 2023-10-27T10:00:00Z \"192.168.1.100\" \"A\" \"example.com\" \"NXDOMAIN\" \"AWS:Route53\" \"Z1A2B3C4D5E6F7\" \"Z1A2B3C4D5E6F7_us-east-1\" \"192.0.2.1\" \"10.0.0.5\" \"UDP\" \"NOERROR\" \"0\" \"0\" \"0\" \"0\" \"0\" \"0\" \"0\"",
  "region": "us-east-1",
  "recipientArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/route53/Z1A2B3C4D5E6F7",
  "facility": "AWS:Route53",
  "logType": "QUERY_LOG_DATA",
  "accountId": "123456789012",
  "logGroup": "/aws/route53/Z1A2B3C4D5E6F7",
  "logStream": "Z1A2B3C4D5E6F7_us-east-1",
  "timestamp": 1698397200000,
  "messageFormat": "QUERY_LOG_DATA",
  "messageContent": "7a07978e-011d-4c1f-8b2b-7c2a4b7a1b1b: QUERY_LOG_DATA - 2023-10-27T10:00:00Z \"192.168.1.100\" \"A\" \"example.com\" \"NXDOMAIN\" \"AWS:Route53\" \"Z1A2B3C4D5E6F7\" \"Z1A2B3C4D5E6F7_us-east-1\" \"192.0.2.1\" \"10.0.0.5\" \"UDP\" \"NOERROR\" \"0\" \"0\" \"0\" \"0\" \"0\" \"0\" \"0\""
}

This log entry, when broken down, tells us a lot. The key fields are:

  • eventVersion, message, region, recipientArn, facility, logType, accountId, logGroup, logStream, timestamp: These are standard CloudWatch Logs metadata.
  • messageContent: This is the core.
    • 7a07978e-011d-4c1f-8b2b-7c2a4b7a1b1b: A unique ID for the query.
    • QUERY_LOG_DATA: Indicates the type of log.
    • 2023-10-27T10:00:00Z: The timestamp of the query.
    • "192.168.1.100": The client IP address making the query.
    • "A": The DNS record type requested (e.g., A, AAAA, MX, CNAME).
    • "example.com": The domain name being queried.
    • "NXDOMAIN": The DNS response code. NXDOMAIN means "non-existent domain." This is often a critical indicator.
    • "AWS:Route53": The service generating the log.
    • "Z1A2B3C4D5E6F7": The ID of the Route 53 hosted zone.
    • "Z1A2B3C4D5E6F7_us-east-1": The specific log stream name.
    • "192.0.2.1": The IP address of the Route 53 resolver.
    • "10.0.0.5": The source IP address from the client’s perspective (this can be the same as the client IP or an intermediate resolver).
    • "UDP": The protocol used.
    • "NOERROR": The DNS response code (this is a bit confusingly named; NXDOMAIN is also a valid NOERROR response).
    • The remaining "0" values represent various flags and counts that are less commonly used for general analysis.

The real power comes from aggregating these logs. Most people focus on specific queries for a domain. But the true insight is in the volume of queries and their sources, especially NXDOMAIN responses.

Enabling Query Logging:

  1. Navigate to the Route 53 console.
  2. Go to "Hosted zones" and select your zone (e.g., example.com).
  3. Click the "Details" tab.
  4. Under "Query logging," click "Create query logging."
  5. Choose "Send to CloudWatch Logs."
  6. Select or create a CloudWatch Logs log group. A good practice is to name it descriptively, like /aws/route53/example.com.
  7. Click "Create."

Route 53 will then automatically start sending query logs to the specified CloudWatch log group.

Analyzing Query Logs in CloudWatch:

Once logs are flowing, you can analyze them using CloudWatch Logs Insights.

Common Use Cases & Analysis:

  1. Identifying Misconfigured Clients/Applications: A high volume of NXDOMAIN responses for a specific domain from a particular client IP is a strong indicator that something is trying to resolve a non-existent hostname. This could be a misconfigured application, a bot, or even a malware infection.

    • Query:
      fields @timestamp, clientIp, query, type, responseCode
| filter responseCode = "NXDOMAIN"
| stats count(*) by clientIp, query
| sort count(*) desc
| limit 20
    • Analysis: Look for clientIp addresses with a disproportionately high number of NXDOMAIN responses for specific query names. This tells you which internal or external IPs are having trouble resolving names.

  2. Detecting DNS Amplification Attacks: While Route 53 itself is a managed service and less susceptible to direct DNS amplification attacks against your domain, understanding query patterns can help detect if your domain is being used as a reflection source (though this is rare for Route 53). More commonly, you’d look for unusual spikes in query volume from unexpected IPs.

    • Query:
      fields @timestamp, clientIp
| stats count(*) by bin(5m), clientIp
| sort count(*) desc
| limit 20
    • Analysis: This shows you the top client IPs by query volume over 5-minute intervals. A sudden, massive spike from an IP that doesn’t normally query your domain warrants investigation.

  3. Troubleshooting Resolution Issues for Specific Records: If users report that a specific subdomain (e.g., api.example.com) is intermittently unreachable, query logs can help.

    • Query:
      fields @timestamp, clientIp, query, responseCode
| filter query = "api.example.com"
| stats count(*) by bin(1h), clientIp, responseCode
| sort @timestamp desc
    • Analysis: This shows you who is querying api.example.com and what the response code is, aggregated hourly. You can spot if certain IPs are consistently getting NXDOMAIN or other errors for that specific record.

  4. Understanding Traffic Patterns: Beyond errors, you can see normal query volumes and types.

    • Query:
      fields @timestamp, query, type
| stats count(*) by bin(1h), query, type
| sort count(*) desc
| limit 20
    • Analysis: This gives you a sense of which subdomains are most frequently queried and what record types are being requested. Useful for capacity planning or understanding application usage.

  5. Geographic Analysis (Indirectly): While query logs don’t directly provide geo-location, the clientIp field can be used with third-party IP-to-geo databases or services (like MaxMind GeoIP) to understand the origin of your DNS traffic.

    • Query (example with hypothetical integration):
      fields @timestamp, clientIp, query, responseCode
| parse clientIp with '\"*\"' as clientIp
| geolocate clientIp as geo
| stats count(*) by bin(1d), geo.country, responseCode
| sort count(*) desc
    • Analysis: This helps you understand if your DNS traffic is coming from expected regions. Unexpected traffic from certain countries might indicate a security concern or a need to optimize your DNS for those regions.

The most impactful insight from Route 53 query logs often comes from analyzing NXDOMAIN responses. When a client requests a domain name that doesn’t exist, and Route 53 returns NXDOMAIN, it’s a signal that something in your environment (or an external entity) is trying to reach something that isn’t there. This is a prime indicator of misconfiguration, outdated DNS records, or even potential security threats like malware attempting to contact command-and-control servers.

The next step after mastering query logging is often integrating these logs into a more robust monitoring and alerting system, perhaps using CloudWatch Alarms based on specific query patterns or thresholds.

Want structured learning?

Take the full Route53 course →