/etc/resolv.conf file is not patched with DNS on MacOS Big Sur

/etc/resolv.conf is an implementation detail / compatible sop on macOS. No third-party code should be reading or writing this file.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you Quinn for your prompt reply. This was working in versions prior to Big Sur. So, my question was specific to Big Sur. Was the implementation changed in Big Sur? Is there a workaround for this?

Regards,
Raghu.

Is there a workaround for this?

A workaround suggests that the previous behaviour was supported, which it was not.

What are you trying to do here? That is, what do you hope to gain by modifying this file?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

I understand that /etc/resolv.conf is a link to /var/run/resolv.conf.

Here is our use case. We have a VPN application and the DNS Names (search names) are configured at our VPN servers. When we connect to the VPN, our application takes a backup of the existing file /var/run/resolv.conf and creates a new file with DNS entries we configured at the VPN Server. Here are the contents of the file before VPN is connected.

nameserver fe80::be0f:9aff:feeb:14c0
nameserver 192.168.0.1

Here is the content of the file after VPN is connected.

search olympus.f5net.com f5net.com
nameserver 192.168.232.186
nameserver 192.168.232.187

As you can see, after connecting to VPN, the file /var/run/resolv.conf is patched with our search domains configured at our VPN server.

This is working until Mac Catalina. But after Big Sur, the above file is not changed after we connect to VPN. Hope this answers you question. With these details in place, can you please let me know if there are any changes in Big Sur that can potentially break this functionality? Is this expected in Big Sur? If so, what would be your suggestion to mitigate this (like Workaround etc.).

Regards,
Raghu.

When we connect to the VPN, our application takes a backup of the
existing file /var/run/resolv.conf and creates a new file with DNS
entries we configured at the VPN Server.

Well, that’s worrying. Is your VPN client built as a Network Extension provider? Or using some legacy interface?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Or EdgeClient UI is written in ObjectiveC. The "tunneling" of traffic and patching of the DNS entries are native .cpp applications.

Regards,
Raghu.

Right, but what API are you using to set up your tunnel? Modern VPN clients do this with a Network Extension packet tunnel provider. Is that what you’re using?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

We are using C Socket APIs for establishing the tunnel. We are reading and writing to the /var/run/resolv.conf using C APIs.

Regards,
Raghu.

We are using C Socket APIs for establishing the tunnel.

Hmmm. I’m going to be really clear here: You should switch to using a Network Extension provider. That is the future of VPN on all of Apple’s platforms [1]. The ad-hoc approach that you’re currently using was necessary before we introduced NE provider support (on the Mac this was in macOS 10.11) but it has effectively been obsoleted by that support. If you continue down this path you will see increasing problems as the system evolves.

Oh, and just as aside, DTS now only supports VPN developers who use NE providers.

In the specific case of customising the DNS setup, modifying /etc/resolv.conf has never been supported on macOS. If you implement your VPN as an NE provider, the system will take care of applying your DNS settings as configured by the NEDNSSettings API.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, the ones that support VPN.