What is the suggested way for a Transparent Proxy resolve hostnames

I just ran a few local tests for NETransparentProxyProvider and did see the same results for Safari based flows.

Code Block 
2020-10-28 06:30:50.943096-0700 0x1ceb0f   new flow with bundle id com.apple.Safari
2020-10-28 06:30:50.943149-0700 0x1ceb0f   ### (TCP) ### provider will handle new NEAppProxyTCPFlow, flow: 0x7fee16805f90 - TCP com.apple.Safari[{length = 20, bytes = ***}] remote: www.apple.com:80

There were a few bug fixes that went into NETransparentProxyProvider and how it handles addresses and remote endpoints now. One of these fixes is now visible in Beta 10 if you use an NENetworkRule that looks like:

Code Block swift
NENetworkRule(remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .outbound)

or

Code Block swift
NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"),
                          remotePrefix: 0,
                          localNetwork: nil,
                          localPrefix: 0,
                          protocol:.TCP,
                          direction: .outbound)

In some cases these results were not consistent prior to Big Sur Beta 10 and that may be what you are seeing.

What is the best way to resolve the hostnames to IP addresses within the handleNewFlow override that would insure that the default resolver and any configured DSN proxies are used?

Why are you in need to proxy flows by IP instead of by hostname or IP?


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Our network extension needs to make some decisions about blocking or proceeding with the connection based on the final IP address.

Okay, well if you are in this situation you will need to hand resolve hostnames with one of the standard resolving APIs on our system, like CFHost. I will point you towards the Resolving DNS Hostnames document here:

<https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/ResolvingDNSHostnames.html>

---

However, note that there are many different DNS APIs on our platform:

CFHost — This is a simple async name-to-address and address-to-name API. For an example, see CFHostSample.

<https://developer.apple.com/library/archive/samplecode/CFHostSample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003222>

---

<dns_sd.h> — This is the API I recommend if you have advanced needs and want to go through the system resolver. A good place to start is the following:


DNSSDObjects

<https://developer.apple.com/library/archive/samplecode/DNSSDObjects/Introduction/Intro.html#//apple_ref/doc/uid/DTS40011371>

SRVResolver

<https://developer.apple.com/library/archive/samplecode/SRVResolver/Introduction/Intro.html#//apple_ref/doc/uid/DTS40009625>

---

<dns.h> — This is the API to use if you /don’t/ want to go through the system’s resolver. This is pretty obscure, but a few years back Quinn posted an example of this to DevForums.

<https://developer.apple.com/forums/thread/53025?answerId=242976022#242976022>

<dns_util.h> — This is intended to be used with the above but it contains a bunch of utilities that are useful in any manual DNS context.

---

<resolv.h> — This is the traditional BSD low-level resolver. In short, I would avoid this if possible.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com