Enable content cache discovery across multiple public IP addresses on Mac
If your network uses multiple public IP addresses to connect to the internet, such that a content cache might register using a different address than a client uses for discovery, you need to provide both the content cache and the clients with a list of those addresses. These lists are used to cross-match registration and discovery requests involving multiple public IP addresses.
To avoid manual configuration of clients, content caching uses DNS TXT records to publish the public IP address information for clients on your network. The TXT record needs to be published in the default DNS search domain used by your clients.
With macOS 10.15 or later, you can also specify favored local IP addresses to reduce the impact of other content caches on your network. If no favored local IP addresses are declared in a TXT record, all clients will use any available content cache.
The correct data for the TXT record for public IP address ranges can be generated automatically or manually. In either case, you need to edit the DNS record, or give the settings to your DNS provider to create or edit the TXT record in the zone file. Note that you can’t automatically generate TXT records for favored local IP addresses—those must be created manually.
Note: These records are necessary only for your internal network. External DNS doesn’t require the additional record.
Configure content caching clients to support multiple IP addresses
On your Mac, choose Apple menu > System Preferences, click Sharing, then select Content Caching.
Press and hold the Option key, then click Advanced Options.
Click the “My local networks” pop-up menu, then choose “use custom public IP addresses.”
Click the Add button , then enter a range of public IP addresses.
Repeat for any additional IP address ranges you want to enter.
Create a DNS text record that describes the public IP addresses you entered.
You can use the content caching service to generate the text record or create it manually (the format is described below). To generate the text record:
Click the DNS Configuration button.
Choose your DNS server type (BIND or Windows).
Copy the generated text record, then paste it into a text file so it is available to use later (when adding it to the DNS zone file).
When you finish the configuration, click OK.
Add the text record to the authoritative DNS zone file for the domain.
DNS TXT record format
The syntax for specifying TXT records, and non-ASCII characters in TXT records, will vary for your DNS server. The examples presented here are for illustration only.
The DNS text records for content caching have the same format as DNS-SD TXT records (key-value pairs):
name._tcp 10800 IN TXT "[prs|prn|fss|fsn]=addressRanges"
Use the prs and prn keys for public IP address ranges; use the fss and fsn keys for local IP address ranges of favored content caches.
Both IPv4 and IPv6 addresses are accepted, but only IPv4 is supported.
The following examples each define the same set of two IP address ranges: a range that starts at 18.104.22.168 and ends at 22.214.171.124, and a range that consists of a single IP address, 126.96.36.199. The difference between them is the first example uses the prs key and the second example uses the prn key.
_aaplcache._tcp 10800 IN TXT "\x2aprs=188.8.131.52-184.108.40.206,220.127.116.11"
_aaplcache._tcp 10800 IN TXT "\x12prn=\x24\x11\x35\x16\x02\x11\x35\x16\xfe\x14\x5d\xb8\xd8\x77"
The keys use different formats for the IP address ranges specified in the value:
prs or fss: The value of the prs or fss key is a sequence of comma-separated ranges of IP addresses in presentation format (ASCII dot notation). This syntax is for easy configuration. A range consists of either a single IP address or two IP addresses separated by a hyphen.
prn or fsn: The value of the prn or fsn key is a sequence of concatenated ranges of IP addresses in binary network-byte-order format. This syntax is for range sequences that are too long for a DNS record when specified in presentation format. Each range in the sequence is preceded with a byte that specifies the type of range that follows:
0x14 denotes a single IPv4 address.
0x16 denotes a single IPv6 address.
0x24 denotes a starting and ending IPv4 address range.
0x26 denotes a starting and ending IPv6 address range.
You can chain multiple records together. If you do, name the first record
_aaplcache._tcp and subsequent records from
_aaplcache1._tcp up to
_aaplcache24._tcp, for a maximum of 25 chained records.
To maintain compatibility with clients using macOS 10.14 or earlier, place records that use the prs or prn keys before any records that use the fss or fsn keys.
Chain records together by putting a continuation marker on all but the last TXT record.
The prs and prn syntaxes may be mixed between records in the chain. With the prs syntax, append “,more” to the end of the record value. With the prn syntax, append “+” (0x2b) to the end of the record value. The first record lacking such a continuation marker ends the chain.
Chained records are resolved in batches of five at a time—that is, _aaplcache._tcp and _aaplcache1._tcp through _aaplcache4._tcp are resolved in parallel first, and if they all end with continuation markers, then _aaplcache5._tcp through _aaplcache9._tcp are resolved next, and so on.
Here’s an example of three chained records:
_aaplcache._tcp 10800 IN TXT "\x2bprs=18.104.22.168,22.214.171.124-126.96.36.199,more"
_aaplcache1._tcp 10800 IN TXT "\x0eprn=\x24\x11\xfa\x03\x01\x11\xfa\x03\xfe+"
_aaplcache2._tcp 10800 IN TXT "\x0eprs=188.8.131.52"
The syntax for specifying TXT records, and non-ASCII characters in TXT records, may vary based on your DNS server. Some servers don’t need the leading length byte (\x2a, \x12, \x2b, \x0e, and \x0e in the examples, respectively) because they prepend it automatically.
This example demonstrates a scenario where both a prs or prn record and an fss or fsn record are required.
Suppose you already have one DNS TXT record named “_aaplcache._tcp” with the value “prs=203.0.113.10-203.0.113.19” and three content caches deployed with local addresses 10.0.0.30, 10.1.0.30, and 10.2.0.30. The first two serve shared content only, and the last one serves both shared and iCloud content.
To prevent clients from using an unauthorized content cache, you can append ",more” to that record and add a second record, like this:
As long as at least one of the three content caches is running, macOS 10.15, iOS 13, iPadOS 13, or tvOS 13 or later clients looking for shared content will use those content caches exclusively.
If all three are offline, clients looking for shared content will use any available content cache.
As long as 10.2.0.30 is running, macOS 10.15, iOS 13, iPadOS 13, tvOS 13 or later clients looking for iCloud content will use it exclusively. If it is offline, clients looking for iCloud content use any available content cache.
Devices with macOS 10.14 or earlier or iOS 12 or earlier use any available content cache, not just those three.
This example demonstrates a scenario where a prs or prn record isn’t required.
Suppose you have only one public IP address and don’t use the DNS TXT record feature at all, but have a few content caches on a subnet reserved for server machines (192.168.50/24).
To prevent unauthorized content caches, you can set one record like this:
As long as at least one content cache is available in that range for the type of client it seeks (shared or iCloud), macOS 10.15, iOS 13, iPadOS 13, tvOS 13 or later clients will use that content cache exclusively.
Add TXT records to the DNS zone file
Add one or more TXT records to the zone file for your local domain on your DNS server. Add the DNS TXT record to the zone that:
Is authoritative for the domain
Matches the default search domain for network clients
For example, if your organization provides DNS service for your own domain and is the source of authority for the host names for example.com, you put the caching TXT record in the example.com zone file.
Important: If you don’t host the authoritative DNS service for your domain, you can’t add the TXT record yourself. Coordinate with your DNS provider to have them add the TXT record provided.
If you use BIND9 DNS, copy the generated TXT record and paste it into your DNS zone file.
For BIND9-based DNS on Linux, this file is in the
/etc/bind/ directory, and the zone file name has been defined in
/etc/bind/named.conf (most likely, “db.example.com.”).
If you use Windows DNS, do one of the following:
If you generated the text record using the content caching service: Replace the ZoneName variable in the generated command with your network’s DNS zone name, then run the command on your Windows DNS computer.
If you created the text record manually: Enter the TXT record information manually using the Windows Server administration tools.