-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-02-15 a las 23:03 +0100, Carlos E. R. escribió:
Porque a ellos no les han cortado el paso en korelogic.
¿Por qué no me funciona con bind? Estoy en la red de T. pero sin usar sus servidores dns.
No señor.
(recorto la historieta para niños...) :-P
Ni tu ni yo podemos en manera alguna saber si las máquinas con los DNS de telefónica tienen problemas, o si alguien les tiene manía en korelogic y les cierra el paso. Eso, en justicia, no lo puedes saber. Lo único que sabemos es que el servidor DNS de telefónica se queja de que no puede llegar hasta ns?.korelogic.com.
Mira:
*** linux:~ # traceroute 63.238.77.253 traceroute to 63.238.77.253 (63.238.77.253), 30 hops max, 40 byte packets
(saltos 1 y 2 eliminados a propósito)
12 fw-dmz.theaimsgroup.com (63.237.12.11) 191.505 ms 187.523 ms 185.802 ms ***
Una traza a la IP "sale" al menos de España.
No es la IP del DNS, que es la que falla.
*** linux:~ # traceroute marc.info marc.info: Temporary failure in name resolution ***
Una traza a la dirección falla.
Es demasiado sospechoso, Carlos.
No, no me vale. No sacas las conclusiones correctas de las pistas existentes. A ver, la orden traceroute falla porque antes falla un paso previo, que es la resolución de nombres, y no se llega a hacer el trazado.
Puedes hacer una apuesta y decir que piensas que Telefónica ha metido la pata. Pero no lo puedes saber cierto. Y yo puedo hacer otra apuesta y decir que el culpable es korelogic. Tampoco lo puedo saber cierto.
Lo que es cierto es que cambiando de servidor DNS, el problema desaparece.
Sí, pero no sabes si el problema es del camionero español, del francés, o de la gendarmeríe o de la guardia civil. Vamos a ver, lo que sabemos hay un problema con la resolución de nombres cuando el servidor de nombres está en tesa, aunque el servidor de nombres no sea de tesa. En una de las pruebas se vio que el servidor de korelogic no respondía. Cuando tú hacías "dig marc.info +trace", llegaba un momento en que el servidor dns del dominio padre info te respondía cual era el servidor DNS responsable de "marc.info", es decir "ns1.korelogic.com". Hasta ahí, bien. El siguiente paso es preguntarle a "ns1.korelogic.com", y es éste el que no te responde: marc.info. 86400 IN NS ns1.korelogic.com. marc.info. 86400 IN NS ns2.korelogic.com. ;; Received 76 bytes from 199.254.31.1#53(A0.INFO.AFILIAS-NST.info) in 169 ms ;; connection timed out; no servers could be reached Esa ultima frase quiere decir que ni ns1 ni ns2 de korelogic le responden - - y no te confundas, no le estás preguntando al DNS de telefónica. En absoluto: estás preguntando directamente al servidor DNS donde está registrado el dominio marc.info, y es a tí a quien no responden. Lo que se intentaba hacer con el traceroute a la ip de ns1.korelogic.com es ver donde se detiene la consulta. Y no está claro.
Lo que sí podemos quejarnos es que no hay una interfaz para preguntarle a Telefónica por estos problemas, y tener una respuesta que no sea dada por un florero con libro de recetas. Eso SÍ que es culpa de Telefónica. No tenemos a quien denunciar estas cosas y que nos digan donde está realmente el problema y lo solucionen.
Telefónica tiene una dirección de correo para estos temas. Puedes escribir...
Nunca la he encontrado, o si lo hice no me respondieron. La ultima vez llamé a varios teléfonos. Al final llegué a uno, y me decían que como el problema no era de configuración del outlook ni del webmail, que no podían hacer nada. Y el problema era que los correos hacia a mí de cierta IP alemana no llegaban. Nada que ver con los clientes de correo.
Mira, otro caso.
Estando yo trabajando con una compañía telefónica (que no era Tesa) resultó que nos llegó la noticia de que era imposible llamar a Cuba via Telefónica, pero sí era posible si nos contratabas a nosotros. ¿Porqué? Bueno, pues la cuestión era que Telefónica tenía el contrato para llegar a Cuba vía USA, y estos cerraron el paso por su boicot. Telefónica no tenía la culpa, pero se la echaban. Nosotros llegabamos porque íbamos por otro pais (¿Canadá? ¿centroamérica?), o entrabamos a USA a través de otro país al que los usanianos miraban mejor. Casualidad.
Casualidad, no. Estaba documentado y sabíais lo que pasaba y porqué.
¿Documentado? No me hagas reír. Funcionaba por casualidad, normalmente era al revés. Mira, otro ejemplo, de lo más peculiar. Un cliente se quejaba de que no podía llamar a cierto número extranjero. Lo probamos, y era cierto, no se podía, daba "avería". Era Afganistán. Le pasamos el marrón a nuestro proveedor internacional, porque comprobamos que la llamada salía de España. Bastante tiempo más tarde, meses, llegó la respuesta: el servicio internacional directo con Afganistán está cortado. Los talibanes sólo dejan llamar a ciertos números autorizados, el resto se fastidia y tiene que llamar vía operadora manual; y si le caías bien y autorizan la llamada, pasas. ¿Documentado? Venga ya. No sabíamos nada. Como nosotros estábamos "dentro", nos enterábamos de la causa real de los problemas, al tiempo. Y por cierto: había muchos problemas que eran culpa de Telefónica, y cuando nosotros les mandábamos el aviso lo resolvían muy rápidamente. Los lentos eramos nosotros. La interfaz de notificación entre operadores con Telefónica funcionaba bastante bien; lo que siempre ha ido mal con Tesa es cuando el problema lo notifica un cliente, que no le hacen ni caso. Los clientes hablan con floreros, mientras que los proveedores hablábamos con los profesionales de verdad, que son muy competentes, por cierto. Mi trabajo, por cierto, era determinar de quien podía ser la culpa y a quien le pasábamos el marrón. Y se me daba bastante bien, solía acertar. Y conservo la bola de cristal desde entonces >:-) El procedimiento en este caso sería pasarle el marrón a Tesa para que averigüen donde está el problema, en su red o en la de otro.
No es via web. Y no sé explicarte cómo hacerlo, no lo he visto hacer y no se como se hace.
Ya tengo la prueba de "dónde" falla, el resto de pruebas no nos llevaría a otra conclusión de la que ya tenemos.
No, no la tienes. Tienes la causa aparente nada más.
No sabes si el proveedor de USA le ha puesto la zancadilla o alguien ha tirado una ruta.
Ya... >:-)
Es sospechoso, pero no es prueba. A mi se me "para" en verizon, pero en realidad hay más nodos que me sueltan asteriscos, y sin embargo, el paquete pasa por ahí.
No tengo motivos para pensar que el servidor dns de marc.info no quiera contestar peticiones de la red de Telefónica, se me hace un poco extraño, la verdad.
A mi no. Tampoco hay motivos para pensar que Telefónica te corte a tí (y a mí no) las peticiones de nombres al DNS de determinada empresa. ¿Para qué? Una manera que existe de restringir el tráfico proveniente de una red "pesada" es no resolver sus peticiones de nombres, y así no te llega el tráfico sin necesidad de poner un tremendo cortafuegos en el backbone: lo pones en el acceso al servidor de nombres tan sólo. Y eso ha pasado muchas veces. Es como cuando pones en el postfix una restricción para no aceptar correos de la China, salvo que en vez de en el cortafuegos lo haces en el DNS, y así cortas todo, web, ftp, mail... hasta los pings. Sin tocar el cortafuegos, que tiene mucho tráfico. Si te protestan, puedes demostrar que no has cortado el paso, haciendo pings contra la IP delante del protestón. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYt6kACgkQtTMYHG2NR9ULCQCaApF0v3DaILpn9oTetdLYmiDi rswAn1KGszKA3JMmvqhcR6JSE4ZPzUqI =teI1 -----END PGP SIGNATURE-----