DNS funziona nel terminale ma non altrove in Mac OS

1

Ho un problema simile a quello in questa domanda: DNS non risolto su Mac OS .

Le cose su Internet funzionano bene. Le macchine locali nella mia azienda, tuttavia, non riescono a risolversi, compresi i server su cui sto lavorando.

Utilizziamo server DNS locali e le mie preferenze Network mostrano solo i server DNS locali. (192.168.20.10, 192.168.25.10)

Cercando di raggiungerli tramite hostname.companyname.local o hostname.companyname.com fallisce nelle app Mac OS (Safari, Firefox, Chrome, RDC, ecc.). Tuttavia, se uso dig o nslookup nel terminale, viene restituito correttamente:

dig hostname.companyname.local

; <<>> DiG 9.8.3-P1 <<>> hostname.companyname.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16841
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hostname.companyname.local.        IN  A

;; ANSWER SECTION:
hostname.companyname.local. 1200    IN  A   192.168.25.24

;; Query time: 3 msec
;; SERVER: 192.168.20.10#53(192.168.20.10)
;; WHEN: Thu Nov 20 11:36:49 2014
;; MSG SIZE  rcvd: 54

Quindi, perché funziona in Terminal e perché non funziona in Mac OS? (Usando Yosemite.) La risposta dal thread precedentemente collegato sul rimbalzo di mDNSResponder sembrava promettente, ma non sembra esistere in Yosemite.

    
posta flyingcheesehead 20.11.2014 - 18:46
fonte

3 risposte

1

Quando la tua rete locale è stata configurata con un nome di dominio che termina con .local , allora tutte le risoluzioni del nome host LAN interrogate da un Mac (~ 10.3-10.10) saranno passate a mDNS prima - bypassando unicast DNS!

Dig and nslookup sono utility DNS unicast, quindi ignoreranno entrambi l'ordine di risoluzione del nome host del sistema (files- > mDNS- > DNS) e interrogheranno direttamente unicast DNS.

Puoi risolvere questo problema modificando il nome del dominio locale per utilizzare un TLD diverso da .local .

Questo è molto comune in split-horizon DNS ed eterogenee ma reti aziendali dominate da Windows. Un sacco di amministratori di sistema di Windows sono utilizzati per .local TLD come nome TLD privato valido da almeno un decennio .

    
risposta data 20.11.2014 - 21:13
fonte
0

Perché funziona in Terminal e perché non funziona in Mac OS? La risposta alla tua prima parte è in man dig o man host :

The dig command does not use the host name and address resolution or the DNS query routing mechanisms used by other processes running on Mac OS X. The results of name or address queries printed by dig may differ from those found by other processes that use the Mac OS X native name and address resolution mechanisms. The results of DNS queries may also differ from queries that use the Mac OS X DNS routing library.

Per rispondere alla seconda parte, eseguirò una traccia di pacchetti e vedrò se i pacchetti di query stanno uscendo, e se sì, dove? tcpdump -i en0 -vnnt "udp port 53"

mDNS è per la scoperta di Bonjour; Non credo che abbia molto a che fare con il DNS standard, ma non citarlo su questo.

    
risposta data 20.11.2014 - 20:55
fonte
0

Abbiamo un problema simile in corso presso la nostra azienda. Per quanto ne sappiamo, sembra che per qualche motivo il sistema operativo smetta di aggiungere alcuni nomi host al dominio di ricerca predefinito.

Ho scritto un semplice script per correggerlo che cambia il dominio di ricerca predefinito su google.com, esegue il ping sull'host interessato (che non riesce), quindi cambia il dominio di ricerca predefinito nuovamente vuoto. Funziona ma non risolve la causa principale del problema. Questo script cambia solo l'impostazione per l'interfaccia wi-fi perché è tutto ciò di cui abbiamo bisogno, ti preghiamo di tenerlo a mente.

networksetup -setsearchdomains Wi-Fi google.com

sleep 3; ping hostname

sleep 3; networksetup -setsearchdomains Wi-Fi empty
    
risposta data 20.11.2014 - 21:33
fonte

Leggi altre domande sui tag