Private relay and DNS filtering via NEPacketTunnelProvider extension

Question

Created Sep ’21

Replies 6

Boosts 0

Views 6.4k

Participants 2

I have a security app that filters DNS traffic via a NEPacketTunnelProvider extension, blocking access to dangerous domains (malware, phishing etc). The DNS requests are sent to a DNS server that will resolve only the safe domains.

With Private Relay ON I still have access in the extension to all the DNS queries, but unfortunately, the user can still access those domains on the device, although DNS resolutions are blocked in the extension for specific domains. This happens only when Private Relay is ON, so practically the web browsing protection does not work anymore.

With Private Relay ON, I noticed DNS requests for mask.apple-dns.net domain resolved by the my DNS server. How is this supposed to work?

Are other DNS requests sent to mask.apple-dns.net and not caught by our network extension? Is that supposed to happen?
a. Would a NXDOMAIN response for mask.apple-dns.net fix this behaviour and allow the app to offer protection while Private Relay ON?
b. Will any alert be displayed to the user in that case?
Do you have any other suggestions?
Could you clarify the behaviour for a NEPacketTunnelProvider extension processing only DNS requests?

I would have expected for the DNS name resolution queries to be processed only through the network extension.

An excerpt from "Get ready for iCloud Private Relay" says: “Similarly, if your app provides a network extension to add VPN or app-proxying capabilities, your extension won't use Private Relay and neither will app traffic that uses your extension.” “When a VPN configuration is active, connections use the VPN instead of iCloud Private Relay. Network Extension providers also don’t use iCloud Private Relay.”

I have also asked for help via Feedback Assistant (FB9623058).

Answered by RalucaoS in 687706022

I think I haven’t mentioned that I’m referring to an iOS app and, unfortunately, the doc mentions that NEDNSProxyProvider is available only for iOS supervised devices only.

What alternatives would there be for non-supervised devices?

DNS proxy providers are supported … on iOS supervised devices only.

https://developer.apple.com/documentation/networkextension/dns_proxy_provider

Boost

Answer 1

Systems Engineer OP

Apple

Sep ’21

I have a security app that filters DNS traffic via a NEPacketTunnelProvider extension, blocking access to dangerous domains (malware, phishing etc). The DNS requests are sent to a DNS server that will resolve only the safe domains. Could you clarify the behaviour for a NEPacketTunnelProvider extension processing only DNS requests?

You should not be using a NEPacketTunnelProvider in this manner. If you need to secure DNS traffic there is an DNS Network Extension API for doing this, i.e., NEDNSProxyProvider. NEDNSSettings should only be used for a SMALL set of hostnames that your business needs to resolve traffic for through the tunnel. The NEPacketTunnelProvider should NOT be used as a mechanism to intercept DNS traffic.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

RalucaoS OP

Sep ’21

Accepted Answer

I think I haven’t mentioned that I’m referring to an iOS app and, unfortunately, the doc mentions that NEDNSProxyProvider is available only for iOS supervised devices only.

What alternatives would there be for non-supervised devices?

DNS proxy providers are supported … on iOS supervised devices only.

https://developer.apple.com/documentation/networkextension/dns_proxy_provider

0

Answer 3

Systems Engineer OP

Apple

Sep ’21

doc mentions that NEDNSProxyProvider is available only for iOS supervised devices only

You are correct, NEDNSProxyProvider are available for supervised devices only and if you need to handle DNS traffic, you should use this API in a supervised setting.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 4

Systems Engineer OP

Apple

Sep ’21

blocking access to dangerous domains (malware, phishing etc).

If your goal is to block dangerous domains from a specific audience then you could take a look at the new Screen Time APIs on iOS 15 along with NEFilterDataProvider. NEFilterDataProvider with the new Screen Time APIs no longer require an supervised environment.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

1

Answer 5

RalucaoS OP

Sep ’21

Thank you for the suggestions, Matt. We will take a look at the NEFilterDataProvider & Screen Time APIs.

Still, could you clarify:

What is the expected behaviour for DNS packets when Private Relay is ON for both NEFilterDataProvider & NEPacketTunnelProvider?
Would a NXDOMAIN response for mask.apple-dns.net further prevent for unsafe domains to be resolved on the device?
Will any alert be displayed to the user in that case? (similar to attached photo)

0

Answer 6

Systems Engineer OP

Apple

Sep ’21

What is the expected behaviour for DNS packets when Private Relay is ON for both NEFilterDataProvider & NEPacketTunnelProvider?

Network Extension providers such as NEFilterDataProvider and NEPacketTunnelProvider should take precedence over Private Relay. That means that if traffic typically goes through Private Relay, like DNS traffic, and these providers are running, then these providers should handle the traffic instead. If you are not seeing this then please open a bug report.

Regarding:

Would a NXDOMAIN response for mask.apple-dns.net further prevent for unsafe domains to be resolved on the device?

The only advice I can offer here is to test this on your end to determine the best course of action.

Regarding:

Will any alert be displayed to the user in that case? (similar to attached photo)

If there is no Network Extension Provider installed on the machine/device and the machine/device is connecting to a private network that needs to audit traffic for business purposes, and is blocking the DNS name fro iCloud Private Relay, then yes, the user would see a prompt similar to the one you have attached. If their is a Network Extension provider running and the DNS name is not being blocked for iCloud Private Relay then you would not see this prompt. If are seeing otherwise, please open a bug report.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0