1. Introduction: When DNS Responses Become an Attack Vector

The Domain Name System (DNS) is essential to internet communication. Applications use DNS to translate domain names into IP addresses, allowing users to access websites, cloud platforms, APIs, and other services.

Most DNS exchanges are routine. A client sends a query to resolve a name, and a DNS resolver returns the corresponding response.

However, DNS can also be abused to generate large volumes of traffic directed at a victim.

In a DNS amplification attack, an attacker sends queries to DNS servers while forging the source IP address to make it appear that the victim requested the information. The DNS servers then send their responses to the victim instead of the actual requester.

If the responses are substantially larger than the queries, the attacker can cause more traffic to reach the victim than was sent directly by the attacking system.

For SOC analysts and network defenders, one useful detection approach is to examine the relationship between DNS queries and responses. Unusual response-to-query ratios, large response sizes, and unexpected traffic direction can provide evidence of possible amplification activity.

The important point is that a high DNS response-to-query ratio is a detection signal, not proof of an attack. Reliable detection requires correlating ratios with packet sizes, resolver behaviour, destination patterns, and the network's normal operating baseline.

2. Understanding DNS Amplification

DNS amplification combines two important concepts: reflection and amplification.

Reflection

Reflection occurs when an attacker sends a request to a third-party system using the victim's IP address as the apparent source.

The third-party system responds to that address, sending traffic to the victim without necessarily communicating directly with the attacker.

DNS servers can become reflectors when they accept a query and return a response to the spoofed source address.

Amplification

Amplification occurs when the response is larger than the request.

DNS responses can contain multiple resource records, DNSSEC-related data, or other information that makes them larger than the original query. The exact size depends on the query, response contents, transport, and configuration.

When an attacker uses many resolvers to generate these responses, the victim can receive a large volume of traffic.

A simplified attack sequence looks like this:

1. The attacker selects DNS servers that will answer the relevant queries.

2. The attacker sends DNS queries with the victim's IP address forged as the source.

3. The DNS servers process the queries and generate responses.

4. The responses are directed to the victim.

5. A sufficiently large traffic volume can consume bandwidth or network-processing resources, disrupting legitimate service.

Not every DNS response is large, and not every DNS server is an open resolver. Amplification depends on the available resolvers, the queries they accept, and the responses they generate.

3. What Are DNS Query-Response Ratios?

A query-response ratio compares the number of DNS queries observed with the number of corresponding DNS responses.

The ratio can be calculated in more than one way. Analysts must define the direction and denominator clearly before interpreting the result.

Response-to-query ratio

A basic count-based ratio is:

[
R_c=\frac{\text{DNS responses}}{\text{DNS queries}}
]

For example, suppose a monitoring point records 10,000 DNS responses and 2,000 DNS queries during a particular interval.

[
R_c=\frac{10{,}000}{2{,}000}=5
]

This means that five responses were observed for every query during that interval.

However, this does not automatically mean that DNS amplification occurred. The queries and responses may belong to different clients, servers, or communication directions. Cached responses, missing telemetry, retries, and sampling can also affect the ratio.

Byte-based amplification ratio

A second metric compares response bytes with query bytes:

[
R_b=\frac{\text{DNS response bytes}}{\text{DNS query bytes}}
]

Suppose a monitoring point records 12 MB of DNS response traffic and 2 MB of DNS query traffic during the same interval.

[
R_b=\frac{12}{2}=6
]

The observed response traffic is six times the query traffic by volume.

This is a traffic-volume ratio, not necessarily the precise amplification factor of an individual request. To estimate per-exchange amplification, investigators need to match requests and responses or otherwise isolate the relevant traffic.

Why both ratios matter

Count-based ratios show whether the number of responses is unusual relative to queries. Byte-based ratios show whether the observed traffic volume is disproportionately large.

A high response count with small responses may have a different impact from a smaller number of very large responses.

For this reason, a useful detection strategy combines response counts, byte volumes, packet sizes, protocol information, and traffic direction.

4. Why Query-Response Ratios Can Reveal Reflection Attacks

Under ordinary conditions, a monitoring point may observe DNS queries travelling towards resolvers and responses travelling back to clients. The expected balance depends on the network's role.

For example, an enterprise resolver may receive queries from thousands of internal endpoints and send responses back to those endpoints. A public DNS server may receive requests from many external clients.

During a reflection attack, a victim may receive DNS responses without having sent the corresponding queries to those resolvers.

This can produce a suspicious pattern:

• Incoming DNS response traffic increases sharply.

• The victim or network segment shows relatively little corresponding outbound query traffic.

• Many DNS servers appear as response sources.

• Response sizes or byte volumes are unusually high.

• The increase coincides with service degradation or a broader DDoS incident.

The key is to examine the traffic from the victim's perspective.

