OS X no consulta los nombres DNS locales correctamente

Ninguna de nuestras máquinas cliente OS X en nuestro lugar de trabajo consulta correctamente los nombres DNS locales de nuestros servidores después de conectarse a VPN. Para otras máquinas cliente, incluidas Linux y Windows, funciona correctamente.

Solo un poco de contexto: nuestros servidores eran accesibles públicamente antes. Dado que comenzamos a asegurar todo, procedemos a ponerlos detrás de un firewall y solo se puede acceder a ellos a través de VPN. Dado que nuestros desarrolladores están acostumbrados a acceder a los servidores a través de fqdn, agregamos un servidor DNS local. Entonces, cuando se conectan a nuestra VPN, la configuración de DHCP + DNS se pasará a sus máquinas automáticamente. Dos direcciones IP de servidor DNS, una para resolución local y otra para resolución pública. Desafortunadamente, todos nuestros usuarios de OS X están experimentando estos problemas. Las máquinas Linux y Windows no lo son.

Servidor: riker.ejemplo.com

• 120.xxx (dirección IP pública)
• 10.20.1.28 (dirección IP local)

Configuración de DNS que se pasa a nuestros usuarios:

• 10.20.1.3 (para locales)
• 8.8.8.8 (para público)

Ya hemos comprobado:

• Configuración del servidor DNS de nuestro dispositivo Fortigate: estamos 100% seguros de que es correcta porque nuestros clientes Linux y Windows están funcionando.
• Políticas de firewall: nuevamente, 100% seguro porque funciona correctamente con Linux y Windows
• Verifique los archivos /etc/resolv.conf de las máquinas OS X: configuración de DNS correcta proporcionada por el servidor DNS [editar el 6 de junio de 2016]
• Caché de DNS vaciado usando esto:sudo killall -HUP mDNSResponder
• Apagó el firewall de las máquinas OS X
• Respondedor mDNS reiniciado

Después de todos estos pasos de solución de problemas, todavía no funciona.

Si estoy conectado a VPN, todavía está resolviendo la dirección IP pública y no la dirección IP local:

heineken:~ heineken$ ping riker.example.com
PING riker.example.com (120.x.x.x): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- riker.example.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
heineken:~ heineken$

Pero si hago ping a la dirección local:

heineken:~ heineken$ ping 10.20.1.28
PING 10.20.1.28 (10.20.1.28): 56 data bytes
64 bytes from 10.20.1.28: icmp_seq=0 ttl=63 time=62.714 ms
64 bytes from 10.20.1.28: icmp_seq=1 ttl=63 time=83.162 ms
^C
--- 10.20.1.28 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 62.714/72.938/83.162/10.224 ms

Comprobación por excavación y nslookup (todavía conectado a VPN):

heineken:~ heineken$ dig @10.20.1.3 riker.example.com
 
; <<>> DiG 9.8.3-P1 <<>> @10.20.1.3 riker.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64601
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;riker.example.come. IN A
 
;; ANSWER SECTION:
riker.example.com. 3600 IN A 10.20.1.28
 
;; Query time: 58 msec
;; SERVER: 10.20.1.3#53(10.20.1.3)
;; WHEN: Fri Jun 10 11:33:00 2016
;; MSG SIZE  rcvd: 52
 
heineken:~ heineken$ nslookup riker.example.com
Server: 10.20.1.3
Address: 10.20.1.3#53
 
Non-authoritative answer:
Name: riker.example.com
Address: 10.20.1.28

Contenido de /etc/resolv.conf de la máquina local (todavía conectado a VPN):

heineken:~ heineken$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 10.20.1.3
nameserver 8.8.8.8

Como puede ver arriba, al hacer ping al dominio, aún se muestra la dirección IP pública y no la dirección IP local. Pero con dig y nslookup, ya está dando la dirección IP local.

Algunas cosas más que hice:

• Probé las soluciones presentadas desde aquí: DNS no se resuelve en Mac OS X , todavía no funcionó para nosotros.
• Instalé una máquina virtual CentOS, dentro de una máquina OS X y la hice para tener una conexión de puente. Estaba resolviendo correctamente el dominio localmente.
  • Esto significa que Forticlient puede eliminarse de la ecuación ya que OS X y CentOS VM simplemente comparten el mismo adaptador.
• Buscó soporte L3 de Fortigate
  • Hicimos mucho tcpdump en el dispositivo Fortigate para verificar el tráfico.
    • Descubrimos que cuando una máquina Linux o Windows hace ping a un dominio, primero busca una solicitud de DNS desde el dispositivo Fortigate.
    • Desafortunadamente para la máquina OS X, no realiza ninguna solicitud de DNS desde el dispositivo Fortigate. Entonces, lo que sucede es que todavía se resuelve en el dominio público.
  • Me informaron que el problema está localizado en los dispositivos OS X porque incluso después de vaciar el caché, no realiza ninguna consulta de DNS al hacer ping en riker.example.com. Así que ya no pueden ayudarnos.

Esto se probó en: Versiones de OS X: Yosemite 10.10.4, El Capitan 10.11.5 Fortigate 100D Versión de firmware: v5.2.4,build688 (GA) Versión de Forticlient: 5.4.0.493

¿Algún consejo?