OS X неправильно запрашивает локальные DNS-имена

Ни один из наших клиентских компьютеров OS X на нашем рабочем месте не запрашивает локальные DNS-имена наших серверов после подключения к VPN. Для других клиентских машин, включая Linux и Windows, все работает правильно.

Просто некоторый контекст: наши серверы раньше были общедоступны. Поскольку мы начали все защищать, мы продолжаем размещать их за брандмауэром, и они доступны только через VPN. Поскольку наши разработчики привыкли обращаться к серверам через fqdn, мы добавили локальный DNS-сервер. Поэтому, когда они подключаются к нашей VPN, настройки DHCP + DNS будут автоматически передаваться на их машины. Два IP-адреса DNS-сервера, один для локального разрешения и один для публичного разрешения. К сожалению, все наши пользователи OS X сталкиваются с этими проблемами. Машины Linux и Windows - нет.

Сервер: riker.example.com

• 120.xxx (общедоступный IP-адрес)
• 10.20.1.28 (локальный IP-адрес)

Настройки DNS, которые передаются нашим пользователям:

• 10.20.1.3 (для местных)
• 8.8.8.8 (для публики)

Мы уже проверили:

• Настройки DNS-сервера нашего устройства Fortigate — мы на 100% уверены, что они верны, потому что наши клиенты Linux и Windows работают.
• Политики брандмауэра — опять же, на 100 %, потому что они корректно работают с Linux и Windows.
• Проверьте файлы /etc/resolv.conf на компьютерах с OS X - исправьте настройки DNS, заданные DNS-сервером [изменить 6 июня 2016 г.]
• Сброс кэша DNS с помощью этого:sudo killall -HUP mDNSResponder
• Отключен брандмауэр машин OS X
• Перезапущен mDNSresponder

После всех этих шагов по устранению неполадок он все еще не работает.

Если я подключен к VPN, он по-прежнему разрешает общедоступный IP-адрес, а не локальный IP-адрес:

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$

Но если я пропингую локальный адрес:

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

Проверка с помощью dig и nslookup (все еще подключен к 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

Содержимое /etc/resolv.conf локальной машины (все еще подключенной к 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

Как вы можете видеть выше, при проверке связи с доменом он по-прежнему выдает общедоступный IP-адрес, а не локальный IP-адрес. Но с dig и nslookup он уже выдает локальный IP-адрес.

Еще несколько вещей, которые я сделал:

• Пробовали решения, представленные здесь: DNS не разрешается в Mac OS X - у нас все еще не работает.
• Я установил виртуальную машину CentOS - внутри машины OS X и сделал так, чтобы у нее было мостовое соединение. Он правильно разрешал домен локально.
  • Это означает, что Forticlient можно исключить из уравнения, поскольку виртуальные машины OS X и CentOS просто используют один и тот же адаптер.
• Запросил поддержку L3 от Fortigate
  • Мы сделали много tcpdump на устройстве Fortigate для проверки трафика.
    • Мы обнаружили, что когда компьютер с Linux или Windows пингует домен, он сначала ищет DNS-запрос от устройства Fortigate.
    • К сожалению, для компьютера с OS X он не выполняет никаких DNS-запросов с устройства Fortigate. Итак, что происходит, так это то, что он по-прежнему разрешается в общественное достояние.
  • Они сообщили мне, что проблема локализована на устройствах OS X, потому что даже после очистки кеша он не выполняет никаких DNS-запросов при проверке связи с riker.example.com. Поэтому они больше не могут нам помочь.

Это было протестировано на: Версии OS X: Yosemite 10.10.4, El Capitan 10.11.5 Fortigate 100D Версия прошивки: v5.2.4, build688 (GA) Версия Forticlient: 5.4.0.493

Любой совет?