---
title: >-
  Possible DNS tunneling or beaconing via high-cardinality A/AAAA subdomain
  queries from a single source IP
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > Possible DNS tunneling or beaconing via
  high-cardinality A/AAAA subdomain queries from a single source IP
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Possible DNS tunneling or beaconing via high-cardinality A/AAAA subdomain queries from a single source IP
Classification:attackTactic:[TA0010-exfiltration](https://attack.mitre.org/tactics/TA0010)Technique:[T1041-exfiltration-over-c2-channel](https://attack.mitre.org/techniques/T1041) 
## Goal{% #goal %}

Detects a high cardinality of distinct `A`/`AAAA` subdomain queries under a single root domain from one source host, indicating potential DNS-based beaconing or tunneling activity.

## Strategy{% #strategy %}

This rule monitors DNS `A` and `AAAA` lookups, counting distinct `@ocsf.query.hostname` values per `@ocsf.src_endpoint.uid` and per queried root domain within the evaluation window. The root domain is derived into a calculated field, `#domain`, by extracting the last two labels of `@ocsf.query.hostname` (its registrable domain, e.g. `evil.com` from `chunk1.chunk2.tunnel.evil.com`), and grouping occurs on the combination of source host and `#domain` rather than on the source host alone.

DNS-beacon and DNS-tunneling tools such as Cobalt Strike's DNS beacon, `dnscat2`, and `iodine` encode session state or data in subdomain labels that change on nearly every request, all under one attacker-controlled root domain. Using `A` and `AAAA` lookups helps this traffic blend in with normal web activity and makes it less likely to be blocked by egress filtering than `TXT` lookups.

These changing subdomains produce many distinct hostnames concentrated under a single root domain. Counting distinct hostnames per root domain, rather than per source host overall, distinguishes this concentrated pattern from a source host that is simply diverse — such as a shared DNS resolver or egress proxy fielding ordinary lookups across many unrelated domains on behalf of multiple clients. Grouping by source host alone previously allowed that kind of breadth, rather than tunneling, to drive the distinct-hostname count past threshold.

The query excludes the following sources of benign DNS activity to reduce false positives:

- Loopback traffic (`@ocsf.src_endpoint.ip:127.0.0.1`).
- Internal telemetry from managed DNS providers, which is recorded as DNS events but does not represent client queries.
- Internal Kubernetes DNS traffic from node-local DNS caches and `kube-dns`.

## Triage and Response{% #triage-and-response %}

- Identify the source host or resolver associated with `{{@ocsf.src_endpoint.uid}}` and determine if it represents a single endpoint, a shared corporate DNS forwarder, or other multi-user infrastructure.
- Review the root domain, `{{domain}}`, that accumulated the high distinct-hostname count and determine whether it is a known, recently registered, or threat-intelligence-flagged domain.
- Examine the distinct `A`/`AAAA`-queried hostnames under `{{domain}}` from `{{@ocsf.src_endpoint.uid}}` over the alert window and review whether they resemble randomly generated or encoded strings rather than human-readable service names, a common trait of session data encoded into DNS beacon check-ins.
- Determine if any endpoint detection or EDR alerts were generated for the host at `{{@ocsf.src_endpoint.uid}}` around the same time as the DNS spike.
- Review outbound network connections from `{{@ocsf.src_endpoint.uid}}` to assess whether the observed hostnames resolve to infrastructure the host does not otherwise communicate with.
- Compare the observed distinct-hostname count under `{{domain}}` against the host's historical query volume for that same domain to rule out a legitimate high-diversity service such as CDN sharding or SaaS telemetry.