Repository navigation
System.Net.NameResolution.Tests DNS failures: Name or service not known #126641
Description
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1368622
Build error leg or test failing: System.Net.NameResolution.Tests.GetHostByNameTest.DnsObsoleteBeginEndGetHostByName_EmptyString_ReturnsHostName
Pull request: #125647
Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorMessage": "",
"ErrorPattern": "System\\.Net\\.Sockets\\.SocketException : Name or service not known|System\\.Exception : Failed for empty hostname",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1368622
Error message validated: [System\.Net\.Sockets\.SocketException : Name or service not known|System\.Exception : Failed for empty hostname]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 4/8/2026 12:37:43 PM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 4 |
Activity
dotnet-policy-service commentedon Apr 8, 2026
Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.
MihuBot commentedon Apr 8, 2026
I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):
wfurt commentedon Apr 8, 2026
It seems like the machines cannot resolve own name.
mangod9 commentedon Apr 8, 2026
diag analysis:
kg commentedon Apr 9, 2026
Summary:
DNS resolution fails with SocketException on Helix machines where hostname is not in /etc/hosts.
Failed in (3):
runtime-coreclr libraries-jitstress 20260409.1
runtime-coreclr libraries-jitstressregs 20260408.1
runtime-coreclr libraries-pgo 20260408.1
Console Log: Console Log
Source: runtime-coreclr libraries-jitstress / net11.0-linux-Release-x64-no_tiered_compilation-AzureLinux.3.Amd64.Open / System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok
Failed tests:
Error Message:
Stack Trace:
Analysis:
These are DNS resolution failures where Dns.GetHostEntry("") fails with "Name or service not known" on Helix Linux machines. The test machines hostnames are not resolvable via DNS or /etc/hosts. This is a Helix infrastructure issue, not JIT/stress related. Tracked by #126641.
JulieLeeMSFT commentedon Apr 10, 2026
Summary:
DNS resolution failures in Helix test machines. Tests fail because hostname cannot be resolved via DNS. Known infrastructure issue affecting jitstress, jitstressregs, and pgo pipelines.
Failed in (3):
runtime-coreclr libraries-jitstress 20260410.1
runtime-coreclr libraries-jitstressregs 20260408.1
runtime-coreclr libraries-pgo 20260408.1
Console Log: Console Log
Source: runtime-coreclr libraries-jitstress / net11.0-linux-Release-x64-no_tiered_compilation-AzureLinux.3.Amd64.Open / System.Net.NameResolution.Tests.GetHostEntryTest.Dns_GetHostEntry_HostString_Ok
Failed tests:
Error Message:
Stack Trace:
Analysis:
Infrastructure issue with DNS resolution on Helix machines. Not a product bug. Known from prior runs.
Generated by ci-pipeline-monitor/scripts/generate_report.py
danmoseley commentedon Apr 11, 2026
Note
This comment was drafted with Copilot assistance.
Some additional findings from investigating
dotnet-helix-machines:Tests run directly on the VM, not in Docker. The Helix logs show hostname
a00BVKN(noDprefix — Docker containers prependDto the VM hostname viadockerhelper.py). The VM's/etc/hostsonly haslocalhostentries — the hostname is completely absent. Multiple machines are affected (a00BOMC,a00C1G0,a00C13G,a00BVKN), so this is fleet-wide.An artifact to fix exactly this already exists —
linux-add-localhost-to-hosts(created in PR 13243 for "self-resolution issues"). It adds127.0.0.1\t$(hostname)to/etc/hosts. However, it is not applied to any AzureLinux 3 queue indefinitions/shared/linux.yaml.Timeline correlates with AutoScalerACA deployment:
AutoScalerSystem: AutoScalerACAadded toAzureLinux.3.Amd64.Open.Rt(PR 59010)AzureLinux.3.Amd64.Openand.Open.Svc(PR 59711)The likely mechanism: old VMs (provisioned under AutoScalerSF) had hostname DNS resolution working through Azure infrastructure. When AutoScalerACA took over and cycled the VMSS (scale down/up over the weekend gap), newly provisioned VMs lost that resolution — possibly due to differences in VNET config, custom extension ordering, or Azure DNS behavior for the new VMSS.
wfurt has an in-progress fix on branch
wfurt/systemd(commit 41a553fa) — adds alinux-enable-systemd-resolverartifact that enablessystemd-resolvedand points/etc/resolv.confat its stub resolver. This is a more comprehensive DNS fix than just patching/etc/hosts.A simpler alternative would be to add the existing
linux-add-localhost-to-hostsartifact to the AzureLinux 3 artifact list — that would fix hostname self-resolution specifically without changing the broader DNS setup.VincentBu commentedon Apr 13, 2026
Failed in: runtime-coreclr libraries-jitstress2-jitstressregs 20260411.1
Failed tests:
Error message:
Stack trace:
EgorBo commentedon Apr 14, 2026
Is this something being worked on? it seems to have a wide-spread impact on all PRs.
wfurt commentedon Apr 14, 2026
yes. it will be fixed on Helix side but I don't have ETA yet.
VincentBu commentedon Apr 20, 2026
Failed in: runtime-coreclr libraries-jitstress2-jitstressregs 20260418.1
Failed tests:
Error message:
Stack trace:
wfurt commentedon Aug 4, 2026
no recent failures. This looks like infra problem where the OS fails to resolve names.