El 2009-02-14 a las 20:55 +0100, Carlos E. R. escribió:

cer@nimrodel:~> dig marc.info

;; SERVER: 192.168.1.12#53(192.168.1.12)

¿Esa es la IP del router? ¿Y cón qué dns resuelve el router?

El servidor que pones tu no responde.

Vale, eso es lo que quería saber. O sea, que es un error generalizado. Tampoco me resuelve utilizando el servidor dns 80.58.0.33

Ahora bien, si en el "/etc/named.conf" le dejo que pregunte primero al dns del adsl (automático), entonces tarda más, pero lo consigue:

¿Qué servidor dns tiene configurado el router?

Trae cuenta tener tu propio servidor DNS.

Tengo el named funcionando en los servidores, pero como forwarders usan los dns de Telefónica, así que, falla con esa dirección miserablemente :-( Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-14 a las 22:09 +0100, Carlos E. R. escribió:

Ni idea, es dinámico; es decir, lo negocia. A ver que miro...

Primary DNS Server: 80.58.61.250 Secondary DNS Server: 80.58.61.254

Y no son capaces de resolver ese marc.

Está claro pues que es un problema de Telefónica... otra vez :-/

Forward first or only? No uses "only", entonces falla.

Puf, pues "forward" nada porque estaba desactivado ¡¡!! Lo activo, añado la ip del dns de Telefónica (80.58.0.33) y habilito el "forward first", reinicio named y... tampoco resuelve "marc.info" :-(

Y a pesar de que el router no resuelve, el PC sí, con esa configuración.

Curioso :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 00:07 +0100, Carlos E. R. escribió:

El 2009-02-14 a las 22:34 +0100, Camaleón escribió:

...

Puf, pues "forward" nada porque estaba desactivado ¡¡!! Lo activo, añado la ip del dns de Telefónica (80.58.0.33) y habilito el "forward first", reinicio named y... tampoco resuelve "marc.info" :-(

A ver si lo tienes ce·hache·ruteado.

Sí, claro, lo está. Suse lo enjaula de manera predeterminada. Pero si este fuera el problema, tampoco resolvería otros dominios externos... y lo hace :-/ Por ejemplo, si le fuerzo a usar el dns local (con @172.168.0.11) google.com lo resuelve bien, pero marc.info, no.

Sin forwarders, debe resolver por sus propios medios, esto es, preguntando a los servidores raiz y siguiendo la cadena. Y si tu al principio lo tenías sin forwarders, es que esa configuración no es la que lee tu named, o tienes algún otro problema.

Ten cuidado con el chroot, si está activado, porque confunde mucho.

Está enjaulado, Carlos. cat /etc/sysconfig/named | grep CHROOT me devuelve "yes" Quizá sea un tema de cachés. ¿Cómo se limpia (flush) la caché de named, reiniciando el daemon? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 14:54 +0100, Carlos E. R. escribió:

El problema es que al estar enjaulado no te lee la configuración.

Analiza el script de inicio, debe copiar el fichero de configuración desde /etc/named.conf a otro sitio. Y al arrancarlo, en el log te sale que fichero de log está leyendo:

Feb 14 20:49:57 nimrodel named[12807]: loading configuration from '/etc/named.conf'

debes asegurarte que el fichero que lea sea el que debe ser. Ojo a lo que tienes ahí en forward first o forward only.

Eso aparece en el registro. Carga la configuración de /etc/named.conf

Pues entonces, tienes un problema en _tu_ dns, no el de telefónica. El de telefonica te importa un bledo, arregla el tuyo.

Ya bueno, pues en eso estamos ¿no?

A ver si me entiendes, tu servidor DNS local puede resolver por su cuenta sin preguntar para nada a telefonica ni opendns ni nadie: sólo a los servidores raiz.

La teoría me la sé ;-), pero no es lo que hace mi named.

Insisto: tu servidor DNS debe ser capaz de resolver _todo_ por sus medios. Una vez que te funcione, entonces y sólo entonces añade como forward first en la lista de forwarders los dns de tesa.

Que sí, que sí... pero no lo hace, no resuelve "por sus propios medios". Sólo me pasa con el dominio de "marc.info". Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 16:32 +0100, Carlos E. R. escribió:

Pues no puede ser, porque a mi me funciona.

Porque usas IP dinámica y recibes los dns dinámicamente en el router. Yo no. Quizá el problema venga por ahí. Ten en cuenta que una vez que el named cachea el servidor, ya lo reconoce para las próximas consultas. Prueba a reiniciar named y ejecutar esta consulta que pongo más abajo.

Mira dentro de la jaula, que esté bien todo. O quita la jaula. Quita los forwarders.

Sin "forwarders" ni "forward first". *** linux:/etc # dig marc.info +trace ; <<>> DiG 9.4.1-P1 <<>> marc.info +trace ;; global options: printcmd . 510837 IN NS G.ROOT-SERVERS.NET. . 510837 IN NS H.ROOT-SERVERS.NET. . 510837 IN NS F.ROOT-SERVERS.NET. . 510837 IN NS L.ROOT-SERVERS.NET. . 510837 IN NS C.ROOT-SERVERS.NET. . 510837 IN NS D.ROOT-SERVERS.NET. . 510837 IN NS J.ROOT-SERVERS.NET. . 510837 IN NS E.ROOT-SERVERS.NET. . 510837 IN NS I.ROOT-SERVERS.NET. . 510837 IN NS M.ROOT-SERVERS.NET. . 510837 IN NS B.ROOT-SERVERS.NET. . 510837 IN NS K.ROOT-SERVERS.NET. . 510837 IN NS A.ROOT-SERVERS.NET. ;; Received 512 bytes from 172.16.0.11#53(172.16.0.11) in 0 ms info. 172800 IN NS A0.INFO.AFILIAS-NST.info. info. 172800 IN NS B2.INFO.AFILIAS-NST.ORG. info. 172800 IN NS B0.INFO.AFILIAS-NST.ORG. info. 172800 IN NS C0.INFO.AFILIAS-NST.info. info. 172800 IN NS A2.INFO.AFILIAS-NST.info. info. 172800 IN NS D0.INFO.AFILIAS-NST.ORG. ;; Received 430 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 218 ms 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 *** Responde con un "connection timed out" y no recibe ningún registro A de ese dominio. En cambio, ejecutando la misma consulta con cualquier otro dominio, no tengo ningún problema: *** linux:/etc # dig spain.info +trace ; <<>> DiG 9.4.1-P1 <<>> spain.info +trace ;; global options: printcmd . 517446 IN NS j.root-servers.net. . 517446 IN NS b.root-servers.net. . 517446 IN NS k.root-servers.net. . 517446 IN NS h.root-servers.net. . 517446 IN NS c.root-servers.net. . 517446 IN NS m.root-servers.net. . 517446 IN NS d.root-servers.net. . 517446 IN NS g.root-servers.net. . 517446 IN NS l.root-servers.net. . 517446 IN NS a.root-servers.net. . 517446 IN NS e.root-servers.net. . 517446 IN NS f.root-servers.net. . 517446 IN NS i.root-servers.net. ;; Received 288 bytes from 172.16.0.11#53(172.16.0.11) in 0 ms info. 172800 IN NS B2.INFO.AFILIAS-NST.ORG. info. 172800 IN NS C0.INFO.AFILIAS-NST.info. info. 172800 IN NS D0.INFO.AFILIAS-NST.ORG. info. 172800 IN NS A2.INFO.AFILIAS-NST.info. info. 172800 IN NS B0.INFO.AFILIAS-NST.ORG. info. 172800 IN NS A0.INFO.AFILIAS-NST.info. ;; Received 431 bytes from 192.5.5.241#53(f.root-servers.net) in 45 ms spain.info. 86400 IN NS ns1.telefonica-data.com. spain.info. 86400 IN NS ns2.telefonica-data.com. ;; Received 83 bytes from 199.254.50.1#53(D0.INFO.AFILIAS-NST.ORG) in 66 ms spain.info. 300 IN A 213.4.113.235 spain.info. 300 IN NS ns2.telefonica-data.com. spain.info. 300 IN NS dns3c.telefonica-data.com. spain.info. 300 IN NS artemis.ttd.net. spain.info. 300 IN NS ns1.telefonica-data.com. ;; Received 180 bytes from 194.224.52.36#53(ns1.telefonica-data.com) in 44 ms *** Algo pasa pero no sé el qué :-/ Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 17:28 +0100, Carlos E. R. escribió:

Sin forwarders, no los uso, se ignoran.

Aún así, usas dns dinámicos (tienes configurada la ip del router en el /etc/resolv.conf). Es posible que algún servidor de telefónica si responda a esa consulta y tu named lo añada al caché.

Funciona.

Claro, por lo que te comento más arriba >:-) Quita del resolv.conf la ip del router y que se apañe solo tu named. Reinicia bind y vuelve a ejecutarlo.

Ahí puede estar tu problema, no estás interrogando a tu DNS local.

¿Cómo que no? El servidor con named es 172.16.0.11.

Eso es porque pregunta a ns1.korelogic.com o ns2.korelogic.com y no le responden. A mi sí me responden. Observa:

Claro, pero no es culpa de mi named. Es culpa del Telefónica que estará bloqueando o filtrando la respuesta... vaya ud a saber :-)

