Jamf Safe Internet Adds Custom DNS Support

At the end of 2022, I wrote a blog that explored how to configure Jamf Safe Internet by customizing configuration profiles and adjusting the XML. Since then, Jamf Safe Internet (JSI) has evolved by adding On-Device Content Filtering (ODCF) as well as using DNS over HTTPS (DoH) as the default vectoring method.

During a recent update, Jamf Safe Internet has received a new “Custom DNS” feature which will solve the original problem through the JSI console. What does this mean for customers? The majority of the heavy lifting regarding XML and configuration profiles is mostly resolved for you.

Working with internal services + Jamf Safe Internet

As the adoption of JSI increases, so do the use cases. A crucial one is the ability to connect to internal services, such as file servers and web servers, to name but a few service host types.

Due to the way that Jamf Safe Internet is designed, learning institutions aren’t able to access internal services without some additional configuration. Jamf Safe Internet now uses two technologies to help keep students and teachers safe online. Network traffic flows through one and then the other.

First, traffic is evaluated on the device itself for the category of the destination. Based on the policies set, JSI will either block or allow this traffic. If traffic is allowed, JSI pushes all DNS requests to the DoH Gateway within our Security Cloud, evaluating domains against security policies configured in JSI.

In order to better understand why additional configuration to our Jamf Safe Internet deployment is needed, a basic knowledge of networking — particularly around what DNS is and how it works — is required. If this concept is new to you or you’d like a refresher, this informational video from Amazon Web Services explains high-level DNS concepts in under five minutes.

Accessing internal services without Jamf Safe Internet

First, let’s look at how a device typically connects to an internal service, without JSI.

For example, a school has a file server onsite (named ‘file’) where students store their data. When a device connects to the school’s network, the Dynamic Host Control Protocol (DHCP) gives it an IP address and a DNS server. Generally, an onsite DNS server contains the entries for the internal domain (configured and maintained by the school IT) which in this example is named: myschool.local.

When a student tries to access the file server, they type in its hostname, “file.myschool.local”. The device starts an exchange with the DNS server. If the device and the DNS server were people, the conversation would go something like this:

• Client device: “Hey DNS Server, the student is looking to go to file.myschool.local but I like numbers, not words. Can you tell me the IP address for file.myschool.local please?”
• DNS server: "Sure, and if I don’t know what it is, I can ask one of my friends out on the internet. Let’s see, myschool.local…I recognize that domain. The IP address for file.myschool.local is: 10.0.0.20."

With the information it needs to communicate directly with the file server, the device connects to it via its IP address resolved by DNS, presenting the student with the shared folder that they requested.

Accessing internal services with Jamf Safe Internet

Using the example from above but adding Jamf Safe Internet into the mix. Everything starts the same as before. When the device connects to the school’s network, DHCP provides the necessary networking information.

However, we have Jamf Safe Internet installed through a configuration profile that’s deployed via MDM. Included in its payload is a DNS setting, making it a managed preference.

