Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robustify a name resolution test #63259

Merged
merged 2 commits into from
Jan 4, 2022
Merged

Conversation

danmoseley
Copy link
Member

These tests get all IP addresses configured for the local machine and arbitrarily try to resolve the first one to a name. On my machine at least, not all these addresses are resolvable. By the comments, it seems this is a configuration issue on some Unix machines as well. Changed the tests to verify that at least one of the addresses are resolved.

On this machine I still have failures in tests that try to resolve ipv6 addresses. This is because GetNameInfoW here is returning HostNotFound for ::1 or similar addresses. ping ::1 and tracert ::1 work fine, so ipv6 is enabled in some sense. There is no relevant entry in hosts. @wfurt any idea why this might be happening? If there was an independent way to verify that a machine is in this configuration, I could use that to make the test skip for such machines.

@ghost
Copy link

ghost commented Jan 1, 2022

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

These tests get all IP addresses configured for the local machine and arbitrarily try to resolve the first one to a name. On my machine at least, not all these addresses are resolvable. By the comments, it seems this is a configuration issue on some Unix machines as well. Changed the tests to verify that at least one of the addresses are resolved.

On this machine I still have failures in tests that try to resolve ipv6 addresses. This is because GetNameInfoW here is returning HostNotFound for ::1 or similar addresses. ping ::1 and tracert ::1 work fine, so ipv6 is enabled in some sense. There is no relevant entry in hosts. @wfurt any idea why this might be happening? If there was an independent way to verify that a machine is in this configuration, I could use that to make the test skip for such machines.

Author: danmoseley
Assignees: -
Labels:

area-System.Net

Milestone: -

@wfurt
Copy link
Member

wfurt commented Jan 3, 2022

I don't know @danmoseley but I know who to ask. Can you share more info about your setup - OS & configuration. (either here os shoot me private message)

@danmoseley
Copy link
Member Author

@wfurt meantime, should we merge this one? It seems from the Unix comments that it's a valid potential configuration for localhost to be mapped to a set of addresses, not all of which can be mapped back. We have the other tests (that we're investigating) to ensure that localhost, 127.0.0.1, ::1 etc can all be mapped (which surely should always happen)

Copy link
Member

@wfurt wfurt left a comment

Choose a reason for hiding this comment

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

LGTM

@danmoseley
Copy link
Member Author

failure already linked.

@danmoseley danmoseley merged commit f686f65 into dotnet:main Jan 4, 2022
@danmoseley danmoseley deleted the net.tests branch January 4, 2022 01:05
@danmoseley
Copy link
Member Author

danmoseley commented Jan 7, 2022

Curiously the name resolution tests mentioned above all seem to pass now. It looks like some update was pushed to the VPN configuration.

Summarizing what we learned: the name resolution tests failed for "::1" and equivalent due to GetNameInfoW returning host not found. DNS team found this was due to a NRPT policy applied to the machine for "ip6.arpa". This could be seen with get-dnsclientnrptpolicy -Namespace .ip6.arpa. This appeared to be applied as part of setting up the Microsoft employee VPN.

I was going to set the tests to skip if this key existed: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DnsPolicyConfig\<varies>@Name= .ip6.arpa. But mysteriously the policy seems to be gone now and indeed they're passing.

@karelz karelz added this to the 7.0.0 milestone Jan 11, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Feb 25, 2022
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.

3 participants