marc.info. 1800 IN A 63.238.77.253 marc.info. 1800 IN A 63.238.77.172 marc.info. 10800 IN NS ns2.korelogic.com. marc.info. 10800 IN NS ns1.korelogic.com. ;; Received 140 bytes from 173.66.103.23#53(ns2.korelogic.com) in 440 ms

Y si le pregunto al router (que es un linux 2.2, creo), con DNSs automáticas, responde también:

cer@nimrodel:~> dig @192.168.1.1 marc.info +trace

A ver, Carlos. Tu named también usa las dns de tu router, salvo que no lo tengas definido en resolv.conf.

Aunque el router también ha pasado ampliamente de tesa. Eso es curioso. O es el comando +trace que funciona así, que va preguntando directamente a la cadena de mando.

A ver, eso es. El +trace no pregunta a tu servidor dns excepto para saber cuales son los raices, a partir de ahí deduce toda la cadena preguntando a los dns respectivos. Si hago "dig @192.168.1.1 marc.info" no funciona, porque el router pregunta a tesa. Si hago "dig @192.168.1.12 marc.info" sí responde, porque es mi suse.

Y si lo haces con +trace va preguntando a los servidore dns autoritativos de cada paso. Lo extraño es que a mi me funciona, y a ti no.

Tienes un bug raro >:-)

