Need for system-wide profile

[csousougen]

In Mac, Safari uses the encrypted dns, all other apps like terminal and App Store use the unencrypted dns server from network settings.
Could you please create a profile that uses system-wide encrypted dns?

[paulmillr]

How?

[csousougen]

I’ve found these system-wide configurations but i don’t know how to import into a mobileconfig

https://www.wwdcnotes.com/notes/wwdc20/10047

[ghost]

@csousougen Actually an MDM profile is by default system wide...
During the developer conference of 2020 when they have announced this feature they have said :

"The first way is to use a single [encrypted] DNS server as the default resolver for all apps on the system. If you provide a public [encrypted] DNS server, you can now write a network extension app that configures the system to use your server. Or, if you use Mobile Device Management to configure enterprise settings on devices, you can push down a profile to configure encrypted DNS settings for your networks,"

The code you have linked is for the dev who want to use encrypted dns for their app (or make an app to activate this dns (like adguard pro for iOS)).

[ghost]

@paulmillr Since it's not a bug in .mobileconfig file I ask this issue be closed.
We cannot fix it only apple can so I vote to close it but it's up to you.

[paulmillr]

@BirdInFire I won't close these and other issues that describe Apple bugs. We can't do anything but we can make bugs visible.

[csousougen]

I can say for sure that on Mac, it is not system wide. The DIG command gets results from the DNS servers that are set in Network and not from the MDM profile. If you try "dig google.com" you will see ;; SERVER: IP address in results.

[ghost]

I can say for sure that on Mac, it is not system wide. The DIG command gets results from the DNS servers that are set in Network and not from the MDM profile. If you try "dig google.com" you will see ;; SERVER: IP address in results.

i have tested it like 10 minutes ago with nextdns to see the log on DNSserver side and it's totally system wide

[csousougen]

@BirdInFire could you please try to put a fake dns (127.0.0.5) in network settings, press Apply and then check if DIG command works?
Also, I tried to dig astalavista.com from the cmd and it didn't show up in nextdns logs.
However, all queries that come from Safari are totally encrypted.

[ghost]

Will do a more profound testing to be sure

[ghost]

I have tested with a new account and done a ping on terminal on google.lol (who does not exist) after having installed their profile (used on apple.nextdns.io) and some second after the ping (who have failed since google.lol does not exist, it appeared on the logs, tried again with .jp and worked also).

Need more search but I really think it's system wide, maybe when you modify your dns (after) having installed the profile it override the profile.

[csousougen]

@BirdInFire You are correct, with ping command it works. But it does not work with DIG command and nslookup command.
Could you please try these commands too? Is it system wide if it does not work with any command?

[ghost]

Sure will do a complete test when I'm at home (actually I have done it remotely), but it's possible that some system component are exempted by this profile (network app).

[ghost]

@csousougen after some search I have found some profile who add :

<key>PayloadScope</key>
<string>System</string>

Can you add it to your profile and do your test (seem I can't replic the problem as well as you).
And see if it solve the problem ?

If it's the case I will do a PR on all profile to add it.

[csousougen]

Hi @BirdInFire
I added the 2 lines just above in nextdns profile. Still, dig and nslookup commands do not go through the encrypted dns (no logs in nextdns).
However, I see in the logs, queries from all apps that run on my mac, this tells that the profile is system wide, except for these two commands (dig and nslookup).

[paulmillr]

Added BirdInFire's stuff to readme.

[quyleanh]

I also have the same problem. Cannot get profile work on macOS since on iOS it works well.

[ASweatyPenguin-1]

Added BirdInFire's stuff to readme.

Hello @paulmillr, I'm not much of a tech person, I got linked here by Sun Knudsen Privacy Guides. Sorry if you don't take questions from newbies...Anyway, my questions:

If @BirdInFire's stuff applies this to significantly more (app store, terminal, etc.) then why not put it in the published profile?

I'm nervous to add it because You said there "seems" to be an additional option, have you changed your opinion at all on @BirdInFire's entry?

Thanks for your time, this stuff is cool!

[paulmillr]

If @BirdInFire's stuff applies this to significantly more (app store, terminal, etc.) then why not put it in the published profile?

The flag needs a thorough investigation, which I don't have time to do right now. Thorough meaning: listening to the traffic, pros & cons etc.

[fyr77]

According to the Configuration Profile Reference, the flag determines if something is to be installed for the current user or the whole system - this does not sound like it should influence app behaviour (it might still do so).

Exact wording:

Determines if the profile should be installed for the system or the user. In many cases, it determines the location of the certificate items, such as keychains. Though it is not possible to declare different payload scopes, payloads, like VPN, may automatically install their items in both scopes if needed.
Legal values are System and User, with User as the default value

[akasandra]

I've found something more interesting.

While Safari uses System-wide DoH correctly, Firefox won't in several cases: In Firefox settings, "Enable secure DNS using:" you have to select either "Default Protection" or "Off" - it would then use DoH from system.
Choosing "Increased protection" and "Max protection" may result into lookup hangs or using mixed secure/insecure DNS, according to my dnsleaktest results.

Google Chrome does not use System-Wide profile DNS-over-HTTPS for me. There is only option to manually enable Chrome-wide DoH in its settings, manually selecting a provider. This should be stated in Readme.

• This what I've used and indeed should be added for all. Not sure at which level this must be, though.

<key>PayloadScope</key>
<string>System</string>

btw: nslookup and dig are not designed to support DoH. They are only designed to be terminal utilities for developers not serving any security or privacy purpose.

[fyr77]

Based on the previous comment, it seems that the encrypted DNS settings have to be implemented and honoured by each individual app. So there is no local DNS server translating all DNS requests into DoH/DoT and sending it to the defined server, rather it is just saved as a value and apps may choose to use that value when operating.

This also means there is no way to force any app to use encryption settings, I believe. Still, it seems as if some apps only use encrypted DNS if "System" scope is selected...

[Fail-Safe]

Still, it seems as if some apps only use encrypted DNS if "System" scope is selected...

Do you find this to still be the case in current versions of MacOS, iOS, iPadOS, etc?

[fyr77]

@Fail-Safe Unfortunately, I no longer own any apple devices to test this with. Perhaps someone else can provide some insight.

[Homas]

Do you find this to still be the case in current versions of MacOS, iOS, iPadOS, etc?

On recent MacOS, I see the same behavior akasandra described above.
I didn't check the user/system scope because not sure which apps except Safari/FF actually use DoH.
kdig & dog ignore the settings.

[ghost]

I do not really know for FF or Chrome on apple (since I only use safari on apple device), but if it's anything like windows I think they have their own resolver maybe why they blatantly ignore the profile.

As for app, it seem that any app from the store obey the profile.
And since I never install anything outside the store I cannot say much more.

As said sonner dig and other tool like that are not mean to use encrypted DNS as they are often used for debugging purpose.

I would not surprise me at all if apple deliberately excluded them for this to help people debug DNS issue when profile enabled.