A response-to-query ratio calculated across an entire organisation may be misleading because different hosts generate queries and receive responses. Detection is usually more useful when performed at an appropriate boundary, destination, or flow group.

5. Investigating DNS Amplification Using Network Telemetry

DNS amplification can be investigated through packet captures, firewall logs, NetFlow or IPFIX records, DNS server logs, and DDoS mitigation telemetry.

Each source provides a different level of detail.

Telemetry sourceUseful fieldsInvestigative purposePacket captureDNS flags, query names, packet sizes, source and destination addressesExamines individual exchanges and response characteristicsFirewall logsSource, destination, protocol, port, action, bytesEstablishes how traffic reached or was blocked at the network boundaryNetFlow/IPFIXAddresses, ports, packets, bytes, flow durationIdentifies traffic volume, direction, and major contributorsDNS resolver logsQuery names, clients, response codes, timestampsHelps validate legitimate DNS activity and resolver behaviourDDoS provider telemetryTraffic rates, attack classification, mitigated volumeProvides upstream visibility and mitigation contextAvailability monitoringLatency, packet loss, timeoutsEstablishes the impact on the victim service

Important limitation

NetFlow records may not include DNS transaction IDs, query names, or enough detail to match an individual query to its response. Packet captures or resolver logs may be needed to confirm the relationship.

Similarly, firewall logs may summarise entire sessions rather than individual DNS messages.

Analysts should understand what the monitoring platform actually records before drawing conclusions from a ratio.

6. Step-by-Step SOC Investigation Workflow

Step 1: Confirm the suspected victim

Identify the affected public IP address, network segment, service, and time window.

Establish when the traffic increased and whether users experienced packet loss, connection timeouts, or other availability issues.

Step 2: Identify inbound DNS traffic

Determine whether the victim is receiving unusually high volumes of DNS traffic, commonly over UDP port 53.

Check the direction of the traffic carefully. A DNS server receiving queries is different from a web server receiving large volumes of DNS responses that it did not request.

DNS can also operate over TCP, so do not assume that every relevant exchange uses UDP.

Step 3: Calculate query-response ratios

Where telemetry supports it, calculate both count-based and byte-based ratios over consistent time windows.

For each metric, document:

• The source and destination scope.

• The observation interval.

• The traffic direction.

• Whether the records represent packets, messages, sessions, or flows.

• Any known sampling or logging gaps.

Compare the current measurements with the destination's historical baseline and similar periods of normal operation.

Step 4: Examine source distribution

Identify the source addresses and networks sending responses to the suspected victim.

A broad distribution of DNS servers may be consistent with reflection, particularly when combined with spoofing indicators and unexpected inbound responses.

However, distributed source addresses alone do not prove reflection. Legitimate services can also receive traffic from many DNS servers.

Step 5: Analyse response size and characteristics

If packet-level data is available, inspect DNS message sizes, response flags, query types, response codes, and fragmentation-related observations where relevant.

Large responses can support an amplification hypothesis, but legitimate DNSSEC responses and other valid DNS traffic can also be large.

The strongest evidence comes from combining response size with traffic direction, source distribution, query-response relationships, and incident timing.

Step 6: Correlate with service impact

Review network-interface utilisation, packet loss, firewall resource metrics, and service-availability data.

Determine whether the DNS traffic is consuming enough bandwidth or processing capacity to explain the observed disruption.

If the traffic volume is modest but the service remains unavailable, investigate other possible causes or attack vectors.

Step 7: Determine the confidence level

Classify the finding according to the evidence:

• Confirmed DNS reflection/amplification: Evidence supports spoofed requests and reflected responses, with amplification characteristics established where measurable.

• Likely DNS amplification: Traffic patterns strongly suggest reflection, but packet-level confirmation is unavailable.

• Suspicious DNS traffic: Anomalous DNS response behaviour exists, but alternative explanations remain plausible.

• Benign or unrelated activity: The observed traffic is consistent with expected DNS operations or does not explain the incident.

Document unresolved questions rather than treating every high ratio as a confirmed attack.

7. Practical Example: Identifying an Unusual Response Ratio

Consider an organisation whose public service normally receives very little DNS traffic because it is not itself a DNS server.

During an incident, its network monitoring system reports the following observations over a one-minute interval:

MetricBaselineDuring incidentIncoming DNS response messagesLow85,000Outgoing DNS queries from the targetLow120Incoming DNS response volumeLow420 MBObserved response sourcesLimitedHundreds of addressesService availabilityNormalElevated timeouts

These figures are illustrative, not real incident data.

The combination of a large increase in incoming DNS responses, very little corresponding query activity from the target, a broad source distribution, and degraded service availability warrants investigation for possible DNS reflection.

However, the count ratio should not be treated as a precise amplification factor because the observed responses may not correspond to the queries recorded in the same interval.