¡Yujuuu! :-P Pero me da a mi que es problema de Telefónica y sus canales y enrutados del adsl.

Es como si tuvieras bloqueada la IP del servidor de nombres de korelogic.

Claro, no me responde.

Haz esto:

cer@nimrodel:~> host ns1.korelogic.com ns1.korelogic.com has address 173.66.103.22 cer@nimrodel:~> host ns2.korelogic.com ns2.korelogic.com has address 173.66.103.23

Mira, mira... linux:/etc # host ns1.korelogic.com ns1.korelogic.com has address 173.66.103.22 ;; connection timed out; no servers could be reached

Y entonces, pregúntale a ellos:

cer@nimrodel:~> dig @173.66.103.22 marc.info

linux:/etc # dig @173.66.103.22 marc.info ; <<>> DiG 9.4.1-P1 <<>> @173.66.103.22 marc.info ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached Si es que no me responden :-/ Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 19:14 +0100, Carlos E. R. escribió:

Que no, que en el /etc/resolv.conf tengo el 192.168.1.12, mi pc. Y no hay caché, lo reinicié para responderte.

Hum...

¿Y el otro?

Devuelve lo mismo: "timed out"

Por cierto, aquello de yutube era que yutube bloqueaba a telefonica por pesados, o algo así. Demasiados "hits" del mismo rango de ips. Algo de eso dijeron en la radio (cope). No era que telefonica jodiera a sus usuarios, como decían las malas lenguas. (Es que los españoles somos el asco del mundo hoy en dia. Los otros proveedores salen por la red de otro pais europeo, no aparecen como españoles. IMO.)

¡Ja! Eso no te lo crees ni tú :-) Los clientes de Telefónica acceden a YouTube tres días después <http://www.rtve.es/noticias/20090203/los-clientes-telefonica-acceden-you tube-tres-dias-despues/228007.shtml> Ambos se acusaron mutuamente de ser el culpable del problema, pero con el "curriculum" que tiene Telefónica con estas cosas, apuesto uno de mis caracoles controlados vía WiFi a que el error fue de ellos >:-)

