Use DNS TXT records with content caches for Apple devices
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 organisation provides DNS service for your own domain and is the source of authority for the hostnames for betterbag.com, you put the caching TXT record in the betterbag.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 /private/etc/bind/ directory, and the zone file name has been defined in /private/etc/bind/named.conf (most likely, “db.betterbag.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.
Use DNS TXT records to publish content across multiple public IP addresses
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. Apple uses these lists 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 favoured local IP addresses to reduce the impact of other content caches on your network. If no favoured local IP addresses are declared in a TXT record, all clients 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 favoured 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.
DNS TXT record format
The syntax for specifying TXT records, and non-ASCII characters in TXT records, may 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 favoured content caches.
The following examples each define the same set of two IP address ranges: a range that starts at 17.53.22.2 and ends at 17.53.22.254, and a range that consists of a single IP address, 17.53.23.1. The difference between them is that the first example uses the prs key and the second example uses the prn key.
_aaplcache._tcp 10800 IN TXT "prs=17.53.22.2-17.53.22.254,17.53.23.1"_aaplcache._tcp 10800 IN TXT_aaplcache._tcp 10800 IN TXT "prn=\x24\x11\x35\x16\x02\x11\x35\x16\xfe\x14\x11\x35\x17\x01"The keys use different formats for the IP address ranges specified in the value:
prs or fss: The value of the
prsorfsskey 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
prnorfsnkey 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.
0x24 denotes a starting and ending IPv4 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 can 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 to _aaplcache4._tcp are resolved in parallel first. If they all end with continuation markers, then _aaplcache5._tcp to _aaplcache9._tcp are resolved next, and so on.
Here’s an example of three chained records:
_aaplcache._tcp 10800 IN TXT "prs=17.250.1.1,17.250.2.1-17.250.2.254,more"_aaplcache1._tcp 10800 IN TXT "prn=\x24\x11\xfa\x03\x01\x11\xfa\x03\xfe+"_aaplcache2._tcp 10800 IN TXT "prs=17.250.4.5"Example 1
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 unauthorised content cache, you can append “,more” to that record and add a second record, like this:
_aaplcache._tcp prs=203.0.113.10-203.0.113.19,more_aaplcache1._tcp fss=10.0.0.30,10.1.0.30,10.2.0.30As long as at least one of the three content caches is using this method, devices with iOS 13, iPadOS 13.1, macOS 10.15, tvOS 13, or later looking for shared content use those content caches exclusively. If all three are offline, clients looking for shared content can use any available content cache.
As long as 10.2.0.30 is using this method, devices with iOS 13, iPadOS 13.1, macOS 10.15, tvOS 13, or later, looking for iCloud content use it exclusively. If it’s offline, clients looking for iCloud content use any available content cache.
Devices with iOS 12 or earlier and macOS 10.14 or earlier use any available content cache, not just those three.
Example 2
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 unauthorised content caches, you can set one record like this:
_aaplcache._tcp fss=192.168.50.1-192.168.50.254As long as at least one content cache is available in that range for the type of client it seeks (shared or iCloud), iOS 13, iPadOS 13.1, macOS 10.15 and tvOS 13, or later clients use that content cache exclusively.