OS X Server Caching / DNS Question

Leyendo las ayuda supongo que prs significa p ublic r ange comma s eparated y prn significa p ublic r ange binary n en formato de orden de bytes de red.

La (s) entrada (s) va (n) al servidor DNS autoritario que no es necesariamente su servidor DNS (interno).

El propósito de las entradas (de los hosts públicos o rangos de red) en el archivo de zona es introducir su servidor de almacenamiento en caché y luego redirigir cualquiera de las consultas de servicio (por ejemplo, actualizaciones) de los otros hosts a su servidor de almacenamiento en caché.

Ejemplo aproximado:

1. Su host público --- solicitud de actualización - > Apple Update Server
2. Apple Update Server --- búsqueda DNS inversa --- > aut. Servidor DNS
3. Aut. Servidor DNS --- nombre de dominio / _aaplcache._tcp --- > Apple Update Server
4. Apple Update Server: determina el servidor de almacenamiento en caché responsable
5. Apple Update Server --- envía una ip pública del servidor de almacenamiento en caché --- > tu anfitrión público
6. Su host público --- solicitud de actualización - > su servidor de almacenamiento en caché

En pocas palabras, así es como explico el servidor de almacenamiento en caché a los clientes:

1. Cada dispositivo iOS y Mac registra en los servidores de Apple alguna actividad en la nube, como almacenar los activos de iCloud y descargar los activos de iCloud, las descargas de la tienda de aplicaciones, las actualizaciones de software y las descargas.
2. El server.app también se registra en los servidores de Apple y le pide que almacene en caché el contenido según la configuración.
3. Todo funciona bien si tiene una dirección IP interna / no enrutable y una red pequeña con la configuración predeterminada
4. Necesitas algo de pegamento de DNS si tu dirección IP pública solo puede acceder a tu servidor para que los clientes de iOS y Mac puedan comunicarse con el servidor de almacenamiento en caché "local", aunque desde un sentido de subred de red estricto, el servidor no está en realidad no es "local" en comparación con la dirección IP del cliente solicitante.

Algunos temas relacionados que pueden o no tener buenas respuestas son:

• ¿Puede saber si las actualizaciones provienen del servidor de almacenamiento en caché de OS X?
• ¿Hay alguna forma de detectar servidores de almacenamiento en caché?

Empíricamente, puede usar dispositivos de prueba para eliminar y reinstalar aplicaciones en varias subredes y seguir los archivos de registro del servidor de almacenamiento en caché para ver si el servidor de almacenamiento en caché vio una solicitud. Una vez más, no todas las solicitudes golpean empíricamente el servidor de almacenamiento en caché. Tengo dos servidores configurados en mi entorno de "prueba" y veo tasas de éxito de 60 a 80% de la mayoría de las solicitudes en la mayoría de los días. Mi idea es que los problemas de carga, los tiempos de espera, los paquetes perdidos y la cuenta de los "fallos" de utilizar el servidor de almacenamiento en caché, pero en general, guardo gigabytes de tráfico al día y, a veces, mucho más tráfico en los días de actualización y cuando los clientes use iCloud Photo Library: algunas veces, la configuración de un nuevo dispositivo llega al servidor de caché casi exclusivamente para una experiencia agradable una vez que el contenido se almacena en caché localmente.

Es probable que desees profundizar en las opciones de la línea de comandos, aunque si ejecutas server.app en algo que no sea un segmento de red plano.