The analyst should now examine packet captures, upstream telemetry, and the relevant traffic path to determine whether the pattern is consistent with spoofed requests and reflected responses.

8. Detection Engineering: Building Useful Alerts

A practical DNS amplification detection should use multiple conditions rather than a single ratio threshold.

Potential detection features include:

• A sudden increase in inbound DNS response packets.

• An unusually high byte-based response-to-query ratio at a defined boundary.

• Many response sources directed at one destination.

• Large DNS responses or unusual packet-size distributions.

• Limited evidence of corresponding queries from the destination.

• Concurrent network saturation or service degradation.

Baseline-aware alerting

Thresholds should be tailored to the monitored asset. A recursive DNS resolver, authoritative DNS server, and ordinary web server have different expected traffic patterns.

A resolver normally sends and receives DNS messages. A public web server that does not provide DNS services should have a very different baseline.

Alerts should also account for legitimate DNSSEC activity, resolver architecture, asymmetric routing, missing packets, and monitoring gaps.

Avoiding false positives

A high response-to-query ratio may arise when:

• Queries and responses are observed at different network boundaries.

• The monitoring system misses one direction of traffic.

• DNS responses are cached or generated by a different component.

• DNSSEC or another legitimate use case increases response sizes.

• Flow sampling or log aggregation produces incomplete counts.

• Traffic is routed asymmetrically.

An alert should trigger investigation, not automatically label the event malicious.

9. Mitigation and Defensive Controls

Filter spoofed traffic

Source-address validation at network boundaries can reduce the ability of systems to send packets with forged source addresses.

Ingress and egress filtering, implemented according to established network practices, helps reduce spoofing opportunities. However, a victim cannot always block spoofed traffic effectively using local rules alone.

Work with upstream providers

When a victim's internet connection is saturated, contact the ISP or DDoS mitigation provider.

Upstream filtering or traffic scrubbing may be required to stop unwanted traffic before it consumes the victim's available bandwidth.

Secure DNS resolvers

Organisations operating DNS infrastructure should restrict recursive resolution to authorised clients where appropriate and prevent their systems from becoming open resolvers.

Authoritative DNS services should be configured and monitored according to their intended role and exposure.

Apply rate limits carefully

DNS response-rate limiting can help protect authoritative DNS servers against some forms of abuse. It should be configured with awareness of legitimate client behaviour and service requirements.

Response-rate limiting on a resolver is not a universal defence against traffic reflected from unrelated third-party servers.

Maintain layered DDoS protection

Use suitable network filtering, capacity planning, monitoring, and DDoS protection services. Ensure that security teams can access upstream telemetry when local logs are insufficient.

Preserve evidence

Retain relevant firewall records, flow data, packet captures, timestamps, and mitigation-provider reports according to incident-response procedures.

This information can support root-cause analysis, help validate whether the attack stopped, and improve future detections.

10. Common Analyst Mistakes

Treating a high ratio as proof of amplification. Ratios are only meaningful when the traffic scope and direction are defined.

Mixing unrelated queries and responses. Aggregate counts may compare traffic from different clients or services.

Confusing message counts with bytes. A count-based ratio and a byte-based ratio measure different things.

Ignoring packet size. A large number of small responses may have a different impact from fewer large responses.

Assuming UDP port 53 proves DNS amplification. The traffic must be validated as DNS, and its role in the incident must be established.

Blocking every observed source address. Some addresses may belong to legitimate DNS infrastructure, and source addresses alone may not identify the attacker.

Ignoring upstream saturation. Local filtering cannot recover bandwidth that has already been consumed before traffic reaches the organisation.

11. MITRE ATT&CK Mapping

The following MITRE ATT&CK techniques may be relevant depending on the evidence.

TechniqueIDRelevanceNetwork Denial of ServiceT1498Network traffic overwhelms availability or network capacityDirect Network FloodT1498.001Traffic directly floods the targetReflection AmplificationT1498.002Third-party services reflect amplified traffic towards a victim

Use the reflection-amplification mapping when the evidence supports that behaviour. A DNS traffic surge without evidence of reflection should not automatically be classified as DNS amplification.

Conclusion

DNS amplification demonstrates how a protocol designed for routine name resolution can be abused to generate unwanted traffic against a victim. By sending queries with a spoofed source address, attackers can cause DNS servers to return responses to a target that did not request them.

Query-response ratios provide a useful starting point for identifying suspicious behaviour, but they are not sufficient on their own. Reliable investigation combines count-based and byte-based ratios with traffic direction, response sizes, source distribution, packet-level evidence, and service-health metrics.

For SOC analysts, the objective is to establish whether the observed DNS traffic represents normal operations, a reflection attack, or another network anomaly, then apply mitigation at the point where it can reduce the impact most effectively.

The key lesson: Query-response ratios can expose unusual DNS behaviour, but context and correlation turn that signal into a defensible incident finding.