This change is 

Hi @JiangtianLi. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with @k8s-bot ok to test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

This PR addresses the comment in #44872 since I closed #44872 due to my bad rebase.

One side note, with rebasing the latest master, building Windows kube-proxy is broken due to #45554.

Thanks for the fix!

Networking team: kubernetes is broken on windows, and our cross-build suite is failing. Will someone from sig-networking review?

@k8s-bot ok to test
@kubernetes/sig-network-pr-reviews

/assign @bowei @thockin @dcbw
/unassign @lavalamp

Thanks all for the review. The change has been patched in my private branch for 1.6.0 and 1.6.2. Once cross-build issue is fixed, we can verify with the latest build.

I have NO IDEA what this code is doing - no other proxy mode has anything DNS related - can you explain what is happening here? Did you build a DNS server into kube-proxy?

I'm going to approve this to unblock, but I'd like to discuss what the heck is going on here.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JiangtianLi, thockin

@thockin Sorry, I should have more context here. This PR is an additional fix to #41618 and the corresponding commit. There is no new DNS server built into kube-proxy.

The issue this PR and #41618 is trying to fix is that DNS suffix search list doesn't work in Windows container (--dns-search option from this link). Therefore lookup unqualified name such as kubernetes or any other unqualified service name doesn't work in Windows container. The users have to specify or change to full qualified name in their apps in Windows container to reach service endpoint.

To overcome that and until Windows releases container that fix DNS suffix search list issue, we have come up with a solution to fix in Windows kube-proxy. The idea is to have kubeproxy do what DNS client would do to search DNS suffix search list and append it to query, i.e., intercept DNS packet and append a list of common DNS suffix ("cluster.local", "svc.cluster.local", "default.svc.cluster.local", and host DNS suffix) to the name in DNS query. This has worked pretty well for most Windows user scenarios.

Hope that clarifies a bit. Please let me know if you have any question.

@JiangtianLi does that code belong in kube-proxy? It seems like something that could be a separate Windows only module that implements the *nix style resolv.conf behavior.

@bowei Thanks for the suggestion. Yes, that code belongs to kube-proxy. The code is in the winuserspace part of the kube-proxy. So it is in Windows kube-proxy and separated from the *nix kube-proxy.

Yeah, I find this exceptionally weird, but I am willing to grant latitude since it seems a) temporary and b) contained. Before long we need to really decide if it is worthwhile for the Window kube-proxy to actually be part of kube-proxy, or a separate thing.

@k8s-bot gce etcd3 e2e test this

@thockin Agreed that this fix is a workaround to get Windows scenario work. Windows's kube-proxy forked from kube-proxy and implemented a few Windows specific features. sig-windows folks should have more context. Thanks for the approval. I felt this fix should be with its precedent commit in the upstream rather than in my private branch separately.

Automatic merge from submit-queue