Pues ahora será lo mismo. Tu IP estará en alguna lista negra, a lo mejor. ¿Lo puedes mirar? ¿Y hacer pings a esas IPs?

No, no va por ahí el asunto. A ti tampoco te resuelve con su servidor dns (80.58.0.33) y tienes ip dinámica... ¿Casualidad? No, problema de Telefónica.

cer@nimrodel:~> /usr/sbin/traceroute -m 50 173.66.103.23 traceroute to

La traza se me para en 81.46.40.130 (un nodo de telefónica,) no sale de España. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 20:28 +0100, Carlos E. R. escribió:

Más fácil me parece que sean los de allá que los de acá. Eso supondría que alguien estaba trabajando en viernes para hacer cambios. ¿Trabajar, en tesa, un viernes? 'amos, anda :-p

No hace falta que estén "trabajando". Si ese día "llovió", a Telefónica se le cruzan los cables, nunca mejor dicho >:-)

No, eso no demuestra nada. El DNS fallará tanto si está averiado como si no tiene acceso al 173.66.103.22 para preguntarle. Da lo mismo que la avería sea local que remota, el resultado será el mismo.

Carlos, no pretendas defender lo que no tiene defensa alguna. Tengo un problema con Telefónica, y Telefónica tiene un problema con algunos de sus servidores DNS. No le des más vueltas, ya te lo he demostrado. Si me dices que usando el 80.58.0.33 te resuelve ese dominio, entonces retiro lo dicho }:-) Ni con named ni gaitas, es la línea, el circuito que tenemos asignado o algún problema en sus enrutadores... recibo un "timed out" cuando consulto, es un problema de mi carrier (Telefónica).

Lo que no se es si puedes hacer una consulta dns a través de un proxy :-?

Que síii, y si uso otro servidor dns ya no tengo ese problema.

¿Quieres decir que a partir de ahí pone asteriscos, o que? Prueba con el puerto 53.

Sí, se para (asteriscos) en el hop #3. ¿Qué quieres pruebe en el puerto 53, el traceroute (-p 53)? :-? Se para en el mismo sitio. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-02-15 a las 21:33 +0100, Carlos E. R. escribió:

No, no me lo has demostrado.

Vaya que no. No me responde. Eso no es culpa de una configuración del named.

Si el ns1.korelogic.com no le da la gana de responder las consultas de los servidores DNS de telefonica, a tí te va a dar "timed out" - y el problema no sería de telefónica - pero tú no verías la diferencia.

¿Por qué responde entonces cuando uso otros servidores dns distintos de Telefónica?

No, porque cuando el 80.58.0.33 le pegunta a ns1.korelogic.com es éste el que no le responde.

Pues yo a eso le llamo "error o problema en los servidores dns de Telefónica" :-)

Que no, que no lo sabes. No sabes en que punto está el corte, si dentro de las maquinas de tesa o las de otro.

El corte está cuando uso sus servidores dns. Si lo hago a través del bind, ni siquiera responde a la consulta. Si uso los servidores dns de opendns funciona sin problemas.

No es lo mismo.

Yo lo que quiero es hacer la consulta haciendome pasar por otro para ver si resuelve.

Usa un proxy vía web, verás que sí funciona, que sí resuelve, que sí conecta y que sí accedes al dominio.

Ojo, cuando pone asteriscos no se ha parado. Lo unico que te dice el traceroute es que el servidor del salto "X" no devuelve respuesta, pero puede ser porque está caído o porque su cortafuegos no le da la gana responderte. La respuesta hay que interpretarla. Sólo cuando te responde, o te responde otro de más allá, tienes información.

¿Y de quién es el problema si cambiando los dns ya resuelve correctamente? ¿Del servidor de marc.info que no sabe "nada"? Verás Carlos, hace unos días, marc.info funcionaba con Telefónica. Ahora ya no. No creo en las meigas, pero sí creo (porque me pasa muchas otras veces esto mismo) que Telefónica "mete la pata" más de la cuenta. Ejemplo: lunes por la mañana, me dicen los usuarios que no pueden conectar con un servidor de EE.UU. Hago pruebas, y efectivamente, algunos routers conectan y resuelven, pero otros no. Todos de Telefónica, todos con IP fija... a los 15 min. vuelven a resolver. ¿De quién es el problema? >:-)