Note: Preferences managed via MDM on Apple Devices will always supersede any setting of the same kind that appears on the device (this is due to the way Apple devices look for resources, starting with:

• managed
• user
• local
• system

This means that although the device was given a DNS server address by DHCP, it will default to using the MDM-provided one. In this case, it’s using the DoH Gateway from Jamf Security Cloud.

When the student contacts the file server by typing “file.myschool.local”, the device starts an exchange with the DNS server. Only this time, the DNS server is the DoH Gateway provisioned in the managed preference, which sits outside of the institution’s internal network. If the device and the DNS server were humans, their conversation would go something like this:

• Client device: “Hey DNS Server, the student is looking to go to file.myschool.local but I like numbers, not words. Can you tell me the IP address for file.myschool.local please?”
• DoH Gateway: ”I do not recognize the myschool.local domain. In fact, nobody on the internet knows anything about myschool.local. I don’t know the IP address of the service you’re looking for.”
• Client device: ”Oh okay, sorry. I’ll have to tell the user that I cannot find or connect to the service they have requested.”

The student is then presented with a “cannot connect to server” error message.

Custom DNS makes Jamf Safe Internet aware of your internal services

In a prior blog, this is where I branched off to talk about how to create bypasses for internal services by downloading and manipulating XML and configuration profiles. However, this is now outshined by the new Custom DNS feature making accessing internal services a breeze for JSI admins.

In a nutshell, by using Custom DNS settings in the JSI console we are making the DoH Gateway aware of your internal services. Custom DNS settings allow populating the hostname (file.myschool.local) and its IP address. Doing so results in the DoH Gateway returning the IP address of local services, permitting the device to connect to it successfully instead of displaying an error message because it cannot be found.

Note: For those preferring the bypass method for internal services using a modified XML and configuration profile, bear in mind that doing so this way does not protect network traffic against web-based threats, like phishing for the bypassed domain. Despite the chances that you may recognize and trust internal services to not be a spam or phishing site, it is nonetheless important to point out.

How to configure a Custom DNS setting

To configure a custom DNS mapping in Jamf Safe Internet, navigate to Intergrations → Custom DNS → Click “AddHostname”.

From here you can add the hostname and its associated IP address. Also, check the Connect to Secure DNS box before clicking Save.

Remember that, unlike with a content policy where you can allow an entire domain, for example, myschool.com, you are mapping a single host to its IP address. Therefore, if you have multiple services you rely on, you will need to add an entry in the Custom DNS window for each. In the example below, I have a file share, a web server and a media server.

It is worth pointing out that if you have large numbers of custom hostname mappings, you can import them from a CSV using the Import button in the Integrations → Custom DNS window.

Don’t forget to check your Content Policies

As we discussed earlier, Jamf Safe Internet uses two technologies, with requests flowing through one (and if allowed) and then to the other. The portion that we configured in the previous section is part of the DoH technology or the second step in the chain.

Depending on your content filtering policy setting, you might be blocking access to internal services due to their category before they can even reach the DoH Gateway or retrieve the custom DNS record. The traffic flows through the ODCF technology first which is responsible for blocking content based on its category.

As an example, educational institutions will often block content flagged as “Uncategorized” by policy. Since your internal service is, well internal, it isn’t categorized like the rest of the internet (external). Therefore, your internal services will be seen as uncategorized and get blocked on the device. This can always be verified using the domain checker tool built-in to JSI.

To prevent internal services from being incorrectly categorized and blocked by default, configure custom rules in the content policy to always allow traffic going to internal services so that network traffic flows through ODCF and onto DoH.

This is accomplished by navigating to Policies → Web protection policy → Custom rules. From there, enter either the hostname file.myschool.local, or if wanting to allow all services internally within your domain, enter the root domain name myschool.local. Click Save and Apply before moving away from the page.

Note: Depending on your needs and security requirements, you may find that using the domain resolves the issue where multiple services are concerned. Conversely, best practice might be to configure the host itself when only one service is used.

With the Custom DNS feature added to Jamf Safe Internet, implementing custom rules allows stakeholders to access internal services without the administrative overhead of resorting to messy workarounds.

…But you might still have to dig into XML to access internal services

In many cases, using the built-in Custom DNS feature will be all that’s needed to access internal services. However, trying to use this workflow for more of a “core service” may likely still cause issues. The main one that we’ve tested and found still needs a bypass added directly to the configuration profile if you’re binding macOS devices to Active Directory.

A bypass differs from Custom DNS in that if the device needs to contact the host ad.myschool.local, it is able to get around the managed DNS setting enforced by MDM, going directly to the DNS server that it was given by DHCP. This direct approach appears more reliable for some core services.

Creating an internal service bypass

Adding additional key pair values into the Activation Profile enables access to the internal services while keeping the device itself protected with Jamf Safe Internet. The information that will be added essentially tells the device that if it's trying to get the IP address of a particular domain (which we will list), then instead of using the DNS server listed in the managed preference, use the DNS server entry that contains records about your local domain (typically, assigned by DHCP).

To create a bypass, we must first obtain an Activation Profile from Jamf Safe Internet. Navigate to Devices → Activation Profiles → click on an Activation Profile (this may be the default profile or a profile of your choice depending on your environment).

Next, under “Select your UEM solution”, choose either Jamf Pro or Jamf School (depending on your deployment). Under “Select your OS”, choose either iOS and iPadOS supervised (16 or later) or macOS depending on your deployment. Should you need a local bypass on both macOS and iPad you must repeat the steps, once for each OS

Note: If your iOS and iPadOS devices are using an OS earlier than 16 and you need to create a local bypass, please refer to the original post for support.

After selecting your OS, click the Download configuration profile button to download the Activation Profile to your computer.

Once downloaded, find the profile, open it with the XML editor of choice and scroll through the code until you find the section below:

Here you will see where connections are evaluated alongside a list of domains that are configured to never connect to the DoH Gateway. In other words, when trying to reach any of the listed domains, connections to these domains bypass the DoH Gateway. As part of the standard DoH configuration, we already see a list of domains for Jamf and Apple, among others.

As you can tell from the image above, create a new line with your local domain in between brackets, then save the profile to your computer. Finally, upload it to Jamf School/Jamf Pro using the Upload Custom Profile option.

Then, scope this profile to the device instead of the standard profile that is created as part of the:

• ‘singleclick’ connection in Jamf School
• standard Activation Profile you download and install in Jamf Pro

Lastly, deploy Jamf Trust along with your custom profile for iOS and iPadOS devices.

Devices with an Activation Profile configuration as the above will then be protected via Jamf Safe Internet, but will also be able to reach any resources located on the internal network, such as file or web servers that aren’t externally accessible.

If you have devices already activated in Jamf Safe Internet and then need to issue a new Activation Profile with the local bypasses, please review Known Issues in the Device Enrollment section of the Jamf Safe Internet documentation.

Wrap Up

With an easy-to-use interface that’s accessible from the cloud-based console, Custom DNS is a critical new feature of Jamf Safe Internet. One that enables admins to customize access to local services with just a few clicks, while still allowing the flexibility to dig deeper to create local bypasses to meet your unique needs.