servidor - sockets en java pdf
En Linux, Java emite búsquedas DNS inversas cuando se abre un socket. ¿Por qué y cómo puedo detenerlo? (2)
Las búsquedas DNS inversas las realiza SecurityManager, y no puede deshabilitarlas.
Estamos experimentando un comportamiento bastante extraño en Linux wrt Java DNS búsquedas (actualización: sucede también en Mac OS X-I estaba equivocado).
Configuramos el servidor DNS público de Google 8.8.8.8 como el servidor DNS de JVM. El servidor del sistema (/etc/resolv.conf), sin embargo, permanece fuera del servidor estándar ghost.di.unimi.it.
Cuando se busca una dirección usando InetAddress.getAllByName () o Addess.getAllByName () de DNSJava, todo funciona como se espera (en particular, esto es DNSJava):
01:39:11.832438 IP nexus.law.di.unimi.it.33195 > google-public-dns-a.google.com.domain: 46509+ A? www.uffa.com. (30) 01:39:11.832820 IP nexus.law.di.unimi.it.52782 > ghost.di.unimi.it.domain: 42740+ PTR? 8.8.8.8.in-addr.arpa. (38) 01:39:11.833510 IP ghost.di.unimi.it.domain > nexus.law.di.unimi.it.52782: 42740 1/2/0 PTR google-public-dns-a.google.com. (128) 01:39:11.865165 IP google-public-dns-a.google.com.domain > nexus.law.di.unimi.it.33195: 46509 1/0/0 A 208.87.35.103 (46)
Como puede ver, resolvemos www.uffa.com, y luego hay una búsqueda inversa (solo ocurre una vez en la primera búsqueda) de 8.8.8.8 para fines de autenticación. En este punto, la dirección IP de www.uffa.com se almacena en caché y no debe haber búsquedas si realizamos otra llamada dentro del TTL.
Sin embargo, cuando realmente intentamos abrir un socket en www.uffa.com utilizando DefaultHttpClient del componente HTTP de Apache, vemos esto:
01:40:06.892383 IP nexus.law.di.unimi.it.53977 > ghost.di.unimi.it.domain: 22255+ PTR? 103.35.87.208.in-addr.arpa. (44) 01:40:07.204359 IP ghost.di.unimi.it.domain > nexus.law.di.unimi.it.53977: 22255 1/2/2 PTR 208-87-35-103.securehost.com. (154)
Es decir, Java (u otra cosa en la máquina) está realizando una búsqueda inversa de la dirección de www.uffa.com en nuestro servidor del sistema , en lugar de en el servidor de Google. Lo mismo ocurre con URL.openConnection (). GetContent ().
Usamos BTrace para instrumentar el código InetAddress / Address, y no se realizaron llamadas que pudieran implicar una búsqueda de DNS inversa.
Francamente, ni siquiera sabemos qué buscar.
Nuestro gran problema es que estamos escribiendo un rastreador de alto rendimiento, y aunque tratamos de controlar cuidadosamente las búsquedas de DNS, no hay nada que podamos hacer para acelerar estas búsquedas inversas porque se realizan cuando se abre el socket, lo que sucede al rastrear hilos cuyo número está en miles.
Una información adicional, wget realiza una búsqueda DNS inversa, también, pero una nc en el puerto 80 (que por supuesto no da nada) no lo hace.
Como de costumbre, cualquier ayuda es apreciada.
Al final, el único problema real era que no le estaba dando a tcpdump la opción -n. La búsqueda inversa que estaba observando era solo de tcpdump.