El traceroute, si.

Pues se para en el mismo salto, ya te lo he dicho. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

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) 3 81.Red-81-46-55.staticIP.rima-tde.net (81.46.55.81) 41.387 ms 40.680 ms 40.769 ms 4 So6-0-0-0-grtmadpe3.red.telefonica.wholesale.net (84.16.8.121) 42.265 ms 41.207 ms * 5 So6-3-0-0-grtparix3.red.telefonica-wholesale.net (84.16.12.118) 62.410 ms So0-3-0-0-grtparix3.red.telefonica-wholesale.net (213.140.43.250) 66.747 ms 66.265 ms 6 So2-3-0-0-grtwaseq2.red.telefonica-wholesale.net (84.16.12.30) 150.091 ms So-3-3-0-0-grtwaseq2.red.telefonica-wholesale.net (84.16.12.34) 148.489 ms 148.014 ms 7 GE1-2-0-0-grtwaseq4.red.telefonica-wholesale.net (213.140.49.194) 205.293 ms 202.411 ms xe0-2-0-0-grtwaseq4.red.telefonica-wholesale.net (213.140.36.33) 145.083 ms 8 Qwest-1-3-0-0-grtwaseq4.red.telefonica-wholesale.net (213.140.55.18) 149.980 ms 147.281 ms 146.051 ms 9 tpa-core-02.inet.qwest.net (67.14.3.78) 181.936 ms tpa-core-01.inet.qwest.net (67.14.3.2) 179.691 ms tpa-core-02.inet.qwest.net (67.14.3.78) 182.632 ms 10 tpa-edge-07.inet.qwest.net (205.171.27.118) 184.553 ms tpa-edge-07.inet.qwest.net (205.171.27.122) 179.907 ms tpa-edge-07.inet.qwest.net (205.171.27.118) 182.945 ms 11 208.47.124.146 (208.47.124.146) 182.489 ms 182.638 ms 182.530 ms 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. *** linux:~ # traceroute marc.info marc.info: Temporary failure in name resolution *** Una traza a la dirección falla. Es demasiado sospechoso, Carlos.

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.

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...

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é.

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 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. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-02-15 a las 21:23 -0200, Juan Erbes escribió:

No será que Timofónica está bloqueando el port 53, o la ip del dns que quieren usar?

No. El corte se produce unicamente al hacer un dig a ns1.korelogic.com, el resto funcionan. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYuXEACgkQtTMYHG2NR9UKRwCffYK6mf8VuxxBM8ODrUr2KJcf OMcAnRBCzDuCX72867Rt9/cgpO8oMWCS =gOmz -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-16 a las 09:17 +0100, Camaleón escribió:

El 2009-02-16 a las 01:55 +0100, Carlos E. R. escribió:

...

El 2009-02-15 a las 21:23 -0200, Juan Erbes escribió:

...

No será que Timofónica está bloqueando el port 53, o la ip del dns que quieren usar?

No.

El corte se produce unicamente al hacer un dig a ns1.korelogic.com, el resto funcionan.

No.

Lo que no funciona es un "dig marc.info".

Un "dig ns1.korelogic.com" sí funciona. También al "ns2.korelogic.com"

Que no. No he dicho un "dig de" sino "dig a". Prueba dig @173.66.103.22 marc.info - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZQv4ACgkQtTMYHG2NR9XCsgCgkbQfYGAL9Dh5zyg1k5eRsZJp rOsAnjHJiNTtXWem7dhtRjD86GjpDsS4 =nbno -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-02-16 a las 13:09 +0100, Camaleón escribió:

El 2009-02-16 a las 11:41 +0100, Carlos E. R. escribió:

...

No he dicho un "dig de" sino "dig a".

Esas preposiciones... :-P

...

Prueba dig @173.66.103.22 marc.info

No resuelve. No puedo rsolver ningún dominio que gestione la zona "ns1.korelogic.com" o "ns2.korelogic.com"

