Skip to content

Conversation

antonfirsov
Copy link
Contributor

@antonfirsov antonfirsov commented Feb 18, 2025

When IPv6 is unsupported or disabled, we should avoid passing AF_UNSPEC to the platform calls since those will do AAAA resolve attempts which might result in failures surfacing to the user, see #107979. Instead, we can narrow down the query to AF_INET so failures are avoided.

The change has been validated by packet captures on Windows and Linux. There are no AAAA questions when System.Net.DisableIPv6 is set to true.

Fixes #107979.

@Copilot Copilot AI review requested due to automatic review settings February 18, 2025 01:31
@ghost ghost added the area-System.Net label Feb 18, 2025
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/libraries/System.Net.NameResolution/src/System/Net/Dns.cs:390

  • The new method ValidateAddressFamily should be covered by tests to ensure its correctness.
private static bool ValidateAddressFamily(ref AddressFamily addressFamily, string hostName, bool justAddresses, [NotNullWhen(false)] out object? resultOnFailure)

Copy link
Member

@MihaZupan MihaZupan left a comment

Choose a reason for hiding this comment

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

LGTM

In #107979 (comment) you've mentioned that we filter out such results after the query. Should we be able to remove that logic, or can the OS still return AAAA results for IPv4-only calls?


private static bool ValidateAddressFamily(ref AddressFamily addressFamily, string hostName, bool justAddresses, [NotNullWhen(false)] out object? resultOnFailure)
{
if (!SocketProtocolSupportPal.OSSupportsIPv6)
Copy link
Member

Choose a reason for hiding this comment

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

should this be symmetric e.g. should we apply same logic to IPv4?

Copy link
Contributor Author

@antonfirsov antonfirsov Feb 18, 2025

Choose a reason for hiding this comment

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

Is OSSupportsIPv4 == false a practical real-life user scenario? I would be hesitant to add logic to handle it otherwise. It would be virtually untestable; we don't have a System.Net.DisableIPv4 switch, and I don't think it would make much sense to add one.

@antonfirsov
Copy link
Contributor Author

/azp run runtime-libraries-coreclr outerloop

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@antonfirsov
Copy link
Contributor Author

CI failures are unrelated

@antonfirsov antonfirsov merged commit 509c12b into dotnet:main Feb 24, 2025
82 of 94 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Mar 27, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Disabling IPV6 in .NET Core

3 participants