-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-02-16 a las 01:47 +0100, Carlos E. R. escribió:
No es la IP del DNS, que es la que falla.
Claro. Y si le pido a otro servidor que resuelva, lo hace correctamente.
Claro, porque no lo han vetado.
Youtube, marc.info... ¿quién es el elemento común en ambos casos? Telefónica.
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.
Las conclusiones se extraen de simples deducciones. Y Telefónica siempre está en medio. En cuanto se elimina el factor T, se elimina el problema.
Doctor, me duele el dedo. Vale, te quito el brazo.
Verás, yo no pago a Youtube ni a marc.info, sino a Telefónica >:-)
Vale, eso si. Telefonica tiene obligación de intentar resolver el problema, pero no podemos saber que Telefonica sea la provocante del mismo. Puede ser la víctima. Eso es como si mando un paquete por correos a Alemania, y se pierde, porque los correos alemanes están de huelga. En cambio si lo mando por UPS llega. No es culpa de correos de España, pero yo les tengo que protestar a ellos para que lo resuelvan.
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.
"Sé" quien me genera el problema >:-)
No, no lo sabes.
;; 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.
A mi y a unos cuantos millones de clientes más...
Claro.
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.
Está claro que tiene un problema con Telefónica.
Y dale.
Nunca la he encontrado, o si lo hice no me respondieron.
Claro... nunca aceptan los errores hasta que es tan evidente que tienen que hacerlo.
Que te crees tu eso. En la interconexión donde yo trabajaba lo hacían continuamente, y por escrito. "Es problema nuestro". "Es problema vuestro". "Es problema del cliente". Muchas resoluciones las reconocían como problema de ellos, y repito, por escrito. Otra cosa es que se lo digan al cliente. Es la atención al cliente donde fallan.
¿Documentado? No me hagas reír.
Funcionaba por casualidad, normalmente era al revés.
Pero lo sabíais quienes teníais que saberlo. Suficiente.
Que no, que no lo sabíamos. Teníamos que mandar el problema por escrito al proveedor internacional, el cual se podía tomar meses en respondernos.
Como nosotros estábamos "dentro", nos enterábamos de la causa real de los problemas, al tiempo.
Pues eso.
Pues eso mismo. Ni tu ni yo estamos en Telefónica internet, y no podemos hacer catas de tráfico para ver si las peticiones al ns1.korelogic.com llegan a salir de España o no.
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 >:-)
Dame pruebas de la culpabilidad del otro.
Dámelas tú del tuyo. No las tienes, haces una suposición. Igual que yo, hago una suposición, pero distinta. Ninguno de los dos tenemos pruebas para ganar un juicio.
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.
Lo cual es lo más normal... no querrás que lo averigüe el cliente :-)
Claro que no. Pero es distinto quejarte a tu proveedor para que resuelva un problema, sea suyo o no, puesto que es su trabajo resolver esos problemas, que directamente acusarles de ser los culpables del problema sin pruebas.
No, no la tienes. Tienes la causa aparente nada más.
Tengo el "tapón" que me impide el acceso. Si quito el "tapón", entro.
El aparente. Eliges otra tubería y funciona, pero no sabes si la tubería está tapada en España o en USA. Tú simplemente le echas las culpas al lado Español.
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é?
A ver, que Telefónica no corta de manera interesa, tiene un problema, nada más. La diferencia está que vamos por canales diferentes.
Repito: tú tampoco resuelves ese dominio usando un dns concreto de Telefónica.
Claro que no, porque ese DNS tiene las peticiones vetadas por korelogic.
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.
No es el caso. No para un servidor dns. No creo que ningún administrador en sus cabales configure sus equipos para rechazar (de manera interesada) peticiones de un ISP en concreto a su servidor dns, y menos tratándose de un servidor de listas de correo.
No es el servidor de las listas (marc.info) el que cierra, es el dns que tienen contratado en korelogic. Y sí, se han dado casos anteriores de que un servidor hace ese tipo de bloqueos. Me ha pasado. Había uno que no respondía a las consultas DNS de países sin importancia. Sólo antendía a los usanianos, ingleses, franceses... Si intentabas entrar desde sudamerica, no resolvía. Porque le daba la gana. Lo comentaron en estas listas hace unos cuantos años. Jolines, una técnica parecida es la que usan los de opendns para ejercer el control parental... Las IPs retringidas no resuelven o lo hacen a una IP de control, dependiendo de quien es el cliente que hace la consulta DNS. Me parece que a Juan le pasó no hace mucho, por un comentario que puso. De esa forma no tienen que poner grifos en el router ni nada, sólo gestionan el DNS de consulta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZSxQACgkQtTMYHG2NR9V9LQCfWckHQXG7W8v3klvfsidBZ9/u 6tMAnA0ZVQMvnQN3ZP3E+v7j0M1bCfPI =O5io -----END PGP SIGNATURE-----