DnsResolver Windows 10/Server 2019 memory leak

[MichalPetryka]

so I was kinda curious how you'll solve this.

Currently it's best-effort. As the article you linked in one of your previous comments said, there is no good way to predict if the query will complete synchronously, so we instead detect the condition ex-post and take the memory leak. We will also practively avoid async path for names we are sure will be resolved synchronously (currently "localhost" only, but we can add more in the future) to mittigate the most common case that would otherwise leak.

I plan to follow-up with the Windows team to see if there a more specific criteria we can use for that.

Originally posted by @rzikm in #129845 (comment)

[MichalPetryka]

Opened for tracking.

[dotnet-policy-service]

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

[MichalPetryka]

@rzikm From my local testing, it seems that doing a sync request first with DNS_QUERY_NO_WIRE_QUERY seems like a possible solution, it returns an error for entries not in cache and succeeds for those needing sync parsing.

[rzikm]

Per conversation with the OS team:

There are only a few types of query names that fall into the inline completion path, namely:

• IP string literals
• The machine's hostname
• Special names "loopback", "localhost", "..DnsServers", and "..localmachine"

Otherwise, other query names sent async should be completed in the normal callback process.

It shouldn't be hard to augment the existing logic to trip for those

[rzikm]

@rzikm From my local testing, it seems that doing a sync request first with DNS_QUERY_NO_WIRE_QUERY seems like a possible solution, it returns an error for entries not in cache and succeeds for those needing sync parsing.

I don't like adding a perf hit of always doing DNS_QUERY_NO_WIRE_QUERY first I would consider it a last resort if the above is not sufficient.