1

our network has 3 primary public IPs (datacenter, user set a, user set b). I would like to set up the Caching server, and am just trying to understand the breakdown of the DNS entry.

In the data portion, the "prs=1.2.3.4,2.3.4.5,3.4.5.6" section: What does "prs" actually equate to? Peers? If this is going into internal DNS, wouldn't I want to use the internal IP of the cache server, as opposed to the public IPs?

Also, does this record assist the clients/devices, or the server itself?

bmike
  • 235,889
TPCoMatt
  • 21
  • I was tempted to edit this down to one question, but I'm not sure which one question is most important. Do you actually have the server set up and running her you just trying to get your mind around the planning before you do anything? – bmike Nov 25 '15 at 17:26
  • @bmike - its up-and-running (whether it's working is a different story...). I mainly want to understand what the DNS entry does. – TPCoMatt Nov 25 '15 at 17:35

2 Answers2

1

Reading the help pages I would assume that prs stands for public range comma-separated and prn stands for public range binary network-byte-order format.

The entry(ies) go(es) to the authoritative DNS-server which is not necessarily your (internal) DNS-server.

The purpose of the entries (of the public hosts or network ranges) in the zone file is to introduce your caching server and then redirect any of the service queries (e.g. updates) of the other hosts to your caching server.

Rough example:

  1. Your public host             ---update request-->                            Apple Update Server
  2. Apple Update Server      ---reverse DNS look up--->                 auth. DNS server
  3. Auth. DNS server            ---domain name/_aaplcache._tcp---> Apple Update Server
  4. Apple Update Server      - determines the responsible caching server
  5. Apple Update Server      ---sends public ip of caching server---> your public host
  6. Your public host             ---update request-->                            your caching server
klanomath
  • 66,391
  • 9
  • 130
  • 201
  • Well said, I wasn't keen on the DNS aspect, but this makes total sense after using the server for a few years. – bmike Nov 29 '15 at 17:00
0

In a nutshell, here's how I explain the caching server to clients:

  1. Each iOS and Mac device checks in with Apple's servers for some cloud activity like storing iCloud assets and downloading iCloud assets, App store downloads, software updates and downloads.
  2. The server.app also checks in to Apple's servers and asks to cache content based on the settings.
  3. Everything works well if you have an internal/non-routable IP address and a small network with the default settings
  4. You need some DNS glue if your server is only/primarily reachable by a public IP address so that the iOS and Mac clients can know to contact the "local" caching server even though from a strict networking subnet sense, the server isn't actually "local" compared to the IP address of the requesting client.

Some related threads which may or may not have good answers are:

Empirically, you can use test devices to delete and reinstall apps on various subnets and tail the caching server log files to see that a request was seen by the caching server. Again, not all request empirically hit the caching server. I have two servers set up in my "test" environment and I see success rates of 60 to 80% most requests on most days. My thinking is that load issues, timeouts, lost packets and such account for the "failures" to utilize the caching server, but on the whole, I save gigabytes of traffic a day and sometimes far, far more traffic on update days and when clients use iCloud Photo Library - some times setting up a new device hits the cache server almost exclusively for a pleasant experience once the content is cached locally.

You'll probably want to dig in to the command line options, though if you run server.app on anything but a flat network segment.

Community
  • 1
bmike
  • 235,889