Problema con resolución de nombres y servicios
Hola, Al final decidí instalar Bind9 en un servidor local, con la idea de que se encargara de resolver las direcciones locales de la red y para acelerar las peticiones de salida a Internet. De momento todo va bien, el único problema que tengo es que de vez en cuando (de forma aleatoria, días sí, día no, día no, día sí...) deja de resolver (aparentemente, ahora lo explico) sólo en la red interna. Los equipos clientes (clientes con XP) están configurados para utilizar los siguientes datos: Servidor DNS: 192.168.0.1 << servidor con bind9 Si ejecuto en una estación cliente: nslookup dominio.local Recibo: host not found Pero si desde la misma estación cliente ejecuto: nslookup google.com Resuelve correctamente, a través de bind9 Problema: el servicio de correo, ftp... deja de reponder: smtp.dominio.local pop3.dominio.local ftp.dominio.local (host not found) En el registro no veo ningún error relacionado con ésto. Y los servicios están funcionando, porque si desde el equipo cliente ejecuto: telnet 192.168.0.1 25 Me responden Postfix, Cyrus o Vsftp según el puerto. Notas: - En el mismo servidor resuelve correctamente - Al cabo de x tiempo, sin hacer nada, vuelve a funcionar en el equipo cliente - Reiniciando named no se resuelve el problema - Ocurre de vez en cuando (no siempre) ¿Alguna idea? ¿Estará actualizando algún dato y por eso da ese error aleatorio? Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-22 a las 11:48 +0200, Camaleón escribió:
- En el mismo servidor resuelve correctamente - Al cabo de x tiempo, sin hacer nada, vuelve a funcionar en el equipo cliente
Pero el equipo cliente es un xp, ¿no? Tíralo :-P No, en serio, tendrías que reproducir el fallo en un linux para echarle la culpa al bind. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFE7XytTMYHG2NR9URAu75AJ9ZDFWuEmo7YtPHXkxXaroyxvCb8QCghPHK AUmRRgIR8dWss4QYqdtb0vk= =8u2o -----END PGP SIGNATURE-----
El 22/09/06, Carlos E. R. escribió:
Pero el equipo cliente es un xp, ¿no? Tíralo :-P
Vaya solución... mejor que tirarlos, "reconvertirlos" ¿no? ;-)
No, en serio, tendrías que reproducir el fallo en un linux para echarle la culpa al bind.
Bien, eso no es problema. Tengo un equipo en la red con SuSE 10.1, puedo probarlo ahí. Ahora ya ha vuelto a resolver con normalidad, es muy extraño, no he hecho nada. Lo volveré a probar en SuSE cuando me dé un error. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-22 a las 12:30 +0200, Camaleón escribió:
El 22/09/06, Carlos E. R. escribió:
Pero el equipo cliente es un xp, ¿no? Tíralo :-P
Vaya solución... mejor que tirarlos, "reconvertirlos" ¿no? ;-)
El xp, no el PC :-P
Ahora ya ha vuelto a resolver con normalidad, es muy extraño, no he hecho nada. Lo volveré a probar en SuSE cuando me dé un error.
Esperemos, entonces... ¿o si alguien conoce el error? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFE8KjtTMYHG2NR9URArlUAJwNgEcb4+TWvkae02uLtaCaYXYv3ACgiD4K Q7P7REDnnrMpBxwcYmBKxaU= =5/V8 -----END PGP SIGNATURE-----
El 22/09/06, Carlos E. R. escribió:
Esperemos, entonces... ¿o si alguien conoce el error?
Bueno, si aplicamos la "lógica difusa" error, error no es, porque "funciona" con la resolución de nombres remotos. ¬_¬ En cuanto vuelva a fallar lo pruebo en SuSE y pongo el resultado. Saludos, -- Camaleón
Ahora ya ha vuelto a resolver con normalidad, es muy extraño, no he hecho nada. Lo volveré a probar en SuSE cuando me dé un error.
Esperemos, entonces... ¿o si alguien conoce el error?
A mi no me suena de nada. Quizá, y solo quizá, podría tener que ver con las vistas de BIND, ya que indica que las externas las resuelve siempre. Pero es que es muy extraño, ya que lo lógico sería que fallara siempre o que funcionara siempre. De todas maneras, y para squivar el fallo, se podría reconfigurar el sistema para no utilizar subdominios con el nombre de dominio. de esta manera sustituyendo mail.dominio, ftp.dominio etc. por el número de la IP interna no se resolvería el problema pero se esquivarían sus efectos. -- Salutacions - Saludos, Josep M. Queralt
2006/9/22, Camaleón <noelamac@gmail.com>:
Hola,
hola [...]
Los equipos clientes (clientes con XP) están configurados para utilizar los siguientes datos:
Servidor DNS: 192.168.0.1 << servidor con bind9
tiene solamente a este servidor de nombres configurado ??? o algun otro ???
Si ejecuto en una estación cliente: nslookup dominio.local
Recibo: host not found
Pero si desde la misma estación cliente ejecuto: nslookup google.com
Resuelve correctamente, a través de bind9
mmm.. talvez este en el cache local y no este consultando realmente al dns que estas en 192.168.0.1 !!! en estes caso, deberias: - reiniciar el equipo con XP y intentar resolver nuevmante los dominios.. o bien, intentar resolver algun dominio que nunca hay resolvido antes, como por ejemplo: www.goolge.com.BR - dejar algun sniffer en el servidor y hacer las consultas desde el cliente y analisar se los paquetes estan llegando hasta el servidor y en caso positivo, analisar el contenido dos mismos.
Problema: el servicio de correo, ftp... deja de reponder:
smtp.dominio.local pop3.dominio.local ftp.dominio.local
(host not found)
con que TTLs configurastes el dominio.local ??? talvez, se colocas vuestros archivos de configuracion/registros por aca, alguien encuentre algo que pueda aclarar el problema. [...]
Notas:
- En el mismo servidor resuelve correctamente
mmm.... posiblemente sea problemas de comunicacion entonces entre cliente/servidor.. por esto, mencionaba sobre el cache local en los clientes.
- Al cabo de x tiempo, sin hacer nada, vuelve a funcionar en el equipo cliente
mmm.. esta la maquina conectada a internet ???? que te muestra top/iptraf y otros similares ???
- Reiniciando named no se resuelve el problema
talvez el cuello de botella este en otra parte !!!! el problema es en varias maquinas o solamente en este cliente XP ???
- Ocurre de vez en cuando (no siempre)
DoS dentro de vuestra red ??? ntop/iptraf/ethereal podrian ser de mucha ayuda.
¿Alguna idea? ¿Estará actualizando algún dato y por eso da ese error aleatorio?
mmm.. "creo", que es un problema, mas por el lado de la red y/o clientes.
Saludos,
salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
2006/9/22, Victor Hugo dos Santos:
tiene solamente a este servidor de nombres configurado ??? o algun otro ???
Es un servidor con dos tarjetas de red, configuradas ambas para responder en bind, pero sí, sólo existe este equipo como servidor DNS.
mmm.. talvez este en el cache local y no este consultando realmente al dns que estas en 192.168.0.1 !!!
en estes caso, deberias:
- reiniciar el equipo con XP y intentar resolver nuevmante los dominios.. o bien, intentar resolver algun dominio que nunca hay resolvido antes, como por ejemplo: www.goolge.com.BR
O.K. Tomo nota para probarlo en cuanto vuelva a dejar de responder. No sólo sucede en un equipo específico con Windows, sino en todos los equipos con Windows que hay en la red. Me falta probar con una SuSE 10.1 para ver si hace lo mismo que el resto de estaciones.
con que TTLs configurastes el dominio.local ??? talvez, se colocas vuestros archivos de configuracion/registros por aca, alguien encuentre algo que pueda aclarar el problema.
Aquí pongo el contenido de /var/lib/named/master/dominio.local % $TTL 2D @ IN SOA dominio.local. serv2.dominio.local. ( 2006090102 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum @ IN NS serv2 serv2.dominio.local IN A 192.168.0.1 serv2.dominio.local IN A 192.168.0.2 smtp IN A 192.168.0.1 pop3 IN A 192.168.0.1 smtp IN A 192.168.0.2 pop3 IN A 192.168.0.2 @ IN MX 10 smtp Y la resolución inversa: $TTL 2D @ IN SOA dominio.local. serv2.dominio.local. ( 2006090100 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum 0.168.192.in-addr.arpa. IN NS dominio.local 1.0.168.192.in-addr.arpa. IN PTR dominio.local 2.0.168.192.in-addr.arpa. IN PTR dominio.local
mmm.... posiblemente sea problemas de comunicacion entonces entre cliente/servidor.. por esto, mencionaba sobre el cache local en los clientes.
En el archivo hosts de Windows sólo aparece una línea: 127.0.0.1 localhost Voy a investigar dónde guardan estos datos de caché los equipos con XP.
mmm.. esta la maquina conectada a internet ????
El servidor con bind9, sí, está conectada. Las estaciones clientes también.
que te muestra top/iptraf y otros similares ???
Ningún proceso "anormal", lo volveré a ejecutar cuando me falle la resolución de nombres en los equipos.
talvez el cuello de botella este en otra parte !!!! el problema es en varias maquinas o solamente en este cliente XP ???
En varias estaciones, aparece el mismo error.
DoS dentro de vuestra red ??? ntop/iptraf/ethereal podrian ser de mucha ayuda.
No me asustes :-(
mmm.. "creo", que es un problema, mas por el lado de la red y/o clientes.
Vale, esperaré a que vuelva a fallar y el cliente con SuSE me indicará el camino... de momento estamos de acuerdo en echarle las culpas a los clientes, así que voy a investigar por ahí. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-22 a las 15:47 +0200, Camaleón escribió:
2006/9/22, Victor Hugo dos Santos:
tiene solamente a este servidor de nombres configurado ??? o algun otro ???
Es un servidor con dos tarjetas de red, configuradas ambas para responder en bind, pero sí, sólo existe este equipo como servidor DNS.
Creo que pregunta que si en windows le has dicho que pregunte a dos servidores dns. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFE+zZtTMYHG2NR9URAmbuAJ92dLyWxY1XRcEERyUjSPedaF7RswCffV0u Md+WPVwa/k01of2bXHEohJ8= =p6jG -----END PGP SIGNATURE-----
El 22/09/06, Carlos E. R. escribió:
Creo que pregunta que si en windows le has dicho que pregunte a dos servidores dns.
Ah, entonces sí, claro. El primario es 192.168.0.1 y el secundario el de Telefónica 80.58.0.33 Saludos, -- Camaleón
Entonces ahi se responde una de las dudas el primer mail.. Que no resuelve equipos locales pero sí externos...
Si ejecuto en una estación cliente: nslookup dominio.local
Recibo: host not found
Pero si desde la misma estación cliente ejecuto: nslookup google.com
Resuelve correctamente, a través de bind9
Pues en ambos casos al no encontrar respuesta del primer servidor DNS consulta al segundo.. Sé que eso ya lo sabías, pero como no se ha escrito aqui lo dejo para futuras consultas :D Saludos: Mau ----- Original Message ----- From: "Camaleón" <noelamac@gmail.com> To: "Lista SuSE (Novell)" <suse-linux-s@suse.com> Sent: Friday, September 22, 2006 8:28 AM Subject: Re: [suse-linux-s] Problema con resolución de nombres y servicios El 22/09/06, Carlos E. R. escribió:
Creo que pregunta que si en windows le has dicho que pregunte a dos servidores dns.
Ah, entonces sí, claro. El primario es 192.168.0.1 y el secundario el de Telefónica 80.58.0.33 Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 22/09/06, Mauricio Masís escribió:
Entonces ahi se responde una de las dudas el primer mail.. Que no resuelve equipos locales pero sí externos...
No, Mauricio, que esto me sucede sólo a veces, cada x minutos, funciona correctamente en el 95% de los casos.
Pues en ambos casos al no encontrar respuesta del primer servidor DNS consulta al segundo..
No, en ambos casos consulta al primero y "sólo" al primero. Este error parece más bien de los clientes Windows, nada tiene que ver lo que te pasaba... Saludos, -- Camaleón
ok, entonces retiro lo dicho. Saludos: Mau
El 22/09/06, Mauricio Masís escribió:
Entonces ahi se responde una de las dudas el primer mail.. Que no resuelve equipos locales pero sí externos...
No, Mauricio, que esto me sucede sólo a veces, cada x minutos, funciona correctamente en el 95% de los casos.
Pues en ambos casos al no encontrar respuesta del primer servidor DNS consulta al segundo..
No, en ambos casos consulta al primero y "sólo" al primero.
Este error parece más bien de los clientes Windows, nada tiene que ver lo que te pasaba...
Saludos,
-- Camaleón
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 22/09/06, Mauricio Masís Valverde escribió:
ok, entonces retiro lo dicho.
Hum, no lo retires tan pronto. Aunque el problema no parece tener relación con lo que te pasaba (esto es algo muy puntual, por ejemplo, hoy sólo me ha fallado durante unos minutos esta mañana), el correo de Carlos y el tuyo me han hecho pensar... En la configuración de named que hice en principio a través de Yast, había un apartado que preguntaba algo similar a que si el servidor dns (bind) no encontrada el nombre preguntara a otro servidor externo y ahí puse el del Teléfonica... por eso resolvía los nombres externos y no los locales, claro. Ahora sólo me queda saber por qué falla el servidor dns (o el cliente Windows) tanto en nombres locales como en remotos. Yo lo sigo observando, cuando falle lo probaré desde un cliente SuSE, a ver qué me dice. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-22 a las 16:28 +0200, Camaleón escribió:
Ah, entonces sí, claro. El primario es 192.168.0.1 y el secundario el de Telefónica 80.58.0.33
Si el primero falla o tarda demasiado preguntará al segundo, que no sabe nada del dominio local... Antiguamente, el windows hacía eso, siempre pregunta al primario hasta que falla y pregunta al secundario. No se si eso ha cambiado. Linux, en cambio, pregunta alternativamente a uno y a otro, por lo que en la misma confiuguración fallaría las consultas locales el 50% de las veces. El XP no se lo que hace, pero si lo hiciera al azar, ya tienes el motivo. Tienes que tener en cuenta ese detallito :-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFFAvOtTMYHG2NR9URAs+HAJ9efnVDgAwOF3ic+qCPtGP2HYWOSwCePot3 8n5xacE9dduycSaWBgiLL3o= =ZDhy -----END PGP SIGNATURE-----
El 22/09/06, Carlos E. R. escribió:
Si el primero falla o tarda demasiado preguntará al segundo, que no sabe nada del dominio local...
En este caso sólo pregunta al primero (SuSE). Y el servidor al que pregunta "no-sabe-no contesta", pero "no-sabe-no-contesta" sólo a direcciones locales, sí a direcciones externas.
Antiguamente, el windows hacía eso, siempre pregunta al primario hasta que falla y pregunta al secundario. No se si eso ha cambiado. Linux, en cambio, pregunta alternativamente a uno y a otro, por lo que en la misma confiuguración fallaría las consultas locales el 50% de las veces. El XP no se lo que hace, pero si lo hiciera al azar, ya tienes el motivo.
Me dejaría igual, porque lo que me interesa es saber por qué falla el primario, que el servidor dns en SuSE. Que no resuelva el de Telefónica es normal, es una dirección local, tiene que dar error. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-22 a las 18:22 +0200, Camaleón escribió:
Si el primero falla o tarda demasiado preguntará al segundo, que no sabe nada del dominio local...
En este caso sólo pregunta al primero (SuSE). Y el servidor al que pregunta "no-sabe-no contesta", pero "no-sabe-no-contesta" sólo a direcciones locales, sí a direcciones externas.
Podría estar fallando todas. Lo que pasa es que para las externas respondería el secundario, y no te darías cuenta. Para estar más cierto en el análisis, tendrías que dejar un XP con sólo el dns local. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFFA/ZtTMYHG2NR9URAu+EAJ4p/idAGnl0wCmgqkoQkYP8opvddACdEebn 7WJdwhj/YKuY/ZclIZSOVS8= =FYRF -----END PGP SIGNATURE-----
El 22/09/06, Carlos E. R.<robin.listas@telefonica.net> escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2006-09-22 a las 16:28 +0200, Camaleón escribió:
Ah, entonces sí, claro. El primario es 192.168.0.1 y el secundario el de Telefónica 80.58.0.33
Si el primero falla o tarda demasiado preguntará al segundo, que no sabe nada del dominio local...
esto si es cierto !!!! y por esto, en algunos momentos puedes resolver los dominios externos (goolge.com) y no los dominios internos (dominio.local), por que el cliente intentaba consultar al DNS que estaba dentro de vuestra red y este "por alguno" motivo que aun no sabemos, no respondía. Entonces consultaba al siguiente DNS (en este caso telefónica) y esta te contestaba correctamente para los dominios externos !!! pero lógicamente, no te contestaba para el dominio interno !!!! :(
Antiguamente, el windows hacía eso, siempre pregunta al primario hasta que falla y pregunta al secundario. No se si eso ha cambiado. Linux, en cambio, pregunta alternativamente a uno y a otro, por lo que en la misma confiuguración fallaría las consultas locales el 50% de las veces. El XP no se lo que hace, pero si lo hiciera al azar, ya tienes el motivo.
nooo.. te equivocas !!!! las consultas DNS de los clientes son echas en orden (de acuerdo a como configuraste en los clientes), por ejemplo: - agregue a mi archivo /etc/resolv.conf los servidores secundarios y terciarios (estará correcta esta palabra ???): nameserver 192.168.1.1 nameserver 200.72.1.254 nameserver 200.72.1.253 y hice unas 8 consultas a diversos sitios distintos (google.cl, google.com, google.es, google.com.br, intel.com, amd.com, entre otros) y todas las consultas, fueron echas directamente al servidor 192.168.1.1, en momento alguno se realizo consulta a los demás DNS !!! *************************** victor@gemini:~$ dig www.google.com ; <<>> DiG 9.3.2 <<>> www.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35330 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 0 [...] ;; Query time: 7 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Sep 25 11:06:16 2006 ;; MSG SIZE rcvd: 180 *************************** pero, deteni el DNS que esta en la maquina 192.168.1.1 y automaticamente se realizo consultas al servidor secundario *************************** ; <<>> DiG 9.3.2 <<>> www.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63504 ;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 6, ADDITIONAL: 6 [...] ;; Query time: 14 msec ;; SERVER: 200.72.1.254#53(200.72.1.254) ;; WHEN: Mon Sep 25 11:07:22 2006 ;; MSG SIZE rcvd: 292 *************************** en resumen, la orden en que pones los servidores DNS es muy, pero muy importante... primero debes de agregar los que son mas rapidos/cercano a vuestro pc y despues agregar otros "alternativos" caso el primero/segundo fallen !!! salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-25 a las 11:21 -0400, Victor Hugo dos Santos escribió:
y hice unas 8 consultas a diversos sitios distintos (google.cl, google.com, google.es, google.com.br, intel.com, amd.com, entre otros) y todas las consultas, fueron echas directamente al servidor 192.168.1.1, en momento alguno se realizo consulta a los demás DNS !!!
Ah, ok, tomo nota - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFGGS+tTMYHG2NR9URAq9hAKCBadLdlQSnNWroO8x6cA/U4Iyn4gCeIrWx ESRLeAy1aMzLOjjeQ3sSgFg= =qH93 -----END PGP SIGNATURE-----
2006/9/22, Camaleón <noelamac@gmail.com>:
2006/9/22, Victor Hugo dos Santos:
[...]
En el archivo hosts de Windows sólo aparece una línea:
127.0.0.1 localhost
Voy a investigar dónde guardan estos datos de caché los equipos con XP.
mmm.. esta la maquina conectada a internet ????
mmm.. el cache del dns en los clientes se queda unica y exclusivamente en alguna area de la memoria !!! seria algo ilogico (por perfomance) gardalo en disco por ejemplo !!! salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
2006/9/25, Victor Hugo dos Santos:
mmm.. el cache del dns en los clientes se queda unica y exclusivamente en alguna area de la memoria !!! seria algo ilogico (por perfomance) gardalo en disco por ejemplo !!!
La memoria virtual se guarda en disco... pero más bien pensaba en algún fichero de configuración de Windows donde se guardaran los datos de las direcciones que resuelve. De momento no me ha vuelto a fallar la resolución (o al menos no he notado nada), cuando vuelva a suceder lo primero que hago es verificar si SuSE funciona y después borrar la caché (ipconfig /flushdns) de los equipos con Windows para ver si ese es el problema. Saludos, -- Camaleón
2006/9/25, Camaleón:
De momento no me ha vuelto a fallar la resolución (o al menos no he notado nada), cuando vuelva a suceder lo primero que hago es verificar si SuSE funciona y después borrar la caché (ipconfig /flushdns) de los equipos con Windows para ver si ese es el problema.
Sólo para que quede en el hilo por si alguien se ve en la misma situación. Hoy se ha vuelto a repetir el error (un cliente Windows no podía enviar correo porque no encontraba el dominio -del tipo "smtp.dominio.local") y el cliente de correo decía: "no se ha encontrado el dominio...". En ese mismo cliente: Se ejecuta "nslookup dominio.local" y resuelve sin problemas. Se ejecuta "ping dominio.local" y reporta "host not found" Se ejecuta "telnet smtp.dominio.local 25" y reporta host not found. Se ejecuta "ipconfig /flushdns" (vaciar la caché dns) y sigue reportando el mismo error. Desde el equipo con SuSE no se produce ningún error, todos los comandos anteriores se ejecutan perfectamente. Acciones: - Bind9 estaba configurado para que respondiera con dos IPs diferentes. En el equipo cliente con Windows (que es el único que tiene problemas para resolver) se configura el servidor DNS con la primera de las direcciones IP que están configuradas en Bind y empieza a funcionar sin problemas la resolución de nombres en este cliente. :-O Como tenía pendiente cambiar la configuración de este servidor bajo "channel bonding" lo he cambiado para que ahora todos los servicios respondan sólo con una dirección IP (samba, postfix, named, dhcpd...), quizá ese fuera el problema que tenía el cliente Windows. Ahora está con la configuración en channel bonding, si vuelve a aparecer el mismo error pues ya no sabría por dónde atacar... Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-09-30 a las 21:13 +0200, Camaleón escribió:
Acciones:
- Bind9 estaba configurado para que respondiera con dos IPs diferentes. En el equipo cliente con Windows (que es el único que tiene problemas para resolver) se configura el servidor DNS con la primera de las direcciones IP que están configuradas en Bind y empieza a funcionar sin problemas la resolución de nombres en este cliente.
:-O
Y antes como lo tenías, ¿con las dos IPs quizás? No entiendo porqué tendría que fallar, pero bueno es saberlo. A lo mejor el bind no respondía en la segunda. Curioso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFH6VmtTMYHG2NR9URAvXGAJwMcJ3a9KOPeaz9xKlwMEJsjVizzQCcCc7X OFyeLlcA9K/RhR/kkcA7Tys= =Sc7t -----END PGP SIGNATURE-----
El 1/10/06, Carlos E. R. escribió:
Y antes como lo tenías, ¿con las dos IPs quizás?
Sí, en Bind9 tenía puestas las dos direcciones ip (192.168.0.1, 192.168.0.2) por si fallaba una... ahora con el "bonding" ya no hace falta.
No entiendo porqué tendría que fallar, pero bueno es saberlo. A lo mejor el bind no respondía en la segunda.
Yo tampoco. Es ese tipo de error que no deja rastro, que es muy específico y que ocurre de forma aleatoria (vamos, de los que fastidian). Pero al menos ha quedado claro que era cosa de los equipos con Windows, nada genérico relacionado con el demonio named. Saludos, -- Camaleón
2006/10/1, Camaleón:
Yo tampoco. Es ese tipo de error que no deja rastro, que es muy específico y que ocurre de forma aleatoria (vamos, de los que fastidian). Pero al menos ha quedado claro que era cosa de los equipos con Windows, nada genérico relacionado con el demonio named.
Bueno, pues vuelven a hacer lo mismo los equipos con Windows, y ahora Bind9 sólo escucha en una IP, por lo que estoy como al principio. Lo curioso es que al cambiar la dirección IP del servidor dns en los clientes con Windows vuelve a funcionar todo correctamente. Es como si al "actualizar" la los datos de la tarjeta de red volviera a funcionar bien. Suena a bug, tendré que investigarlo. Pues lo dejo como "pendiente", es algo que no me había pasado nunca con servidores dns externos (no locales como es éste) en clientes Windows. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-01 a las 17:54 +0200, Camaleón escribió:
Pues lo dejo como "pendiente", es algo que no me había pasado nunca con servidores dns externos (no locales como es éste) en clientes Windows.
¿cambio de mac? ¿reinicio de routers? Por divagar un poco. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFIBX7tTMYHG2NR9URAttJAJ9REXI9kGVqu99BZtGDgPaVDjfkSwCfU9rE z/+QSk6QwoNZM0jokIoESaY= =31NR -----END PGP SIGNATURE-----
El 1/10/06, Carlos E. R. escribió:
¿cambio de mac? ¿reinicio de routers? Por divagar un poco.
¿Dices cambiar de dirección mac la tarjeta de red de los clientes con Windows? ¿todos? Buff, no, prefiero que me llamen una vez a las tantas para decirme que no les funciona el correo local :-) No hay routers en la red local "para la red local", son equipos conectados a un switch, cortafuegos y router adsl. La comunicación con el servidor que tiene SuSE (named) es directa, no hay en medio ningún equipo ni servicio que pueda estar dando error. Yo lo veo raro porque no había configurado hasta ahora un equipo como servidor dns, siempre utilizaba los del isp para resolver y direcciones ip para los servicios de correo, etc... por eso quizá lo que yo veo extraño es normal y suele pasar, lo desconozco, por eso lo preguntaba por aquí, por si alguien se había visto en la misma situación... [off-topicazo] Venga, que van a empezar (en España) los últimos capítulos de la serie "24"... [/off-topicazo] Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-01 a las 21:53 +0200, Camaleón escribió:
[off-topicazo] Venga, que van a empezar (en España) los últimos capítulos de la serie "24"... [/off-topicazo]
La cagaste, me largo :-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFIB/3tTMYHG2NR9URAlw2AJ96mOfvmOGpqsqtnKy5sO+NFBxO1gCeJMCz X77S7yty6bCJYFsRIBMmPWk= =b71e -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-01 a las 21:53 +0200, Camaleón escribió:
El 1/10/06, Carlos E. R. escribió:
¿cambio de mac? ¿reinicio de routers? Por divagar un poco.
¿Dices cambiar de dirección mac la tarjeta de red de los clientes con Windows? ¿todos? Buff, no, prefiero que me llamen una vez a las tantas para decirme que no les funciona el correo local :-)
No, digo que si habrá cambiado alguna por si misma.
Yo lo veo raro porque no había configurado hasta ahora un equipo como servidor dns, siempre utilizaba los del isp para resolver y direcciones ip para los servicios de correo, etc... por eso quizá lo que yo veo extraño es normal y suele pasar, lo desconozco, por eso lo preguntaba por aquí, por si alguien se había visto en la misma situación...
Pues no lo se. Pero si que me suena haber oído algún problema relacionado con windows respecto al named, pero no puedo recordar que. Busca en el archivo de la lista inglesa, igual aparece...
[off-topicazo] Venga, que van a empezar (en España) los últimos capítulos de la serie "24"...
Jo, ahora que tenían al presi en el trullo, van y la cagan. Ya tenemos para cuatro episodios más :-P [...] Ah, menos mal, se lo han cargado, pero ahora tenemos para otros veinte con el barquito :-P
[/off-topicazo]
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFIW60tTMYHG2NR9URAnryAJ0bfZxnM/5ZXbKKipDC33RXNvJd+ACgksi5 qUjpeCT4yHV9PXCnMU+CdE0= =TT0T -----END PGP SIGNATURE-----
2006/10/1, Camaleón <noelamac@gmail.com>:
2006/10/1, Camaleón:
Yo tampoco. Es ese tipo de error que no deja rastro, que es muy específico y que ocurre de forma aleatoria (vamos, de los que fastidian). Pero al menos ha quedado claro que era cosa de los equipos con Windows, nada genérico relacionado con el demonio named.
Bueno, pues vuelven a hacer lo mismo los equipos con Windows, y ahora Bind9 sólo escucha en una IP, por lo que estoy como al principio. Lo curioso es que al cambiar la dirección IP del servidor dns en los clientes con Windows vuelve a funcionar todo correctamente. Es como si al "actualizar" la los datos de la tarjeta de red volviera a funcionar bien. Suena a bug, tendré que investigarlo.
insisto.. instala alguno sniffer (ettercap, para consola es muy bueno) en la red, de manera que puedas capturar el trafico entre el cliente y el servidor.. esto te ayudara a "descubrir" que es lo q pasa !!! por cierto.. que tarjetas de redes tienes en los clientes/servidores ??? algunas (dlink, sys900, realtek) se marean muy facil y se presentan problemas de comunicacion que luego se funcionan nuevamente!!! mmm.. pero en todo caso, los problemas de comunicacion que menciono son totales y no solamente con un o otro servicio !!! pero mismo asi, dejo nota !!! :-) salu2 y mantenganos informados. -- -- Victor Hugo dos Santos Linux Counter #224399
2006/10/4, Victor Hugo dos Santos:
insisto.. instala alguno sniffer (ettercap, para consola es muy bueno) en la red, de manera que puedas capturar el trafico entre el cliente y el servidor.. esto te ayudara a "descubrir" que es lo q pasa !!!
Lo que pasa sólo les pasa a los clientes Windows, lo cual es un problema menor (pensaba que algo estaba mal configurado en el servidor bind).
por cierto.. que tarjetas de redes tienes en los clientes/servidores ???
Los clientes tienen dos Gigabit, pero sólo tienen una activada (¿se podría hacer "channel bonding en Windows" :-D?). La que utilizan es una Intel integrada en placa, modelo Intel 82573V. La otra disponible es una Realtek. El servidor con named tiene dos Gigabite Intel (módulo e1000), modelo Intel 82541GI.
algunas (dlink, sys900, realtek) se marean muy facil y se presentan problemas de comunicacion que luego se funcionan nuevamente!!! mmm.. pero en todo caso, los problemas de comunicacion que menciono son totales y no solamente con un o otro servicio !!! pero mismo asi, dejo nota !!! :-)
Tomo nota. Carlos comentó que recordaba un mensaje similar en la lista inglesa. Yo encontré este hilo* donde comentan algo al respecto. En otro mensaje** enlazan con artículo de KB de MS pero también probé lo del "ipconfig /flushdns" y no tuvo resultado. Deshabilitar el caché dns de los equipos con Windows no me hace mucha gracia porque son varios clientes... * http://lists.suse.com/archive/suse-slox-e/2005-Apr/0001.html ** http://lists.suse.com/archive/suse-slox-e/2005-Apr/0005.html Saludos, -- Camaleón
participants (6)
-
Camaleón -
Carlos E. R. -
Josep M. Queralt -
Mauricio Masís -
Mauricio Masís Valverde
-
Victor Hugo dos Santos