Replace dns "resolver" calls with "dns.Exchange" func

containers / gvisor-tap-vsock

A new network stack based on gVisor

Apache License 2.0

269 stars 50 forks source link

Replace dns "resolver" calls with "dns.Exchange" func #339

Closed evidolob closed 2 months ago

evidolob commented 8 months ago

This PR is trying to simplify DNS server implementation, by replacing parsing query message and pass it to different resolver.* function calls with single dns.Exchange() function.

The downside of this, is getting DNS configuration on Windows is quite difficult, as it is required syscall.

cfergeau commented 3 months ago

(note for myself) I was wondering about the 'no ipv6/AAAA support' mention in the commit log, it's a preexisting issue, support for AAAA requests is only in the ipv6 PR https://github.com/containers/gvisor-tap-vsock/pull/59/commits/964d1136e8fec5c023cefb18bf73346a2dafaaa8

cfergeau commented 2 months ago

I did a few changes in https://github.com/cfergeau/gvisor-tap-vsock/commits/replace-dns/ , but overall it looks good to me! There is a possibly significant change with this approach though. Before, if I had 1.2.3.4 some.host.example.com in /etc/hosts on my host machine, then the guest would resolve some.host.example.com to 1.2.3.4. After these changes, /etc/hosts will no longer be considered. I tested this on macOS. I don't know if it's going to be problematic or not :-/

Changes I did:

rebased on top of main
merged readAndCreateClient in newDNSHandler as it imo made things more complicated rather than easier to read
made getDNSHostAndPort private
split the test case addition and the addLocalAnswers addition as this simplifies the 'main' commit (the one adding h.dnsClient.Exchange())
fixed the FIXME in handleTCP/handleUDP

cfergeau commented 2 months ago

Before, if I had 1.2.3.4 some.host.example.com in /etc/hosts on my host machine, then the guest would resolve some.host.example.com to 1.2.3.4. After these changes, /etc/hosts will no longer be considered. I tested this on macOS. I don't know if it's going to be problematic or not :-/

CRC relies on the crc.testing and apps-crc.testing entries in the host /etc/hosts file, so I think this is going to cause a problem :-/ Any idea how/if we could address this?

evidolob commented 2 months ago

@cfergeau @gbraad I add 'hosts' file records handling in https://github.com/evidolob/gvisor-tap-vsock/pull/2 Pls, give a look on it

cfergeau commented 2 months ago

@cfergeau @gbraad I add 'hosts' file records handling in evidolob#2 Pls, give a look on it

Looks like a good way forward! Let's merge this PR which has waited for far too long, and then we'll add /etc/hosts support as a follow-up.

cfergeau commented 2 months ago

/lgtm

cfergeau commented 2 months ago

/approve /hold (waiting for the tests to run)

openshift-ci[bot] commented 2 months ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cfergeau, evidolob

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/containers/gvisor-tap-vsock/blob/main/OWNERS)~~ [cfergeau] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

cfergeau commented 2 months ago

win-sshproxy-tests failing is unfortunately expected :-/ /unhold