La ricerca DNS di Mac OS X sembra essere incasinata, ma solo al lavoro

Le ricerche DNS di Mac OS X richiedono per sempre Safari e altre applicazioni che utilizzano mDNSResponder. Le stesse ricerche funzionano bene se utilizzo nslookup dalla riga di comando e funzionano anche dal mio iPhone e iPad sulla stessa rete wireless.

E questo è solo sulla rete al lavoro; quando sono a casa o legato al mio iPhone, tutte le ricerche DNS funzionano bene. Quando sono in rete al lavoro, tramite Wi-Fi o Ethernet, ho questi problemi. Ho provato ad usare i seguenti comandi:

launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Questo era solito fornire un sollievo temporaneo (minuti) sotto Snow Leopard, ma ora, sotto Lion, di solito non fornisce nulla.

Né le mie impostazioni Ethernet né Wi-Fi specificano i server DNS; vengono compilati automaticamente dal router. Ma ho provato a specificare il mio, come Google DNS o OpenDNS, e questo non risolve il problema.

La configurazione di rete è un router collegato al modem via cavo, con tutte le porte Ethernet dell'ufficio che ne escono. Un router wifi Airport Extreme è anche collegato al router principale (in modalità bridge) e i client WiFi si connettono a quello.

Ho cercato dappertutto e trovato altre cose che sembrano applicabili all'inizio (ad esempio, la ricerca DNS non riesce ma nslookup funziona ), facendomi pensare che questi problemi di mDNSResponder non sono troppo rari, ma nessuno di questi corrisponde esattamente e le loro soluzioni non hanno ha funzionato ancora per me.

Inoltre: non è ogni ricerca DNS, solo la maggior parte. Le ricerche di Google arrivano all'istante, ma Google Maps impiega un'eternità a caricarsi (quando guardo la finestra delle attività, di solito sono gli script e tutto ciò che non proviene da alcuni server CDN di Google). Anche i siti che utilizziamo ogni giorno e che potresti pensare che verrebbero memorizzati nella cache da qualche parte (come php.net) impiegheranno un'eternità a caricarsi o a scadere.

Inoltre: tutto si carica bene da un browser all'interno di una macchina virtuale Windows XP, che per me indica ancora più accusatamente mDNSResponder come colpevole, ma tutto funziona bene quando sono un'altra rete.

Il motivo per cui il DNS è lento in ufficio ma non a casa, potrebbe essere che il router dell'ufficio utilizza IPv6 ma il router di casa utilizza IPv4 e Lion utilizza meglio IPv6 rispetto a Snow Leopard. I siti Web che non sono interessati da quel rallentamento sono quindi probabilmente quelli che hanno un supporto migliore per IPv6.

Vedi questo articolo per le misure che mostrano che IPv6 è 2-3 volte più lento di IPv4 su DNS:
IPv6 ti rallenterà (DNS)

In tal caso, la disabilitazione di IPv6 sul router dell'ufficio (e così su tutta la rete dell'ufficio) potrebbe risolvere il problema.

Questo articolo potrebbe anche essere utile: Come disabilitare IPv6 su Mac OS X 10.7 Lion .

Avevo lo stesso problema con il mio MacBook Pro in esecuzione 10.6. Raramente spengo mai la mia macchina. Praticamente a casa chiudo il coperchio e lo metto nella mia borsa e lo porto al lavoro. Al lavoro apro il coperchio e vado via. Quello che ho notato è che OS X non sembra fare questa transizione nel modo più semplice possibile. Avrei DNS lento, grandi quantità di risorse di rete in attesa, ecc. Ciò che lo risolve per me è disconnettermi manualmente da ciascuna rete prima di chiudere la mia macchina (cioè spegnere l'aeroporto prima di chiudere il coperchio). Se non lo faccio, il mio standby è:

dscacheutil -flushcache

In entrambi i casi funziona abbastanza bene per me. In una rara occasione, riavvio la macchina.

Gli altri Mac funzionano correttamente sulla rete dell'ufficio?

Assicurarsi che le impostazioni di rete assegnate siano coerenti. Ho visto la situazione in cui un server DHCP stava assegnando un gateway predefinito che non si trovava nella sottorete del client. Windows è andato avanti e lo ha usato, e ha funzionato bene, ma MacOS (correttamente!) Ha rifiutato di inviare a un indirizzo IP che non era sulla sottorete.

Quando la subnet mask viene applicata sia all'indirizzo IP del client sia al gateway predefinito, i risultati dovrebbero essere uguali. Altrimenti, è una configurazione errata del server DHCP.

Questo non suona esattamente come quella situazione. Il tuo Mac è configurato per utilizzare sia WiFi che Ethernet al lavoro? In tal caso, prova a disattivarne uno alla volta.