La actualización de Parallels Desktop 5 a 6 provocó "lentitud" en la resolución de consultas de DNS en el nivel de Mac OS X

¿Alguien más siente esto/tiene alguna idea de cómo solucionarlo sin reinstalar Snow Leopard? Esto parece muy similar a los problemas que solía tener PD en 2008 ( enlace del foro )

FWIW, mis interfaces de red actuales son:

$ ifconfig -l
lo0 gif0 stf0 en0 en1 fw0 vnic0 vnic1 vmnet1 vmnet8

(Y sí, como puede ver en las NIC, también ejecuto VMWare Fusion 3.1.1, pero el problema comenzó al actualizar a PD6)

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
 inet 127.0.0.1 netmask 0xff000000
 inet6 fd18:d7ce:18ee:1e60:223:32ff:fea0:fade prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether HH:II:DD:DD:EE:NN
 media: autoselect
 status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether HH:II:DD:DD:EE:NN
 inet6 HH:II:DD:DD:EE:NN%en1 prefixlen 64 scopeid 0x5
 inet 192.168.0.198 netmask 0xffffff00 broadcast 192.168.0.255
 media: <unknown subtype>
 status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
 lladdr 90:84:0d:ff:fe:ba:6d:2a
 media: autoselect <full-duplex>
 status: inactive
vnic0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:1c:42:00:00:08
 inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
 inet6 fe80::21c:42ff:fe00:8%vnic0 prefixlen 64 scopeid 0x7
 inet6 ::1 prefixlen 64
 media: autoselect
 status: active
vnic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:1c:42:00:00:09
 inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
 inet6 fe80::21c:42ff:fe00:9%vnic1 prefixlen 64 scopeid 0x8
 inet6 ::1 prefixlen 64
 media: autoselect
 status: active
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:50:56:c0:00:01
 inet 172.16.155.1 netmask 0xffffff00 broadcast 172.16.155.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:50:56:c0:00:08
 inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255

$ cat /etc/resolv.conf
nameserver 208.67.220.220
nameserver 208.67.222.222
¿Puede publicar la salida de su ifconfig y la salida de: cat /etc/resolv.conf (en Terminal.App, por supuesto)

Respuestas (1)

Comience haciendo algunas pruebas en su Terminal:

  1. Use nslookup e intente buscar ciertas cosas (www.google.com, www.ibm.com, etc.) Vea cómo funciona desde allí.

  2. Use 'cavar' (otro comando) para hacer lo mismo. Dig será mucho más detallado y le mostrará más información sobre la búsqueda en sí.

  3. Asegúrese de que sus DNS sean correctos en /etc/resolv.conf (pruebe con Google 8.8.8.8 si no está seguro).

  4. Revise su consola para ver posibles mensajes relacionados con adaptadores de red o bucles en curso.

Editar: Todo parece "normal". ¿Utiliza redes compartidas? ¿Puedes intentar deshabilitar vnic0 y vnic1 (esos son los paralelos). Recuerdo haber tenido problemas de lentitud (en paralelos 3.x) que solucioné usando Bridged Networking en lugar de compartir. ¡No pensé que el problema siguiera siendo un problema unos años después!

1 y 2) A veces se resuelve de inmediato, otras veces apesta como el infierno. Eso es lo que es tan desconcertante. De hecho, ejecuté los comandos "time nslookup" y "time dig" y obtuve un comportamiento extraño. 3) Mis servidores DNS son definitivamente correctos. Uso OpenDNS porque quiero que Google al menos no sepa todos mis hábitos pornográficos. 4) Veo algunos mensajes raros de kernel.log con información de VMWare... (vmnet: VMNET_SO_BINDTOHUB: port: paddr vmnet: bridge-en1: media 80 dev 0x89f2404 family 2vmnet: Invalidating peer info for hub: 0, port: 0vmnet: VNetUserIfFree: liberando userIf en 0x9e8df00.) Tendré que investigar esto más. ¡Gracias!
Yo también uso OpenDNS, así que intente deshabilitar todos los adaptadores virtuales proporcionados por Parallels y VMWare y comience uno por uno. Las redes en puente generalmente funcionan mejor (para mí) ya que crean un adaptador "real" (virtual de todos modos) y no interfieren con la creación de una "red privada" entre su Mac y sus máquinas virtuales.