¡Pues eso es lo que te estoy diciendo desde ayer! Y yo si puedo, por cierto. Usando Telefónica, por supuesto. A ver, vuelve a mirar la salida del comando "dig marc.info +trace" que hiciste ayer, y fíjate bien en lo que significa cada paso. Lo primero a tener en cuenta es que ese comando no interroga al bind que tengas configurado salvo para el primer paso. Es decir, no usa el DNS de telefónica. * 1er paso: averiguar quienes son los servidores raiz. Esa respuesta es el párrafo anterior a este: ;; Received 512 bytes from 172.16.0.11#53(172.16.0.11) in 0 ms Es decir, el DNS local (el que sea que esté configurado en el resolv, o en la @ del comando) te da una lista de servidores raiz. * 2ndo paso: preguntar a uno de los raices por cuales son los servidores responsables del dominio "info". Te da una serie de DNS, que son el párrafo que termina con esta linea: ;; Received 430 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 218 ms * 3er paso: preguntar a uno de los servidores responsables del dominio "info" cuales son los DNS responsables del dominio "marc.info". Y te dice: 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 * 4to paso: preguntar a uno de los servidores responsables del dominio "marc.info", es decir, a korelogic, por cuales son las IPs de "marc.info". Y la respuesta es: ;; connection timed out; no servers could be reached **ESE** es el problema, que los servidores ns1.korelogic.com y ns2.korelogic.com no responden cuando preguntas tú, pero sí cuando pregunto yo: marc.info. 1800 IN A 63.238.77.172 marc.info. 1800 IN A 63.238.77.253 marc.info. 10800 IN NS ns1.korelogic.com. marc.info. 10800 IN NS ns2.korelogic.com. ;; Received 140 bytes from 173.66.103.22#53(ns1.korelogic.com) in 1155 ms Lo que no podemos saber es porqué no responden. No sabes si la consulta les llega, o si la corta telefónica, o la corta la verizon, o la corta korelogic, ni porqué. Lo que sí sabemos es que la consulta funciona si quien pregunta no viene de ciertos rangos.

Y lo curioso es que tampoco puedo usar un dns distinto, por ejemplo, el de Ono:

Mira, mira, ya no es sólo Telefónica...

*** hpc02@stthpc:~> dig @62.81.61.2 marc.info

; <<>> DiG 9.4.1-P1 <<>> @62.81.61.2 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 13137 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;marc.info. IN A

;; Query time: 51 msec ;; SERVER: 62.81.61.2#53(62.81.61.2) ;; WHEN: Mon Feb 16 13:01:18 2009 ;; MSG SIZE rcvd: 27 ***

Pero este lo dice bien claro: REFUSED

El caso es que falla con otros dominios:

*** hpc02@stthpc:~> dig @62.81.61.2 google.com

; <<>> DiG 9.4.1-P1 <<>> @62.81.61.2 google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9351 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;google.com. IN A

;; Query time: 49 msec ;; SERVER: 62.81.61.2#53(62.81.61.2) ;; WHEN: Mon Feb 16 13:05:49 2009 ;; MSG SIZE rcvd: 28 ***

Quizá los ISP estén poniendo restricciones en las consultas y sólo permitan a sus clientes usar sus servidores dns :-?

Exacto. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZZTkACgkQtTMYHG2NR9WVFACeLTYqyuwRMcXFoP5pLIb1geU7 mxcAnA4EJ5nKoP9NZRsK+7EjbSF+zoL9 =NQCc -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-02-15 a las 23:35 +0100, Camaleón escribió:

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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-02-16 a las 08:34 +0100, Camaleón escribió:

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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-16 a las 12:56 +0100, Camaleón escribió:

El 2009-02-16 a las 12:16 +0100, Carlos E. R. escribió:

...

Claro, porque no lo han vetado.

No eso eso. No pueden vetar una consulta al servidor dns.

A ver, lo que pueden hacer es poner un cartelito en su página principal y decir: "Su ip está bloqueada por eso, esto y eso". Pero no las consultas... el error que me da indica un problema técnico, nada de "bloqueos" a una IP determinada.

