cws: add DNS response IPs and CNAMEs to activity dumps

[homoeconomics]

What does this PR do?

Adds a DNSResponseInfo message to the CWS activity-dump v1 schema, carrying the DNS response code, the resolved IP addresses, and the CNAME targets. It is nested on DNSInfo as field 6, so the answers stay attached to the question that produced them.

message DNSInfo {
    string name = 1;
    uint32 type = 2;
    uint32 class = 3;
    uint32 size = 4;
    uint32 count = 5;

    DNSResponseInfo response = 6;   // new
}

message DNSResponseInfo {           // new
    uint32 response_code = 1;
    repeated string ips = 2;
    repeated string cnames = 3;
}

Motivation

CWS-6595.

Activity dumps and workload profiles record which domains a workload queried, but not what those queries resolved to. That leaves the DNS section of a profile impossible to correlate with the bind / connect / flow nodes sitting in the same tree.

The agent already has this data and throws it away: the probe decodes the full DNS response, extracts the IPs and CNAMEs, and hands the event to the activity tree, which drops the answers because the wire format has nowhere to put them. This PR is the schema half of the fix; the agent-side change follows once this is tagged.

Additional Notes

Why nested per question rather than flat lists on DNSNode. DNS answers are per question type — A returns IPv4, AAAA returns IPv6 — and DNSNode.Requests is already a per-qtype list. Pooling ips / cnames onto DNSNode would have been a smaller wire format but would lose which question produced which answer, and give the response code nowhere sensible to live.

Why string for IPs. Matches the existing convention in this file (BindNode.ip, IPPortContext.ip) and the agent's existing utils.GetIPStringFromIPNet helper used by the event serializer.

Regeneration. Only the CWS Activity Dumps v1 target was regenerated (activity_dump.pb.go, activity_dump_vtproto.pb.go, and the Java bindings). Running the full codegen.protoc task would have churned every unrelated payload in the repo. The generated diff is larger than the schema change because inserting a message renumbers the downstream msgTypes indices; there is no generator-version drift.

Possible Drawbacks / Trade-offs

Compatibility — purely additive, per the checklist in REVIEWING.md:

• Old sender → new receiver: fine, response is simply absent and decodes to nil.
• New sender → old receiver: fine, field 6 lands in unknownFields and is ignored.
• No field IDs are removed, so nothing needs reserved.

Payload size — dumps grow for workloads that do DNS. The agent side bounds this: answers accumulate as a set capped at 32 IPs and 8 CNAMEs per question, and profiles remain subject to the existing security_profile.v2.max_dump_size cap.

Describe how to test/QA your changes

go build ./cws/... plus a marshal → unmarshal round trip over SecDump. I verified locally that:

• resolved IPs (v4 and v6) and CNAMEs survive MarshalVT / UnmarshalVT;
• a DNSInfo with no answers decodes back to a nil response rather than an empty struct;
• the vtproto and standard proto.Marshal paths agree (proto.Equal);
• the ReturnToVTPool reset path is clean, since Profile.EncodeJSON relies on it.

Functional coverage lives in the consuming datadog-agent PR, which adds unit tests for the merge and encode/decode paths and an activity-dump functional test asserting resolved IPs reach a real dump.

Reviewer's Checklist

Reviewers: please see the review guidelines.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9e187debf5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve every observed DNS response code

When one aggregated question returns different outcomes over time—for example, NXDOMAIN first and NOERROR with an IP later—this scalar can retain only one response code, even though the surrounding message explicitly unions answers across every observed response. Whichever code the producer retains or overwrites, the dump loses the other outcome and can misleadingly associate the unioned IPs/CNAMEs with a single status; represent observed codes as a set or per-code counts instead.

Useful? React with 👍 / 👎.

[homoeconomics]

Good catch, fixed in db9b40a — response_code is now repeated uint32 response_codes.

You identified a real inconsistency: I was unioning ips and cnames across every response for a question but keeping status as a scalar. The damaging ordering is NOERROR-then-NXDOMAIN, where last-write-wins leaves a record claiming the domain doesn't exist while still listing the addresses it resolved to. All three fields are now unions with the same semantics, so both outcomes survive in either order.

Regression test on the agent side asserts exactly that, in both orderings:

root.insert(dnsResponse("flap.example.com", A, NOERROR, []net.IPNet{ip("1.2.3.4")}))
root.insert(dnsResponse("flap.example.com", A, NXDOMAIN, nil))
// ResponseCodes == {NOERROR, NXDOMAIN}, IPs still {1.2.3.4}

I verified it isn't vacuous by reverting to the scalar behaviour — three subtests fail.

On the other half of the suggestion: I did not add per-code counts, deliberately. DNS samples are rate limited in the kernel before user space sees them, so a count here would report how many samples happened to survive the limiter, not how often the workload actually observed that outcome — misleading in a way the bare set is not. It would also cut against the surrounding design, which discards frequency at the kernel boundary on purpose (the activity tree records which targets a workload touched, not how many times). Codes are capped at 8 per question as a backstop; RFC 6895 leaves few enough that real traffic won't approach it.

One thing worth flagging for human reviewers: per-response fidelity is still not preserved, and that's intentional. You can see that a question returned both NOERROR and NXDOMAIN, but not which response produced which IP. Keeping that would mean storing a list of individual responses, which defeats the aggregation this message exists for and would grow without bound for CDN-backed domains.

[homoeconomics]

Superseded: a reviewer asked for response codes to be dropped entirely, so DNSResponseInfo is now just ips and cnames (3b39e70). With no status field left there is nothing to contradict the unioned answers, so this is resolved by removal rather than by the union I'd added.

[homoeconomics]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-09-03 13:53:13 UTC ℹ️ Start processing command /merge

---

2026-09-03 13:53:20 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 3m (p90).

---

2026-09-03 13:55:46 UTC ℹ️ MergeQueue: This merge request was merged