Investigating DNS Retry Noise and Unexplained Traffic
Once an analyst has traced a noisy network pattern to a plausible configuration problem, it is tempting to treat the source as understood. The difficult question is how far that explanation reaches. A repeated DNS lookup can explain a large volume of traffic while leaving another exchange from the same source unresolved.
We investigated that boundary in retained DeepNora network evidence. Six source addresses repeatedly queried one application name along three observed resolver paths. Two paths carried DNS answers; the third had no recorded response. Alongside them, the same sources produced a separate group of UDP/53 records to the address returned in those answers. Those records had partial connection analysis and no confirmed application protocol. Calling the entire population a DNS retry loop would merge materially different evidence.
A plausible misconfiguration explanation should cover a defined set of observations, while the remaining traffic keeps its own investigation path. DeepNora’s searchable protocol and connection history lets an analyst make that separation, inspect the original records and identify the device or path evidence still needed.
Start with the population the explanation must cover
We began with a fixed one-hour discovery window, 12:00–13:00 UTC on 4 November 2026, across the available DNS observations. A particularly frequent application name appeared on three paths from six leading source addresses at one sensor. We selected those six sources for detailed analysis, then examined that name over the complete UTC day. This is a deliberately selected high-volume example, not a random sample or an estimate of how often misconfiguration occurs.
Across all ten sources seen querying that name at the selected sensor, the day contained 3,060,858 retained DNS records. Of these, 2,040,183 had NOERROR and 1,020,675 had no retained response-code name. The six-source subset accounted for 3,054,677 records. We use cloud-control.example, Source A–F and Resolver A–C as consistent aliases; counts and measured relative timestamps are preserved.
Actual Hunt result for the selected name, sensor and full UTC day, cropped to omit identifiers. The dash is a missing response-code value, not a successful response or an NXDOMAIN result. This aggregate covers all ten observed sources; the investigation below narrows to six.
That distinction matters at ingestion as well as on screen. A numeric response-code field that defaults to zero cannot, by itself, establish an observed NOERROR reply. We checked the retained response-code name, answer content and related connection evidence. Nor does NOERROR invariably mean a useful address was returned: a NODATA response can contain no records of the requested type. In this case, the answered records contained the same address.
For the selected six sources, the two internal resolver paths supplied 2,037,076 NOERROR records over the day. Resolver C supplied 1,017,549 records without a response-code name, and another 52 such records occurred on A or B. The dominant pattern was therefore repeated queries with answers on two paths, alongside a third path without observed answers. DNS failure everywhere is already an inadequate explanation.
Separate DNS transactions from everything using port 53
The next step was to return to the original noon hour and retrieve connection records for the same sensor and six source addresses. Restricting this comparison to UDP destination port 53 produced the following population.
Observed destination: Resolver A
Connection records: 42,667
Confirmed service: DNS
Connection evidence: SF; responder packets observed
Observed destination: Resolver B
Connection records: 42,667
Confirmed service: DNS
Connection evidence: SF; responder packets observed
Observed destination: Resolver C
Connection records: 42,668
Confirmed service: DNS
Connection evidence: S0; no responder packets recorded
Observed destination: Address returned in DNS answers
Connection records: 21,295
Confirmed service: Unconfirmed
Connection evidence: S0, history DX; partial analysis
Observed destination: Total
Connection records: 149,297
Confirmed service: 128,002 DNS; 21,295 unconfirmed
Connection evidence: One sensor, six source addresses, one hour
Connection-record counts for 12:00–13:00 UTC on 4 November. The two answered resolver paths are combined in the first bar; the table preserves each path. All bars use the same zero-based scale. The third group is unresolved, not a measured malicious population.
In Zeek’s connection model, UDP uses flow semantics rather than a TCP handshake. S0 says no reply was seen; it does not encode a firewall decision. The service field records a confirmed protocol, while X in the history marks partial connection analysis. An empty service field with that history cannot establish either “ordinary DNS” or “definitely not DNS.” It identifies an observation that needs more evidence. Zeek connection field reference.
The DNS table contained 128,122 records for the same six sources in the hour, compared with 128,002 DNS-classified connection records. These are different units. A UDP flow can contain more than one transaction, and connection-start and protocol-event windows need not have identical boundaries. Adding those counts together would double-count evidence; treating their difference as missing traffic would also be unjustified.
Reconstruct the repeated exchange before naming its cause
To examine the mechanism, we retrieved the first ten minutes for Source A: 3,614 DNS records and 4,217 connection records. For every DNS record, exactly one connection candidate matched the sensor, retained connection reference, complete endpoint tuple and bounded event-time interval. We independently repeated that join in SQLite. A connection reference alone was insufficient: a compact identifier or reused network tuple must remain inside its producer and time scope.
Grouping the DNS records by source port, transaction ID and query name, then requiring three distinct resolver destinations within one second, produced 1,204 complete three-path groups. Two additional DNS records were singletons under that rule. The median separation between the first and last record in a complete group was 0.089 milliseconds. That is evidence of closely related observations, not 1,204 proven application calls: the client implementation, translation and mirror topology were not independently established.
Relative start: 0.000 ms
Destination: Resolver A
Observation: A query for cloud-control.example; NOERROR, address returned; RTT 0.406 ms
Relative start: 0.005 ms
Destination: Resolver C
Observation: Same name, source port and transaction ID; no response code retained
Relative start: 0.009 ms
Destination: Resolver B
Observation: Same name, source port and transaction ID; NOERROR, same address; RTT 0.524 ms
Relative start: 3.301 ms
Destination: Returned address, UDP/53
Observation: Separate connection; S0, DX, unconfirmed service
A selected record sequence beginning at 12:00:01.743509 UTC. Reply positions use each DNS record’s start plus retained RTT. A second three-path DNS group begins between these observations and the partial connection; it is shown in the figure. Temporal proximity and the returned address make the connection relevant, but do not identify the initiating process or establish causation.
The full ten-minute join associated 2,408 NOERROR records with SF connections and 1,206 missing-response-code records with S0 connections. This supports a precise statement: answers were observed on two paths while repeated activity continued. It does not establish that the application accepted the answers, successfully contacted its service, or was configured correctly.
Get Ishak’s stories in your inbox
Join Medium for free to get updates from this writer.
Retry amplification is an established operational problem. RFC 9520 documents aggressive requerying during resolution failures and requires caching of those failures. Its explanation cannot simply be imported into this case: the trace contains successful address answers as well as silence. Repeated application discovery, multiple configured resolvers, a downstream service failure or the observation topology remain competing explanations. The next useful evidence is the device’s resolver and application configuration, service logs and time-matched gateway decisions.
Keep the partially analyzed traffic outside the explanation
The separate 21,295-record group matters because a broad rule such as “this source is a noisy DNS appliance” would absorb it. The destination matched the address retained in the DNS answers, but the connection records did not confirm an application protocol. Every selected record had partial-analysis history and no responder packets. They recorded 21,305 originator packets and 1,235,690 IP-level bytes in total.
Those byte totals are observations at the sensor, not application data recovered at the destination. They include IP-level overhead. A zero or missing application-byte value must not erase the packet observation, and a zero missed-byte counter does not repair the explicit partial-analysis marker. In this storage representation, most records in the group also lacked a usable retained connection reference, so they must not be attached to a DNS transaction through an invented identifier.
Several benign explanations remain plausible. A service can use an unconventional port; a device can be trying a stale or inappropriate discovery path; sensor analysis can be incomplete. None is established merely by frequency or by the destination also appearing in a DNS answer. The actionable result is an unresolved service exchange with precise source, destination, port and time boundaries. Request a bounded authorized packet view or device-side service evidence for that group, rather than closing it under the DNS explanation.
That is also where a security investigation can coexist with configuration repair. Fixing the recurring resolver or application problem may reduce noise substantially. It does not retrospectively classify everything else from the device. Compare the exact repeated family before and after the authorized repair, and continue examining any separate population that remains.
Test why an unanswered query is still a security-relevant observation
The operational records do not prove that an external receiver obtained the unanswered traffic. We tested the narrower protocol question separately: can a DNS request reach a receiver even when the sender receives no useful answer?
A local UDP server received harmless DNS A requests in three conditions, with 16 requests per condition repeated three times. One condition repeatedly used a fixed name and received no reply. Another used distinct, readable record markers in names and received no reply. The third used distinct markers and received an NXDOMAIN response. All communication stayed on loopback; server receipts recorded the actual received bytes.
Condition: Fixed name, silent receiver
Requests sent: 48
Received at server: 48
Replies received by client: 0
Offline connection replay: 48 S0
Condition: Readable marker names, silent receiver
Requests sent: 48
Received at server: 48
Replies received by client: 0
Offline connection replay: 48 S0
Condition: Readable marker names, negative reply
Requests sent: 48
Received at server: 48
Replies received by client: 48 NXDOMAIN
Offline connection replay: 48 SF
Actual endpoint receipt counts, pooled across three repetitions. Negative or absent replies do not undo delivery of the request. The experiment demonstrates that logical distinction; it does not measure an external path, recursive resolver, covert-channel capacity or production detection effectiveness.
We independently decoded all 144 request messages and compared them byte for byte with the receiver receipts. The unchanged DNS messages were then placed in authored Ethernet/IP/UDP envelopes for offline analysis: Zeek 9.0.0 produced 96 S0 and 48 SF records; TShark 4.6.9 decoded all 192 request/response frames and validated their UDP checksums. Addresses, ports and spacing in that replay were constructed, not captured network timing. The endpoint delivery result comes from the executed socket exchange.
The adversarial relevance is established independently of our example. MITRE ATT&CK’s DNS technique describes communication embedded in DNS. Mandiant’s SUNBURST analysis documents encoded victim information in DNS names, response-dependent behavior and traffic intended to resemble legitimate software activity. Those reports explain why a familiar operational appearance is insufficient; they are not evidence of SUNBURST, tunneling or compromise in our observed population.
A new name or destination is a reason to reopen a question, not a malicious verdict. Equally, an adversary need not produce a high-volume or high-entropy outlier. When approved and unauthorized activity produce the same retained network evidence, a network-only rule cannot recover the missing intent. Process provenance, device configuration, account context or receiver-side evidence must resolve that ambiguity.
Turn the explanation into a reproducible Hunt investigation
DeepNora’s role here is concrete: retain the connection and protocol evidence, group it by the question being asked, and let the analyst return to the records behind the count. The actual Hunt result above was checked against the separate read-only aggregate. Its record drill-down, table/chart/pivot views and evidence-notebook action provide the investigation surface. The scoped explanation below is an analyst method, not a claim that a new automatic classifier has been deployed.
- Freeze the scope. Set an explicit time interval and sensor. In DNS, group by source, query, query type, destination and response code. Inspect answer content; preserve missing values. Keep multicast discovery and other transports separate when they are outside the question.
- Open the records behind the repeated family. Inspect representative answered and unanswered observations. Compare transaction identifiers, ports and timestamps before interpreting several paths as separate application attempts. Follow available connection references inside their sensor, tuple and time scope.
- Return to connection history for the same sources. Compare confirmed service, state, history and both packet directions. Include traffic that has no DNS child record or no confirmed service. A DNS-only result cannot show the whole port-53 population.
- Resolve device ownership at event time. The source labels in this investigation denote addresses at one sensor. Before assigning responsibility to an asset or person, corroborate the historical address binding and account for shared devices, translation and mirrored paths. A current inventory name does not establish the earlier owner.
- Preserve two follow-ups. Give the service owner the exact repeated family and evidence needed to test the configuration explanation. Keep the partial-analysis group separately visible with its own record locators and next evidence request. Save the scope and observations in the evidence notebook so another analyst can reproduce both paths.
Proposed explanation: Repeated application discovery or retry activity
What currently supports it: Stable name; closely grouped resolver paths; repeated answers to the same address
What requires a fresh decision: Device configuration, initiating service and reason for continued retries
Proposed explanation: Resolver C is unavailable on the observed path
What currently supports it: DNS-classified S0 records and no recorded replies
What requires a fresh decision: Gateway enforcement and return-path evidence; no inferred “blocked” verdict
Proposed explanation: Other UDP/53 activity belongs to that same application
What currently supports it: Same source population; destination matches the observed answer
What requires a fresh decision: Partial protocol analysis and absent process linkage leave this unconfirmed
Proposed explanation: The source can be treated as benign
What currently supports it: No source-wide evidence establishes this
What requires a fresh decision: Any new activity needs its own context; even an unchanged pattern may require endpoint evidence
A useful handoff would read: “The selected sources repeatedly queried one name on three observed paths. Answers were retained on two paths; the third showed no response. A separate partial-analysis group contacted the returned address over UDP/53. Verify the device’s discovery configuration and resolver path, while obtaining service evidence for the separate group.” It gives the operator something to fix and the investigator something precise to pursue.
Noise reduction is valuable when it makes the remaining evidence easier to see. The test is whether the explanation stays attached to the records it actually supports. Searchable history makes that boundary reviewable; a source-wide trust label removes it.
Measurement scope and checks
Operational data was read on 5 November 2026. Windows are half-open UTC intervals: the full day of 4 November, the noon hour for the six-source comparison, and 12:00–12:10 for Source A’s detailed reconstruction. The full-name day and six-source subset have separate denominators. Selected aggregate counts equalled distinct retained event identifiers; raw ten-minute identifiers were unique within each dataset. This checks duplicate retained records in those selections, not independent physical observations across sensors.
Hourly aggregates reconciled with a separately grouped day query. The detailed DNS-to-connection join required the sensor, both addresses and ports, transport, a nonempty retained reference and a compatible start/duration interval; all 3,614 DNS rows had one candidate. Python and SQLite agreed. Three-path grouping additionally required the same name, source port and DNS transaction ID, three resolver destinations and less than one second between record starts. That grouping is descriptive and does not establish application identity or causation.
Private queries, results, calculation code and experiment inputs were retained with hashes. Public figures preserve counts and relative timing while replacing operational identifiers. No endpoint configuration, gateway decision, remote receipt or confirmed malicious execution was available for the operational example. The separate loopback experiment answers only the request-delivery question. Neither population supplies a false-positive rate, a universal tuning threshold or proof that the partial traffic was hostile.
Related investigations: DNS tunneling and ordinary query churn, connection-state evidence, scoped flow correlation and historical address ownership.
