They also say the domain needs to be in your domain search field on your end user device, meaning I think the enduser device looks up whatever default hostname, appending whatever domain name is in your client. Your authoritative DNS then returns the IP of your Apple cache. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: nanog@nanog.org Sent: Monday, September 18, 2017 12:11:22 PM Subject: Re: IOS new versions and network load On 2017-09-18 08:48, Mike Hammett wrote:
It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a lot easier to implement.
I would have to read the stuff again, but my understanding is: caching server starts. caching server registers with Apple, gives it its local IP, as well as the IP ranges that it manages. When a client wants something, it first reaches out to an Apple server. That server decides which content server is nearest to the client, and if there is a caching server in the same network, will give the client the IP address to access that local caching server. (and this is where there is NAT friendliness , as other have pointed out, designed mostlty for enterprise). The business about TXT records is to allow real IPs with multiple ranges to be used. I *assume* that it is the caching server which reads those records upon startup and then transmits it to Apple when it "logs in" as a caching server. You can have up to 24 chained TXT records to list all the IP blocks you can service.