Skip to content

[NO-TICKET] Profiling: Use system dns resolver by default#5449

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 2 commits into
masterfrom
ivoanjo/system-dns-default
Mar 16, 2026
Merged

[NO-TICKET] Profiling: Use system dns resolver by default#5449
gh-worker-dd-mergequeue-cf854d[bot] merged 2 commits into
masterfrom
ivoanjo/system-dns-default

Conversation

@ivoanjo

@ivoanjo ivoanjo commented Mar 13, 2026

Copy link
Copy Markdown
Member

What does this PR do?

This PR changes the default for the experimental_use_system_dns profiler setting from false to true.

The setting is now true by default, meaning that the system DNS resolver is used instead of libdatadog's built-in resolver.

Motivation:

We discovered an inconsistency between how the libdatadog resolver resolves localhost with IPv4 vs IPv6.

Change log entry

Yes. Profiling: Use system dns resolver by default

Additional Notes:

N/A

How to test the change?

This change includes test coverage.

**What does this PR do?**

This PR changes the default for the `experimental_use_system_dns`
profiler setting from `false` to `true`.

The setting is now `true` by default, meaning that the system DNS
resolver is used instead of libdatadog's built-in resolver.

**Motivation:**

We discovered an inconsistency between how the libdatadog resolver
resolves `localhost` with IPv4 vs IPv6.

**Additional Notes:**

N/A

**How to test the change?**

This change includes test coverage.
@ivoanjo
ivoanjo requested a review from a team as a code owner March 13, 2026 17:25
@github-actions github-actions Bot added the core Involves Datadog core libraries label Mar 13, 2026
@ivoanjo
ivoanjo requested a review from danielsn March 13, 2026 17:25
@ivoanjo

ivoanjo commented Mar 13, 2026

Copy link
Copy Markdown
Member Author

Based on @gleocadie's report:

in our test infra, we have mock agent. We use TcpListener to listen (obviously 😅 ) to some prefixes (http://127.0.0.1/: and http://localhost/:).
Currently validating that the non-system resolver, resolves localhost to [::1] instead of > 127.0.0.1. Since my listener does not have [::1] as prefix 💥 404
When using the system resolver, everything is fine

@pr-commenter

pr-commenter Bot commented Mar 13, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-03-16 14:39:14

Comparing candidate commit 8d1a855 in PR branch ivoanjo/system-dns-default with baseline commit c5d8dee in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 46 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

@Strech

Strech commented Mar 16, 2026

Copy link
Copy Markdown
Member

Didn't find any configuration use anywhere, so I guess it's not a breaking change?

@Strech Strech left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤞🏼

@gh-worker-ownership-write-b05516
gh-worker-ownership-write-b05516 Bot removed the request for review from danielsn March 16, 2026 13:15
@ivoanjo

ivoanjo commented Mar 16, 2026

Copy link
Copy Markdown
Member Author

Yes, my bad, I forgot one of the most important details -- linking to #5425 which was the PR that added this. That PR is recent, so it never made it to any dd-trace-rb release.

…onfig

Version A used the default as `false` so we needed to create a new one.
@ivoanjo

ivoanjo commented Mar 16, 2026

Copy link
Copy Markdown
Member Author

/merge

@gh-worker-devflow-routing-ef8351

gh-worker-devflow-routing-ef8351 Bot commented Mar 16, 2026

Copy link
Copy Markdown

View all feedbacks in Devflow UI.

2026-03-16 14:03:54 UTC ℹ️ Start processing command /merge


2026-03-16 14:04:02 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.


2026-03-16 14:41:14 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in master is approximately 0s (p90).


2026-03-16 15:16:42 UTC ℹ️ MergeQueue: This merge request was merged

@datadog-prod-us1-3

datadog-prod-us1-3 Bot commented Mar 16, 2026

Copy link
Copy Markdown

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8d1a855 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Involves Datadog core libraries mergequeue-status: done

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants