Private Relay with Encrypted DNS

Hi, I have an application that creates an encrypted DNS configuration (#wwdc20-10047) which redirects DNS queries for a specific domain to my DNSOverHTTPS server system wide using NEEvaluateConnectionRule(matchDomains: ...).

I was wondering how that would get affected by a user enabling Private Relay. An excerpt from "Get ready for iCloud Private Relay":

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.

Does it mean that both DNS and HTTPS traffic matching my domain(s) will not use Private Relay system wide?

In my use-case, my domain can be resolved while browsing web (using Safari, Chrome, etc.) as well as in other apps.

Thank you!

Replies

Does it mean that both DNS and HTTPS traffic matching my domain(s) will not use Private Relay system wide?

Network traffic that is claimed by a Network Extension is not eligible for Private Relay. Please let me know if you see different. See the Get ready for iCloud Private Relay video around the 5:15 mark.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
  • When I have iCloud private relay enabled and I go to: Settings -> WiFi -> click on my WiFi network -> Configure DNS, it mentions: “DNS requests are being routed by iCloud Private Relay for this Wi-Fi network. Turn off Private Relay to manually configure DNS settings.”

    When private relay is on, are all DNS resolution queries handled by the DNS server private relay utilizes or can we configure our own DNS server in the WiFi settings?

Add a Comment

When private relay is on, are all DNS resolution queries handled by the DNS server private relay utilizes or can we configure our own DNS server in the WiFi sett

When iCloud Private Relay is on, DNS queries will be handled by iCloud Private Relay. To configure your own DNS Settings, turn off iCloud Private Relay or use a Network Extension API that would handle DNS traffic, such as a NEDNSProxyProvider.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
  • In my testing I have found that, with iCloud Private Relay enabled, NEDNSProxyProvider is bypassed

Add a Comment

In my testing I have found that, with iCloud Private Relay enabled, NEDNSProxyProvider is bypassed

If you can confirm that you have iCloud Private Relay enabled and DNS traffic is passing through iCloud Private Relay and then you enabled a NEDNSProxyProvider and no flows are handed off to your NEDNSProxyProvider then we should get this down as a bug report. Please respond back with a Feedback ID.

As a note, if you do find out that this is the case, please provide a sysdiagnose with the following debug profiles installed on the device when you reproduce the issue:

  • mDNSResponder for iOS
  • Network Diagnostics for iOS
  • VPN (Network Extension) for iOS
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,

If you can confirm that you have iCloud Private Relay enabled and DNS traffic is passing through iCloud Private Relay and then you enabled a NEDNSProxyProvider and no flows are handed off to your NEDNSProxyProvider then we should get this down as a bug report. Please respond back with a Feedback ID.

What happens is, when the private relay is disabled, all works as per expected (that is, the DNS requests are forwarded to the upstream provider) and DNS responses are received for these hostnames.

When private relay is enabled, the flows never get passed on to the filter via handleNewFlow.

Upon re-toggling, (turning off private relay), the flows start coming through again.

I am testing on iOS 15 Beta 5 (iPhone 11).

To my this sounds like a bug - should I submit as per your initial recommendation - just wanted to clarify behaviour first Thanks

Nick

Nick,

Thank you for the response here. Regarding:

When private relay is enabled, the flows never get passed on to the filter via handleNewFlow. Upon re-toggling, (turning off private relay), the flows start coming through again. To my this sounds like a bug - should I submit as per your initial recommendation - just wanted to clarify behaviour first

This does sound like a bug as my understanding was that Network Extensions should take precedence here over iCloud Private Relay. Now, having said that, I could have been wrong and possibly only providers like NEPacketTunnelProvider, NEAppProxyProvider, and on macOS NETransparentProxyProvider take precedence over iCloud Private Relay and NEDNSProxyProvider is not included in this group. Either way I think we need a bug report here so that we can at least get this documented. Please respond back with Feedback ID.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,

I have submitted the Feedback as suggested and the ID for your reference is FB9511164. The fact that some filtering controls may be not supported is a little concerning, esp. when we are also leveraging the NEFilterControlProvider restrictions in our app.

Thanks

Nick

I have submitted the Feedback as suggested and the ID for your reference is FB9511164.

Thank you, I have added some internal notes to your bug report for more information regarding NEDNSProxyProvider.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

@Nick

Can you add a focused sample of what you are seeing with NEDNSProxyProvider to your bug report for FB9511164?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,

Can do - what exactly do you mean by focussed sample ? Is there anything in particular you would like me to look at. I have tried the latest Beta (today) a d it is still happening. Essentially the behaviour seems to be the the Private Relay is capturing the DNS request for the initial ingress proxy for it's DNS request and sending that through to the NEDNSProxyProvider flow rather than the request itself, eg. standard DNS flow with request/response for pretty much any domain ... e.g. in the case below, notpurple.com

-> WITH Private Relay enabled ...

DNS Request [33 bytes] : 
00000000 fe ff 01 00 00 01 00 00 00 00 00 00 04 6d 61 73 .............mas
00000010 6b 06 69 63 6c 6f 75 64 03 63 6f 6d 00 00 01 00 k.icloud.com....
00000020 01                        .                        .
DNS response : [183 bytes] : 
00000000 3e f6 81 80 00 01 00 01 00 01 00 00 04 6d 61 73 >............mas
00000010 6b 06 69 63 6c 6f 75 64 03 63 6f 6d 00 00 41 00 k.icloud.com..A.
00000020 01 04 6d 61 73 6b 06 69 63 6c 6f 75 64 03 63 6f ..mask.icloud.co
00000030 6d 00 00 05 00 01 00 00 00 1e 00 14 04 6d 61 73 m............mas
00000040 6b 09 61 70 70 6c 65 2d 64 6e 73 03 6e 65 74 00 k.apple-dns.net.
00000050 04 6d 61 73 6b 09 61 70 70 6c 65 2d 64 6e 73 03 .mask.apple-dns.
00000060 6e 65 74 00 00 06 00 01 00 00 00 9a 00 49 07 6e net..........I.n
00000070 73 2d 31 34 36 32 09 61 77 73 64 6e 73 2d 35 34 s-1462.awsdns-54
00000080 03 6f 72 67 00 11 61 77 73 64 6e 73 2d 68 6f 73 .org..awsdns-hos
00000090 74 6d 61 73 74 65 72 06 61 6d 61 7a 6f 6e 03 63 tmaster.amazon.c
000000a0 6f 6d 00 00 00 00 01 00 00 1c 20 00 00 03 84 00 om........ .....
000000b0 12 75 00 00 01 51 80               .u...Q.

-> WITHOUT Private Relay enabled ...

DNS Request [31 bytes] : 
00000000 16 bb 01 00 00 01 00 00 00 00 00 00 09 6e 6f 74 .............not
00000010 70 75 72 70 6c 65 03 63 6f 6d 00 00 41 00 01   purple.com..A..
DNS response : [60 bytes] : 
00000000 16 bb 81 00 00 01 00 01 00 00 00 00 09 6e 6f 74 .............not
00000010 70 75 72 70 6c 65 03 63 6f 6d 00 00 41 00 01 09 purple.com..A...
00000020 6e 6f 74 70 75 72 70 6c 65 03 63 6f 6d 00 00 01 notpurple.com...
00000030 00 01 00 00 00 1e 00 04 23 f4 79 44       ........#.yD

I have covered all this in the original bug report but if there is something else you need please let me know, thanks.

Nick

  • Hi Matt,

    Any update on this one? Thanks

    Nick

Add a Comment