¿Y porqué te van a poner un letrerito? Eso es como cuando mandas un correo a algún sitio y lo tiran a la basura sin leerlo porque creen que eres un spamer. No te lo dicen. Es incorrecto, pero lo hacen muchos.

...

No, no lo sabes.

Sí lo sé. Es Telefónica... ¿quién si no? :-)

Si claro. "Detengan a los delincuentes habituales".

...

Y dale.

Pero es que es "asín", no puedo decir otra cosa porque sería falso.

Que no lo puedes saber. Que se han ganado a pulso su mala fama, vale, pero no siempre son ellos.

...

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 no.

No hace falta ir a la luna para saber que no hay oxígeno suficiente como para respirar.

Se hacen pruebas, desde distintos ISP, con distintos dns, y se obtienen datos. Con esos datos, trabajas y se extraen conclusiones.

Pero las conclusiones que sacas no son las correctas.

...

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.

Narices no las tengo:

- Funcionaba hace unos días - Desde un ISP distinto, sin problemas - Con un DNS distinto, sin problemas

Si no te dice nada... vale. A mi, sí.

Me dice que no se quien es el culpable. Veo el atasco, sí, pero no el punto del atasco.

...

El aparente.

El que funciona.

...

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.

Al lado español, no. Al lado Telefónica.

Pues eso, le echas las culpas a Telefónica sin pruebas.

...

Claro que no, porque ese DNS tiene las peticiones vetadas por korelogic.

"Demuestra" que están vetadas.

Demuestra que no lo están. No puedes. Ni yo puedo demostrar que están vetadas, ni tu que Telefónica ha cortado la ruta. Fíjate el detalle: para que sea Telefónica la culpable, tiene que haber cortado el puerto 53 de los paquetes que vayan a ns1.korelogic.com, y nada más. Y eso lo tiene que hacer en los routers gigantescos de toda la red. ¡Eso son muchos recursos! Es mucho más fácil cortar el tráfico en destino, en una sóla IP o dos.

...

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.

No. Un "timed out" no es un "rejected" o un "refused".

Es más eficiente en recursos un timeout, o sea, no responder. Es lo que se hace en muchos cortafuegos. Muy maleducado, pero eficiente.

¿Sabes que significa "vetar" a todo un ISP con la carga de clientes que tiene Telefónica? No, esto no tiene tintes de algo meditado, ni mucho menos.

Claro que lo se, pero no es la primera vez. Busca por ahí, hay servidores y gente que comenta que bloquea a zonas enteras del globo: sobre todo a Asia. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZaJMACgkQtTMYHG2NR9WUaACcDOZC+9ny1sU4z6fMNXEEX0Q6 aMkAn3lXj1KlcbqC2P/gPqU+rC7ToBi0 =k0Wz -----END PGP SIGNATURE-----

On Saturday 14 February 2009 20:55:44 Carlos E. R. wrote:

dig @80.58.0.97 marc.info

lluis@lilm3111:~> dig @80.58.0.97 marc.info ; <<>> DiG 9.5.0-P2 <<>> @80.58.0.97 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32950 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN A ;; Query time: 733 msec ;; SERVER: 80.58.0.97#53(80.58.0.97) ;; WHEN: Sat Feb 14 23:39:54 2009 ;; MSG SIZE rcvd: 27 ///////////////////////////////////////////////////////////////////////////////////////////////////////////// lluis@lilm3111:~> dig @208.67.222.222 marc.info ; <<>> DiG 9.5.0-P2 <<>> @208.67.222.222 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36638 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 640 IN A 63.238.77.172 marc.info. 640 IN A 63.238.77.253 ;; Query time: 88 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Sat Feb 14 23:39:19 2009 ;; MSG SIZE rcvd: 59 A mi también me falla, pero no tengo ni idea . -- Saludos Lluis

El 2009-02-14 a las 23:03 -0200, Juan Erbes escribió:

Aqui en la Argentina, Timofónica tambien es un desatre.

Yo hace casi un año empecé a usar los servidores Opendns, y se acabaron los problemas:

https://www.opendns.com/start/device/suse-linux

No me hace mucha gracia, pero al final he tenido que añadir uno de los servidores dns de opendns para que resuelva, detrás del de Telefónica. Si Telefónica no lo encuentra, pregunta al de opendns. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org