[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cómo funcionan varios DNS en /etc/resolv.conf



El 5 de noviembre de 2019 13:00:09 CET, Debian <javier.debian.bb.ar@gmail.com> escribió:
>El 4/11/19 a las 14:33, Ramses escribió:
>> Hola a tod@s,
>> 
>> Yo tenía entendido que en Linux, tener varios DNS en /etc/resolv.conf
>funcionaba de la siguiente forma. Por ejemplo, en el /etc/resolv.conf
>lo siguiente:
>> 
>> nameserver 1.1.1.1
>> nameserver 2.2.2.2
>> nameserver 3.3.3.3
>> 
>> Pensé que si buscamos una máquina "maquina.pruebas.org":
>> 
>> - La buscaba en el /etc/hosts
>> - Si no la encontraba, la buscaba en el 1.1.1.1
>> - Si no la encontraba, la buscaba en el 2.2.2.2
>> - Si no la encontraba, la buscaba en el 3.3.3.3
>> - Y si tampo la encontraba, daba el error de que no existe esa
>máquina.
>> 
>> Al contrario que hace Windows, que mientras que esté vivo el primero
>de los DNS, no busca en el siguiente si no existe la máquina en este
>primer Servidor DNS.
>> 
>> ¿Estoy equivocado con esta creencia mía?
>> 
>> 
>> Saludos y gracias,
>> 
>> Ramsés
>> 
>
>
>Sí, pero más o menos.
>El tema es largo.
>
>Tu problema no es resolv.conf, tu problema es enrutamiento.
>
>man route
>
>Primero, /etc/resolv.conf funciona de dos maneras y tiene sus
>limitaciones.
>Por compilación del kernel, sólo puede manejar hasta 3 DNS y 2 dominios
>
>de búsqueda; si querés agregar más, debés recompilar el núcleo a mano; 
>no lo aconsejo. Además, en general, con 3 alcanza, pues rara vez tienes
>
>más de 3 interfaces de red, conectadas a 3 redes distintas.
>
>Por otra parte, resolv.conf funciona en forma estática o dinámica.
>La estática, es la que creo estás usando vos, metiendo dedos en el
>archivo.
>La dinámica, es manejada por el paquete resolvconf.
># apt install resolvconf.
>
>Esta última se configura con cada reinicio de su respectivo demonio. 
>Fijate si no lo tenés corriendo con
># systemctl status resolvconf.
>
>Este demonio se controla a través de sus archivos de configuración 
>/etc/resolvconf, y/o a través de instrucciones dinámicas que se cuelgan
>
>en el archivo /etc/network/interfaces.
>
>Un tema MUY importante: si manejás varias redes, asegurate que las 
>mismas estén es segmentos distintos, que me parece que es lo que te
>está 
>pasando.
>
>Por ejemplo, te copio lo que yo tengo colgado para manejar dos redes en
>
>segmentos distintos, y que además, para evitar colisiones, está 
>configurado el ruteo de redes sobre cada una de las interfaces.
>Es fundamental que el DNS de tu VPN esté bien configurado, y recuerda 
>que en una VPN, los servidores deben estar con direcciones estáticas y 
>los usuarios con dinámicas.
>
>Lo que está escrito después de => no hay que agregarlo al archivo, lo 
>escribo ahora para que sepas qué hace.
>
>/etc/network/interfaces
>======================================================
># This file describes the network interfaces available on your system
># and how to activate them. For more information, see interfaces(5).
>
>source /etc/network/interfaces.d/*
>
># The loopback network interface
>auto lo
>iface lo inet loopback
>
>
># EMPRESA => esta es la VPN
>auto enp2s0
>  allow-hotplug enp2s0
>  iface enp2s0 inet dhcp
>  hostname userw39  => el nombre de host para la red de mi empresa
>  dns-nameserver 10.115.1.201 => DNS de la VPN de la empresa
>  dns-search mi.empresa => dominio de la empresa
>
># Internet
>auto enp3s0
>  allow-hotplug enp3s0
>  iface enp3s0 inet dhcp
>  hostname jap => el nombre de host con que salgo a internet
>  dns-nameserver 192.168.13.1 => DNS del enrutador que sale a internet
>  dns-nameserver 8.8.8.8 => DNS de Google
>
># Enrutamiento => Fuerza a cada interfaz a ceñirse a un segmento 
>específico. Lo que está en el segmento de la empresa, va por la
>interfaz 
>enp2s0, el resto sale por internet a la enp3s0.
>
>  post-up ip route change default via 192.168.13.1 dev enp3s0
> post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.112.1.254 dev 
>enp2s0
>
># Enrutamiento =>  estos son dos servidores que uso mucho, y al
>ponerlos 
>en forma estricta, no busca en los DNS pues tiene la ruta explícita.
>
>post-up route add -host 10.1.0.231 gw 10.112.1.254 dev enp2s0
>post-up route add -host 10.1.12.201 gw 10.112.1.254 dev enp2s0
>
>========================
>
>Espero te sirva.
>
>JAP

JAP, gracias por contestar. 

No, no es un problema de enrutamiento, es un problema de resolución, ya que son redes distintas con DNS's distintos. De hecho, si tiro un Ping a cualquier IP de cualquier máquina de las redes a las que quiero llegar, responden sin problemas, el tema está en que si intento acceder por el nombre FQDN, siempre me lo intenta resolver el Primer Servidor DNS establecido en el "/etc/resolv.conf", que es el de mi LAN y, evidentemente, las máquinas de la otra red o redes, no las tengo definidas en mi Servidor DNS, por lo que la respuesta del DNS es que no existen esas máquinas. 

El dominio, o dominios, de las otras redes son internos, a las que llego a través de VPN's Site-to-Site, y como he comentado, lo que tengo como Primer Servidor DNS, tanto en el DHCP Server como en los Clientes VPN, es un Servidor DNS BIND9, el de mi LAN, que administro yo, por lo que he optado por tocar la configuración de éste metiendo en el "named.conf.local" lo siguiente:

zone "paco.org" {
    type forward;
    forwarders { 1.1.1.1; };
};

zone "pepe.org" {
    type forward;
    forwarders { 2.2.2.2; };
};

Por lo tanto, cuando busque un FQDN del dominio "paco.org" manda la petición de resolución a un DNS y cuando es del dominio "pepe.org" lo manda al otro. 

Todo funcionando. 

Lo estaba intentando solucionar desde la parte del Cliente, pero esta parece ser la solución más "limpia".

Con 3 líneas, solucionado... 

Espero que les sirva. 

No sé si a alguien se le ocurre una mejor opción. 


Saludos y gracias, 

Ramsés


Reply to: