Re: Problemas de resolución de nombres.
On Tue, Mar 27, 2001 at 07:57:40PM +0200, Francisco Callejo wrote:
> El nsswitch.conf es correcto, con esa línea incluida; el host.conf
> incluye también "order hosts, bind", y en /etc/hosts están los nombres
> de los dos ordenadores de la red. A pesar de todo, sigue dando
> problemas a la hora de pedir un servicio de un ordenador al otro.
> Resumo la situación:
>
> - Ordenador A: conectado a la línea RDSI, y con ipchains activado en
> un kernel 2.4.1. (con el módulo ipchains.o, no con iptables).
> - Ordenador B: conectado por tarjeta de red al ordenador A.
> - El ordenador A puede hacer peticiones al B tanto por nombre como por
> dirección IP (192.168.1.1).
> - El ordenador B puede hacer peticiones al A que no sean tcp (ping,
> traceroute) por nombre y por ip (192.168.1.2).
> - El ordenador B tiene en su tabla de rutas al A como gateway.
> - Si A está conectado a Internet, B puede hacer peticiones a A de
> servicios tcp por su nombre.
> - Si A _no_ está conectado a Internet, B sólo puede hacer peticiones
> tcp a A por ip. (También por nombre, pero tarda muchísimo en
> responder).
>
> Esta situación me ocurre desde hace unos días (anteriormente todo iba
> bien) y supongo que tendrá relación con algún .deb que haya instalado
> últimamente, pero no sé cuál. Los ficheros de configuración no los he
> tocado desde hace tiempo.
>
> Si a alguien se le ocurre algo, que me lo diga.
>
Desde ya, para evitar falsas esperanzas, NO tengo la solución, pero...
Te cuento.
Mi situación es practicamente idéntica a la tuya (conexión RDSI, ordenador
con linux haciendo de router y red interna 10/100, en mi caso con 6 máquinas)
y exactamente el mismo problema con la resolución de nombres.
Primera consideración: el problema no está relacionado con /etc/hosts, ni con
/etc/nsswitch.conf, ni con la versión del núcleo. Tu ejecutas kernels 2.4.x,
yo tengo todas las máquinas con kerlnels 2.2.14 y 2.2.18 (bueno, menos una que
tiene un minix, pero para el caso no cuenta)
Yo detecté el problema al instalar la ver. 0.17.x de los paquetes telnet y
telnetd en la máquina en la que trabajo habitualmente. En esta primera
actualización, si el router no estaba operativo, telnet no conectaba ni
proporcionando un nombre canónico ni proporcionando una dirección ip y telnetd
no admitía una conexión al no poder realizar una resolución inversa de la
dirección ip del cliente. Si el router estaba operativo, el cliente solicitaba
la resolución del nombre a los nameservers de mi ISP y al obtener contestación
negativa de estos por fin se dignaba mirar en /etc/nsswitch.conf. El servidor
(telnetd) realizaba su resolución inversa por el mismo procedimiento.
En una versión de telnet que bajé unos días después este había modificado su
comportamiento y permitía la conexión sin intentar resolución de nombres
cuando le proporcionaba directamente una dirección ip. El comportamiento del
telnetd seguía siendo el mismo. Cansado de esto, decidí downgradear a la ver.
0.16.x de estos paquetes y todo volvió a funcionar normalmente.
Investigando algo el tema en los archivos de listas de correo de debian, en
el bug tracking y en las news, lo único que pude obtener es un aviso de un
problema de seguridad referido al paquete libc6 que literalmente dice "If a
stuid program does not drop privileges before calling resolver functions,
arbitrary file on the system can be read by setting the RESOLV_HOST_CONF
environment variables", que es contestato por el mantenedor del paquete
informando que soluciona el problema (no se si provisionalmente) haciendo
que las funciones de la librería para resolución de nombres "try absolute
lookups first". No se si esto tiene que ver con el problema que tenemos, pero
si fuera así debería afectar a todos los programas que utilicen las funciones
de resolución de la libc6 2.2 posteriores a este "arreglo" (01-2001).
Saludos.
rlp
Reply to: