[opensuse-es] [OT] Servidores DNS de Telefónica
Hola, Desde hace unos días tengo problemas con la resolución de un dominio en concreto (marc.info). Utilizo los servidores dns de Telefónica. ¿Alguien que tenga configurado algún servidor de Telefónica podría confirmar este punto? No sé si se trata de un problema localizado o general, porque ya lleva varios días así :-? *** stthpc:/etc # dig @80.58.0.97 marc.info ; <<>> DiG 9.4.1-P1 <<>> @80.58.0.97 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8891 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN A ;; Query time: 1083 msec ;; SERVER: 80.58.0.97#53(80.58.0.97) ;; WHEN: Sat Feb 14 19:54:23 2009 ;; MSG SIZE rcvd: 27 *** En cambio, si se utiliza el servidor dns de opendns (por ejemplo), no hay ningún problema... *** stthpc:/etc # dig @208.67.222.222 marc.info ; <<>> DiG 9.4.1-P1 <<>> @208.67.222.222 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1070 IN A 63.238.77.172 marc.info. 1070 IN A 63.238.77.253 ;; Query time: 79 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Sat Feb 14 19:58:21 2009 ;; MSG SIZE rcvd: 59 *** 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 El 2009-02-14 a las 20:06 +0100, Camaleón escribió:
Desde hace unos días tengo problemas con la resolución de un dominio en concreto (marc.info). Utilizo los servidores dns de Telefónica.
¿Alguien que tenga configurado algún servidor de Telefónica podría confirmar este punto? No sé si se trata de un problema localizado o general, porque ya lleva varios días así :-?
*** stthpc:/etc # dig @80.58.0.97 marc.info
; <<>> DiG 9.4.1-P1 <<>> @80.58.0.97 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8891 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;marc.info. IN A
;; Query time: 1083 msec ;; SERVER: 80.58.0.97#53(80.58.0.97) ;; WHEN: Sat Feb 14 19:54:23 2009 ;; MSG SIZE rcvd: 27 ***
En cambio, si se utiliza el servidor dns de opendns (por ejemplo), no hay ningún problema...
*** stthpc:/etc # dig @208.67.222.222 marc.info
; <<>> DiG 9.4.1-P1 <<>> @208.67.222.222 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;marc.info. IN A
;; ANSWER SECTION: marc.info. 1070 IN A 63.238.77.172 marc.info. 1070 IN A 63.238.77.253
;; Query time: 79 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Sat Feb 14 19:58:21 2009 ;; MSG SIZE rcvd: 59 ***
cer@nimrodel:~> dig marc.info ; <<>> DiG 9.4.2-P1 <<>> marc.info ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52585 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1800 IN A 63.238.77.253 marc.info. 1800 IN A 63.238.77.172 ;; AUTHORITY SECTION: marc.info. 9052 IN NS ns2.korelogic.com. marc.info. 9052 IN NS ns1.korelogic.com. ;; ADDITIONAL SECTION: ns1.korelogic.com. 94081 IN A 173.66.103.22 ns2.korelogic.com. 94081 IN A 173.66.103.23 ;; Query time: 175 msec ;; SERVER: 192.168.1.12#53(192.168.1.12) ;; WHEN: Sat Feb 14 20:36:07 2009 ;; MSG SIZE rcvd: 140 cer@nimrodel:~> El servidor que pones tu no responde. Y mi servidor ahora mismo no se a quien pregunta, creo que a los root. Hago un "rcnamed restart", cer@nimrodel:~> host -v marc.info Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2816 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1800 IN A 63.238.77.172 marc.info. 1800 IN A 63.238.77.253 ;; AUTHORITY SECTION: marc.info. 10800 IN NS ns1.korelogic.com. marc.info. 10800 IN NS ns2.korelogic.com. ;; ADDITIONAL SECTION: ns2.korelogic.com. 172800 IN A 173.66.103.23 ns1.korelogic.com. 172800 IN A 173.66.103.22 Received 140 bytes from 192.168.1.12#53 in 797 ms Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5116 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN AAAA ;; AUTHORITY SECTION: marc.info. 3600 IN SOA ns1.korelogic.com. root.marc.info. 2008111501 1200 3600 604800 3600 Received 85 bytes from 192.168.1.12#53 in 178 ms Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48518 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;marc.info. IN MX ;; ANSWER SECTION: marc.info. 10800 IN MX 100 marcmx.10east.com. marc.info. 10800 IN MX 10 mail.marc.info. ;; AUTHORITY SECTION: marc.info. 10799 IN NS ns1.korelogic.com. marc.info. 10799 IN NS ns2.korelogic.com. ;; ADDITIONAL SECTION: mail.marc.info. 1800 IN A 173.66.103.20 ns2.korelogic.com. 172799 IN A 173.66.103.23 ns1.korelogic.com. 172799 IN A 173.66.103.22 Received 175 bytes from 192.168.1.12#53 in 181 ms cer@nimrodel:~> 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: cer@nimrodel:~> host -v marc.info Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54650 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1800 IN A 63.238.77.172 marc.info. 1800 IN A 63.238.77.253 ;; AUTHORITY SECTION: marc.info. 10800 IN NS ns2.korelogic.com. marc.info. 10800 IN NS ns1.korelogic.com. ;; ADDITIONAL SECTION: ns2.korelogic.com. 172550 IN A 173.66.103.23 ns1.korelogic.com. 172549 IN A 173.66.103.22 Received 140 bytes from 192.168.1.12#53 in 4054 ms Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65109 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN AAAA ;; AUTHORITY SECTION: marc.info. 3600 IN SOA ns1.korelogic.com. root.marc.info. 2008111501 1200 3600 604800 3600 Received 85 bytes from 192.168.1.12#53 in 535 ms Trying "marc.info" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14190 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;marc.info. IN MX ;; ANSWER SECTION: marc.info. 10800 IN MX 10 mail.marc.info. marc.info. 10800 IN MX 100 marcmx.10east.com. ;; AUTHORITY SECTION: marc.info. 10799 IN NS ns1.korelogic.com. marc.info. 10799 IN NS ns2.korelogic.com. ;; ADDITIONAL SECTION: mail.marc.info. 1800 IN A 173.66.103.20 ns2.korelogic.com. 172549 IN A 173.66.103.23 ns1.korelogic.com. 172548 IN A 173.66.103.22 Received 175 bytes from 192.168.1.12#53 in 301 ms cer@nimrodel:~> En cambio, si pido "terra.es" se ve que interroga a los root servers, o eso creo: cer@nimrodel:~> host -v terra.es Trying "terra.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36778 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 12 ;; QUESTION SECTION: ;terra.es. IN A ;; ANSWER SECTION: terra.es. 10440 IN A 213.4.130.210 ;; AUTHORITY SECTION: . 445728 IN NS C.ROOT-SERVERS.NET. . 445728 IN NS A.ROOT-SERVERS.NET. . 445728 IN NS I.ROOT-SERVERS.NET. . 445728 IN NS K.ROOT-SERVERS.NET. . 445728 IN NS M.ROOT-SERVERS.NET. . 445728 IN NS G.ROOT-SERVERS.NET. . 445728 IN NS D.ROOT-SERVERS.NET. . 445728 IN NS B.ROOT-SERVERS.NET. . 445728 IN NS E.ROOT-SERVERS.NET. . 445728 IN NS H.ROOT-SERVERS.NET. . 445728 IN NS F.ROOT-SERVERS.NET. . 445728 IN NS L.ROOT-SERVERS.NET. . 445728 IN NS J.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: K.ROOT-SERVERS.NET. 532117 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 533763 IN AAAA 2001:7fd::1 F.ROOT-SERVERS.NET. 580330 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 593369 IN AAAA 2001:500:2f::f A.ROOT-SERVERS.NET. 532116 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 533699 IN AAAA 2001:503:ba3e::2:30 L.ROOT-SERVERS.NET. 532116 IN A 199.7.83.42 L.ROOT-SERVERS.NET. 533775 IN AAAA 2001:500:3::42 H.ROOT-SERVERS.NET. 587406 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 591355 IN AAAA 2001:500:1::803f:235 B.ROOT-SERVERS.NET. 592707 IN A 192.228.79.201 M.ROOT-SERVERS.NET. 532117 IN A 202.12.27.33 Received 505 bytes from 192.168.1.12#53 in 88 ms Trying "terra.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46685 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;terra.es. IN AAAA ;; AUTHORITY SECTION: terra.es. 112 IN SOA dns1.terra.es. dnsadmin.corp.terra.es. 2009021300 28800 7200 2592000 172800 Received 81 bytes from 192.168.1.12#53 in 68 ms Trying "terra.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18802 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 12 ;; QUESTION SECTION: ;terra.es. IN MX ;; ANSWER SECTION: terra.es. 10367 IN MX 100 mx.terra.es. ;; AUTHORITY SECTION: . 445727 IN NS E.ROOT-SERVERS.NET. . 445727 IN NS G.ROOT-SERVERS.NET. . 445727 IN NS D.ROOT-SERVERS.NET. . 445727 IN NS I.ROOT-SERVERS.NET. . 445727 IN NS K.ROOT-SERVERS.NET. . 445727 IN NS J.ROOT-SERVERS.NET. . 445727 IN NS H.ROOT-SERVERS.NET. . 445727 IN NS A.ROOT-SERVERS.NET. . 445727 IN NS B.ROOT-SERVERS.NET. . 445727 IN NS L.ROOT-SERVERS.NET. . 445727 IN NS F.ROOT-SERVERS.NET. . 445727 IN NS C.ROOT-SERVERS.NET. . 445727 IN NS M.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: mx.terra.es. 10234 IN A 213.4.149.224 K.ROOT-SERVERS.NET. 532116 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 533762 IN AAAA 2001:7fd::1 F.ROOT-SERVERS.NET. 580329 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 593368 IN AAAA 2001:500:2f::f A.ROOT-SERVERS.NET. 532115 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 533698 IN AAAA 2001:503:ba3e::2:30 L.ROOT-SERVERS.NET. 532115 IN A 199.7.83.42 L.ROOT-SERVERS.NET. 533774 IN AAAA 2001:500:3::42 H.ROOT-SERVERS.NET. 587405 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 591354 IN AAAA 2001:500:1::803f:235 B.ROOT-SERVERS.NET. 592706 IN A 192.228.79.201 Received 508 bytes from 192.168.1.12#53 in 64 ms cer@nimrodel:~> Esto es con: forwarders { 192.168.1.1; }; # router adsl ... forward first; Trae cuenta tener tu propio servidor DNS. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmXIcYACgkQtTMYHG2NR9VQMACdHdMrXxXCKAukcP4t7xhXUY09 qZUAmwfiTCUmBo4r5LN/EZ8BwlReWSyc =Wi42 -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-14 a las 21:46 +0100, Camaleón escribió:
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?
No, es mi PC. Las primeras pruebas usaban los root servers.
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?
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.
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 :-(
Forward first or only? No uses "only", entonces falla. Como te dije, tengo: forwarders { 192.168.1.1; }; # router adsl forward first; Y a pesar de que el router no resuelve, el PC sí, con esa configuración. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmXMxQACgkQtTMYHG2NR9VSXgCfTVEqeGMuqX27MeKeytDsbZoM nXQAnRpQzV1D858VZYQmSX6r8y5PEKz0 =uEVr -----END PGP SIGNATURE-----
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-14 a las 22:34 +0100, Camaleón escribió:
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 :-/
Pues si.
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" :-(
A ver si lo tienes ce·hache·ruteado.
Y a pesar de que el router no resuelve, el PC sí, con esa configuración.
Curioso :-?
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. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmXTsUACgkQtTMYHG2NR9X3oQCfaES2jyiS87uVvfELwPr3zhNb b0wAn20YwGWZLc48G2S0aqHc7cd33JFP =h27W -----END PGP SIGNATURE-----
El 14 de febrero de 2009 17:06, Camaleón
Hola,
Desde hace unos días tengo problemas con la resolución de un dominio en concreto (marc.info). Utilizo los servidores dns de Telefónica.
¿Alguien que tenga configurado algún servidor de Telefónica podría confirmar este punto? No sé si se trata de un problema localizado o general, porque ya lleva varios días así :-?
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 Salu2 -- 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-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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-15 a las 13:35 +0100, Camaleón escribió:
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 :-/
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.
Por ejemplo, si le fuerzo a usar el dns local (con @172.168.0.11) google.com lo resuelve bien, pero marc.info, no.
Pues entonces, tienes un problema en _tu_ dns, no el de telefónica. El de telefonica te importa un bledo, arregla el tuyo. 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. 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. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYHpYACgkQtTMYHG2NR9V6UACfQzyQZDuzEPmta/+g0gFmR3kA rx4An3IXVsa72W8eV2kfX/ZfwUFCMxgC =M9WL -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-15 a las 15:08 +0100, Camaleón escribió:
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.
Pues no puede ser, porque a mi me funciona.
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".
Mira dentro de la jaula, que esté bien todo. O quita la jaula. Quita los forwarders. Yo no use chroot - total, no sirvo a nadie... Esta es mi configuración, heredada del 9.3: options { directory "/etc/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; listen-on-v6 { any; }; notify no; }; zone "." in { type hint; file "root.hint"; }; logging { channel lame_errors { # file "/var/log/named-lame-servers" versions 2 size 200k; # Cer: no puede remombrarlos file "/var/lib/named/log/named-lame-servers" versions 2 size 200k; severity debug 3; print-severity yes; print-time yes; }; category lame-servers { lame_errors; }; }; zone "localhost" in { type master; file "zone/localhost"; }; zone "0.in-addr.arpa" in { type master; file "zone/0"; }; zone "255.in-addr.arpa" in { type master; file "zone/255"; }; zone "0.0.127.in-addr.arpa" in { type master; file "zone/0.0.127"; }; zone "midominiolocalinexistente" in { type master; file "zone/midominiolocalinexistente"; }; zone "1.168.192.in-addr.arpa" in { type master; file "zone/1.168.192"; }; include "/etc/named.conf.include"; Y comprueba el root.hint - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYNYwACgkQtTMYHG2NR9WYTwCeJ6maAxYXLav+2QsmqMpSgYbM PUcAnRbCEJQ3UKJE4D12vn7Rc0ZFQJpK =vCdy -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-15 a las 17:00 +0100, Camaleón escribió:
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.
Sin forwarders, no los uso, se ignoran.
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.
Funciona.
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
Ahí puede estar tu problema, no estás interrogando a tu DNS local.
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.
Eso es porque pregunta a ns1.korelogic.com o ns2.korelogic.com y no le responden. A mi sí me responden. Observa: cer@nimrodel:~> dig marc.info +trace ; <<>> DiG 9.4.2-P1 <<>> marc.info +trace ;; global options: printcmd . 3600000 IN NS H.ROOT-SERVERS.NET. . 3600000 IN NS A.ROOT-SERVERS.NET. . 3600000 IN NS J.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. . 3600000 IN NS I.ROOT-SERVERS.NET. . 3600000 IN NS K.ROOT-SERVERS.NET. . 3600000 IN NS F.ROOT-SERVERS.NET. . 3600000 IN NS E.ROOT-SERVERS.NET. . 3600000 IN NS L.ROOT-SERVERS.NET. . 3600000 IN NS C.ROOT-SERVERS.NET. . 3600000 IN NS M.ROOT-SERVERS.NET. . 3600000 IN NS D.ROOT-SERVERS.NET. . 3600000 IN NS G.ROOT-SERVERS.NET. ;; Received 228 bytes from 192.168.1.12#53(192.168.1.12) in 6 ms <================ 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. info. 172800 IN NS B2.INFO.AFILIAS-NST.ORG. ;; Received 430 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 121 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 1020 ms 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 ; <<>> DiG 9.4.2-P1 <<>> @192.168.1.1 marc.info +trace ; (1 server found) ;; global options: printcmd . 372499 IN NS C.ROOT-SERVERS.NET. . 372499 IN NS D.ROOT-SERVERS.NET. . 372499 IN NS E.ROOT-SERVERS.NET. . 372499 IN NS F.ROOT-SERVERS.NET. . 372499 IN NS G.ROOT-SERVERS.NET. . 372499 IN NS H.ROOT-SERVERS.NET. . 372499 IN NS I.ROOT-SERVERS.NET. . 372499 IN NS J.ROOT-SERVERS.NET. . 372499 IN NS K.ROOT-SERVERS.NET. . 372499 IN NS L.ROOT-SERVERS.NET. . 372499 IN NS M.ROOT-SERVERS.NET. . 372499 IN NS A.ROOT-SERVERS.NET. . 372499 IN NS B.ROOT-SERVERS.NET. ;; Received 504 bytes from 192.168.1.1#53(192.168.1.1) in 141 ms info. 172800 IN NS A2.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 A0.INFO.AFILIAS-NST.info. info. 172800 IN NS D0.INFO.AFILIAS-NST.ORG. info. 172800 IN NS C0.INFO.AFILIAS-NST.info. ;; Received 430 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 256 ms marc.info. 86400 IN NS ns1.korelogic.com. marc.info. 86400 IN NS ns2.korelogic.com. ;; Received 76 bytes from 199.249.121.1#53(B2.INFO.AFILIAS-NST.ORG) in 308 ms marc.info. 1800 IN A 63.238.77.253 marc.info. 1800 IN A 63.238.77.172 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 620 ms 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 >:-) Es como si tuvieras bloqueada la IP del servidor de nombres de korelogic. 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 Y entonces, pregúntale a ellos: cer@nimrodel:~> dig @173.66.103.22 marc.info ; <<>> DiG 9.4.2-P1 <<>> @173.66.103.22 marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53113 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1800 IN A 63.238.77.253 marc.info. 1800 IN A 63.238.77.172 ;; AUTHORITY SECTION: marc.info. 10800 IN NS ns2.korelogic.com. marc.info. 10800 IN NS ns1.korelogic.com. ;; ADDITIONAL SECTION: ns1.korelogic.com. 120 IN A 173.66.103.22 ns2.korelogic.com. 120 IN A 173.66.103.23 ;; Query time: 171 msec ;; SERVER: 173.66.103.22#53(173.66.103.22) ;; WHEN: Sun Feb 15 17:26:12 2009 ;; MSG SIZE rcvd: 140 - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYQp4ACgkQtTMYHG2NR9WvsACfREVs5aHkGcJtQr6UiAfOD+67 e5sAni+Hck/vw17v7ehA77gL3tR8Bj5S =5m2Z -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-15 a las 17:50 +0100, Camaleón escribió:
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é.
Que no, que en el /etc/resolv.conf tengo el 192.168.1.12, mi pc. Y no hay caché, lo reinicié para responderte.
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.
Que ya lo hice, la quité.
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.
Ah, vale, es que no es la tipica 192.
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 :-)
Mmmm...
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.
No usa a mi router. No para esas pruebas, lo quité.
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 :-/
¿Y el otro? 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.) Lo que pasa es que no hay contactos de telefonica de gente que responda, porque no llegas más allá de los floreros a no ser que seas un peso pesado o tengas enchufe en la moncloa. Pues ahora será lo mismo. Tu IP estará en alguna lista negra, a lo mejor. ¿Lo puedes mirar? ¿Y hacer pings a esas IPs? cer@nimrodel:~> /usr/sbin/traceroute -m 50 173.66.103.23 traceroute to 173.66.103.23 (173.66.103.23), 50 hops max, 40 byte packets 1 router (192.168.1.1) 0.480 ms 0.456 ms 0.466 ms 4 So6-0-0-0-grtmadad1.red.telefonica-wholesale.net.10.16.84.in-addr.arpa (84.16.10.73) 66.771 ms 62.761 ms 63.796 ms 5 Xe7-1-3-0-grtmadde2.red.telefonica-wholesale.net (84.16.13.210) 64.941 ms Xe2-1-0-0-grtpartv1.red.telefonica-wholesale.net (84.16.15.182) 86.320 ms Xe0-1-0-0-grtpartv1.red.telefonica-wholesale.net (84.16.13.186) 85.714 ms 6 so3-2-0-0-grtparix1.red.telefonica-wholesale.net (213.140.36.74) 85.801 ms Xe4-0-0-0-grtparix1.red.telefonica-wholesale.net (84.16.13.230) 90.050 ms so3-2-0-0-grtparix1.red.telefonica-wholesale.net (213.140.36.74) 84.788 ms 7 so7-0-2-0-grtwaseq3.red.telefonica-wholesale.net (213.140.36.126) 163.630 ms So4-1-0-0-grtwaseq3.red.telefonica-wholesale.net (213.140.36.130) 173.786 ms So5-3-0-0-grtwaseq3.red.telefonica-wholesale.net (213.140.36.210) 166.532 ms 8 213.140.53.130 (213.140.53.130) 232.568 ms 229.758 ms 173.522 ms 9 so-7-3-0-0.BB-RTR1.RES.verizon-gni.net (130.81.10.89) 170.366 ms 177.666 ms 174.409 ms 10 P14-0.LCR-01.WASHDC.verizon-gni.net (130.81.29.217) 175.486 ms 174.524 ms 173.905 ms 11 L1.VFTTP-34.WASHDC.verizon-gni.net (130.81.243.134) 169.476 ms 170.595 ms 171.486 ms 12 * * * 13 * * * ... 48 * * * 49 * * * 50 * * * cer@nimrodel:~> Lo unico que se es que llego hasta verizon, más allá no se sabe cual falla, traceroute no lo demuestra. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYW6MACgkQtTMYHG2NR9U7vgCgkTOSuKTi3RNEI2cGZmM9RGAh cB0AnRE6Ln0RIOo5XWK6lJAroJ0/INs+ =emDc -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-02-15 a las 19:14 +0100, Carlos E. R. escribió:
¡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 >:-)
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
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.
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. Lo que no se es si puedes hacer una consulta dns a través de un proxy :-?
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.
¿Quieres decir que a partir de ahí pone asteriscos, o que? Prueba con el puerto 53. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYbNAACgkQtTMYHG2NR9UimACgiB3/cC8XtRAMAPGeU6yDPGAM bdoAn02C0FPccMiNKiHk3v6YOLKuGEv4 =0kKS -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
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.
No, no me lo has demostrado. 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.
Si me dices que usando el 80.58.0.33 te resuelve ese dominio, entonces retiro lo dicho }:-)
No, porque cuando el 80.58.0.33 le pegunta a ns1.korelogic.com es éste el que no le responde.
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).
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.
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.
No es lo mismo. Yo lo que quiero es hacer la consulta haciendome pasar por otro para ver si resuelve.
¿Quieres decir que a partir de ahí pone asteriscos, o que? Prueba con el puerto 53.
Sí, se para (asteriscos) en el hop #3.
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.
¿Qué quieres pruebe en el puerto 53, el traceroute (-p 53)? :-?
El traceroute, si. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYfCoACgkQtTMYHG2NR9UQCwCgiixqRUzp0D+6uUhRAdRmRHhD oiQAn3NOB7qSdIlLwwejTGb4AMxDjRbO =NZ/I -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
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.
No digo que lo sea.
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?
Porque a ellos no les han cortado el paso en korelogic.
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" :-)
No señor. Vamos a ver, suponte que mandas un paquete por a Paris. Se lo das al bedel, y este lo envía por "Paquetes Pérez". Estos llegan a San Juan de Luz, donde lo traspasan a "Camionets Asterix". Al llegar a las cercanías de París, una huega de camioneros ha cortado la autopista, dejando sólo pasar a los de UPS pero no a los autónomos. Los paquetes via Barcelona en cambio no tienen problema, porque el dueño de "Camionets Obelix" está casado con la hija del jefe del sindicato. O también podrían haber ido via "Seo de Urgel", porque "Paquetería Gutierrez" tiene linea con París. Y entonces vas tu y le echas las culpas al bedel por haberte mandado el paquete via oeste en vez de via este, cuando el bedel no tiene ni puñetera idea de las rutas que va a usar ups o fedex o quien sea. 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. 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 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. 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. Con el tiempo los de Telefónica volvieron a tener línea con Cuba.
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.
No es via web. Y no sé explicarte cómo hacerlo, no lo he visto hacer y no se como se hace.
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? >:-)
No sabes si el proveedor de USA le ha puesto la zancadilla o alguien ha tirado una ruta.
El traceroute, si.
Pues se para en el mismo salto, ya te lo he dicho.
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í. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYkS8ACgkQtTMYHG2NR9W7agCdFwAasOiO3RdVuTfdHhA7tG4I /D4AoIR3J9/VjwzH+iH9M/fL8Vh0v2+V =1RW+ -----END PGP SIGNATURE-----
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
El día 15 de febrero de 2009 20:35, Camaleón
El 2009-02-15 a las 23:03 +0100, Carlos E. R. escribió:
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.
No será que Timofónica está bloqueando el port 53, o la ip del dns que quieren usar? http://linuxgazette.net/issue50/tag/1.html Salu2 -- 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 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:
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-----
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. 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. Verás, yo no pago a Youtube ni a marc.info, sino a Telefónica >:-)
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 >:-)
;; 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...
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.
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.
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.
Esos a los que llamas no te pdorán decir gran cosa.
¿Documentado? No me hagas reír.
Funcionaba por casualidad, normalmente era al revés.
Pero lo sabíais quienes teníais que saberlo. Suficiente.
Como nosotros estábamos "dentro", nos enterábamos de la causa real de los problemas, al tiempo.
Pues eso.
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.
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 :-)
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.
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.
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. 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-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" 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 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 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-----
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.
Doctor, me duele el dedo. Vale, te quito el brazo.
Esa es una de las soliciones posibles. Si tienes gangrena, corte que te crio.
No, no lo sabes.
Sí lo sé. Es Telefónica... ¿quién si no? :-)
Y dale.
Pero es que es "asín", no puedo decir otra cosa porque sería falso.
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.
Pues eso. Al cliente (a los clientes) no les dicen nada. Y eh, que somos los que pagamos todos los meses >:-)
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.
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í.
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.
Claro que no, porque ese DNS tiene las peticiones vetadas por korelogic.
"Demuestra" que están vetadas.
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.
No. Un "timed out" no es un "rejected" o un "refused". ¿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. 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-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" Y lo curioso es que tampoco puedo usar un dns distinto, por ejemplo, el de Ono: *** 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 :-? 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-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 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-----
El 2009-02-16 a las 14:08 +0100, Carlos E. R. escribió:
¡Pues eso es lo que te estoy diciendo desde ayer!
Pero eso ya lo sabemos... también desde ayer :-)
Y yo si puedo, por cierto. Usando Telefónica, por supuesto.
Pues a ver si me dices con qué servidor dns de telefónica te resuelve porque yo no he logrado que me resuelva ninguno de los que usa. He probado con un móden rtb y desde la tarjeta pcmcia, y no hay manera: con sus dns no es capaz de resolver ese dominio :-(
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.
Todo esto ya lo sabemos, Carlos. "Timed out", no logra conectar con el servidor dns del dominio.
**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
Pues dime con qué dns de telefónica resuelves y lo pruebo :-)
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.
Sólo he logrado respuesta utilizando los dns de opendns y un servidor español (saturno.ran.es): *** hpc02@stthpc:~> dig @saturno.ran.es marc.info ; <<>> DiG 9.4.1-P1 <<>> @saturno.ran.es marc.info ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35940 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;marc.info. IN A ;; ANSWER SECTION: marc.info. 1799 IN A 63.238.77.253 marc.info. 1799 IN A 63.238.77.172 ;; Query time: 176 msec ;; SERVER: 212.34.128.5#53(212.34.128.5) ;; WHEN: Mon Feb 16 18:57:16 2009 ;; MSG SIZE rcvd: 59 *** El resto o no me lo permiten (refused) o son los de telefónica, que fallan (servfail).
Mira, mira, ya no es sólo Telefónica...
Están restringiendo las consultas a sus usuarios. Y eso es malo :-/ 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-16 a las 14:22 +0100, Carlos E. R. escribió:
¿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.
Porque ese es el procedimiento. En un servidor de correo, igual. En el registro de sesión ves por qué te bloquea la ip o el dominio.
Si claro. "Detengan a los delincuentes habituales".
Es que no es la primera vez, Carlos. Soy "gato escaldado" con este tema.
Que no lo puedes saber.
Que se han ganado a pulso su mala fama, vale, pero no siempre son ellos.
Si se ganan "mala fama" como dices, es porque no son transparentes y no comunican nada a los usuarios. Aún recuerdo el mega-proxy transparente que pusieron...
Pero las conclusiones que sacas no son las correctas.
Con los datos que tengo, sí.
Me dice que no se quien es el culpable. Veo el atasco, sí, pero no el punto del atasco.
Correcto. Pero yo veo también el by-pass, veo una salida a 3 km. que me dice "eh, por aquí para llegar al destino" y tomo la salida.
Pues eso, le echas las culpas a Telefónica sin pruebas.
¡Es que no me funciona "ninguno" de sus dns! :-( Podría ser un problema de su caché, no lo sé. Pero como no es la primera vez que pasa (y con dominios diferentes) pues tengo la vocecilla de la experiencia que me dice "Telefóoonica, Telefóoonicaaaa" :-)
Demuestra que no lo están.
Si no funcionara con ningún otro servidor dns, vale. Podrían tener un problema ellos, los del dominio. Pero es que con otros no tiene problemas. Y no, no me digas que un sitio como marc.info bloquea un de los mayores isp del mundo de meanera interesada porque no me lo creo. Tampoco creo que Telefónica lo haga a propósito, pero sí encuentro más verosímil un fallo de sus dns, de su caché o de sus rutas.
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.
Que no, que no ha "cortado nada". Yo creo que se centra sólo en sus servdiores dns.
Es más eficiente en recursos un timeout, o sea, no responder. Es lo que se hace en muchos cortafuegos. Muy maleducado, pero eficiente.
Psé.
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.
Yo creo que no. "Marc.info" ha estado funcionando desde siempre con Telefónica. Nunca he tenido problemas. Yo creo que se trata de un error temporal y totalmente circunstancial. 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
participants (4)
-
Camaleón
-
Carlos E. R.
-
Juan Erbes
-
lluis