Fix the issue in Windows kube-proxy when processing unqualified name. This is for DNS client such as ping or iwr that validate name in response and original question.

[JiangtianLi]

What this PR does / why we need it:
This PR is an additional fix to #41618 and the corresponding commit. The DNS client such as nslookup does not validate name matching in response and original question. That works fine when we append DNS suffix to unqualified name in DNS query in Windows kube-proxy. However, for DNS client such as ping or Invoke-WebRequest that validates name in response and original question, the issue arises and the DNS query fails although the received DNS response has no error.

This PR fixes the additional issue by restoring the original question name in DNS response. Further, this PR refactors DNS message routines by using miekg's DNS library.

This PR affects the Windows kube-proxy only.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #42605

Special notes for your reviewer:

Release note:

Fix DNS suffix search list support in Windows kube-proxy.

[k8s-reviewable]

This change is 

[k8s-ci-robot]

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[JiangtianLi]

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

[JiangtianLi]

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

[fejta]

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

[pires]

LGTM but I didn't got a chance to test it manually on a Windows node.

[JiangtianLi]

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.

[thockin]

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?

[thockin]

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

[thockin]

/lgtm
/approve

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

Needs approval from an approver in each of these OWNERS Files:

• pkg/proxy/OWNERS [thockin]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[JiangtianLi]

@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.

[bowei]

@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.

[JiangtianLi]

@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.

[thockin]

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.

[thockin]

@k8s-bot gce etcd3 e2e test this

[JiangtianLi]

@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.

[k8s-github-robot]

Automatic merge from submit-queue