Archivo de la etiqueta: dns

Vistas en un servidor DNS ó cómo resolver en función del cliente

Hoy voy a hablaros de algo que utilizo desde 2001 aproximadamente y que creo que cualquiera que trabaje en un entorno soho debería conocer ya que es la solución a todos sus problemas de resolución DNS, sin embargo he llegado a la conclusión de que es un completo desconocido. En esta situación nuestra infraestructura de red sería algo del estilo de la imagen que muestro a continuación.

SOHOEs decir, del router hacia adentro estamos en la red local de la oficina con direcciones privadas mientras que hacia el exterior se utiliza la IP pública del router, la que nos da nuestro proveedor de ADSL/Cable.

Supongamos ahora que por motivos de trabajo necesitamos que nuestro servidor responda ante algún dominio o subdominio de manera que desde el exterior se pueda acceder a determinados servicios que ofrecemos (y no, no queremos usar la IP directamente :P). Utilizando NAT configuramos el router para que las peticiones que le lleguen desde el exterior a determinados puertos las redirija al servidor.

En la imagen he pintado en rojo el camino que seguirían las solicitudes que llegan desde el exterior y en verde las que llegan de la propia red local. El problema habitual de un entorno de este tipo es que desde dentro de la red no se puede acceder al servidor con el nombre de dominio ya que la resolución devuelve una IP pública que está al otro lado del router, es decir, por simplificarlo un poco, el router no permite acceder desde el interior a los servicios que ofrece al exterior. Es simplemente un problema de interfaces y enrutamiento.

La solución pasa por convertir a nuestro servidor en el DNS principal de los usuarios de la red en vez de utilizar los que nos da nuestro proveedor, y configurar en él nuestro dominio de manera que dependiendo de quien lo interrogue nos devuelva la ip pública del router o la ip privada del servidor. Esto se puede hacer con las llamadas “vistas” de bind, imagino que en otros servidores DNS se podrán configurar del mismo modo.

Vale, creo que no he entendido nada de lo que has dicho. ¿Qué son esas vistas de las que hablas? Tranquilos que os lo explico.

Fíjate de nuevo en la imagen de arriba. Es obvio que los clientes que intentan acceder desde el exterior a nuestro servidor deberán utilizar la IP pública del router, NAT se encarga después de hacerlas llegar al servidor. Desde el interior es diferente, nuestras máquinas están en la misma red local que el servidor, sólo debemos saber la IP del servidor para acceder a él. Bien, pues esto es, a grandes rasgos, lo que hacen las vistas: si el cliente que me llama lo hace desde el exterior le digo la IP pública, si es desde el interior le digo la privada.

La configuración es extremadamente sencilla. Deberemos editar /etc/named.conf y hacer algo así:

#DNSINTERNO
view "internal" {
	match-clients { 192.168.0.0/24; 127.0.0.0/8; };
        zone  "dominio.com" {
                type master;
                file  "dominio.com.internal.zone";
        };
};
#DNSEXTERNO
view "external" {
        match-clients { any; };
        zone  "dominio.com" {
                type master;
                file  "dominio.com.external.zone";
        };
};

Eso es todo, sí, no hay más truco. El nombre de las vistas lo pones tú, algo que te permita identificar qué es cada una. Para cada vista le indicas qué clientes la verán y el archivo de zona con las resoluciones. Ya sólo nos falta configurar los clientes para que utilicen tu servidor DNS y preparar el dominio para que tu máquina local sea el servidor DNS mediante la IP pública.

Obviamente os he dado los detalles a grandes rasgos, a partir de ahí seguro que se os ocurren utilidades y combinaciones entre redes y subredes mucho más útiles. Al menos os ayudará a muchos a crear un entorno mucho más productivo y cómodo.

Centro de Sistemas de la Xunta de Galicia, las cosas bien hechas

Hace algo más de un mes recibí un email de Marcos avisándome que no podía enviar emails a cuentas del dominio xunta.es, a los diez días le venían rebotados con un error de conexión. Hasta entonces siempre había funcionado bien, pero llevaban ya unos días con el problema. Haciendo una análisis detallado desde el servidor obteníamos lo siguiente:

[osus@lerez ~]# dig xunta.es
; <<>> DiG 9.3.4-P1 <<>> xunta.es
;; global options: printcmd
;; connection timed out; no servers could be reached

[osus@lerez ~]# dig @85.91.64.171 xunta.es
; <<>> DiG 9.3.4-P1 <<>> @85.91.64.171 xunta.es
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached

[osus@lerez ~]# dig @85.91.64.172 xunta.es
; <<>> DiG 9.3.4-P1 <<>> @85.91.64.172 xunta.es
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

[osus@lerez ~]# ping 85.91.64.171
PING 85.91.64.171 (85.91.64.171) 56(84) bytes of data.
64 bytes from 85.91.64.171: icmp_seq=1 ttl=45 time=184 ms
--- 85.91.64.171 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 184.025/184.025/184.025/0.000 ms

[osus@lerez ~]# ping 85.91.64.172
PING 85.91.64.172 (85.91.64.172) 56(84) bytes of data.
64 bytes from 85.91.64.172: icmp_seq=1 ttl=45 time=173 ms
-- 85.91.64.172 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1000ms
rtt min/avg/max/mdev = 173.111/173.111/173.111/0.000 ms

[osus@lerez ~]# telnet 85.91.64.172 53
Trying 85.91.64.172...
Connected to 85.91.64.172 (85.91.64.172).
Escape character is '^]'.
Connection closed by foreign host.

Donde 85.91.64.171 y 85.91.64.172 son los servidores DNS de xunta.es.

Como se puede ver en el resultado de las pruebas, conectividad con los servidores DNS sí que había, respondían al ping, no había ningún tipo de bloqueo, sin embargo el servidor DNS no aceptaba nuestras solicitudes, con lo cual no podíamos resolver ningún host de xunta.es. Era ése precisamente el error que reportaba nuestro MTA cuando devolvía los emails, no se ha encontrado el servidor de destino (como no podía resolver los servidores MX asumía que el dominio no existía).

Decido entonces ponerme en contacto con el centro de sistemas y el primer mensaje no se me ocurre otra cosa que escribirlo con una cuenta desde la misma máquina que fallaba. Me llegó devuelto a los diez días tal como acabo de describir, pero me sirvió para ver con mis propios ojos el problema. Volví a escribir con una cuenta de otra máquina explicándoles el problema y las pruebas que os he copiado.

En un primer momento me contestan que, tras abrir una incidencia con el centro de gestión de red,  no tienen ningún problema de conectividad y que deberíamos tener acceso.

Abrín incidencia co centro de xestión de rede da Xunta de Galicia, e dinme que en principio non debería haber ningún problema co acceso ó noso servidor dende a vosa ip, polo que deberíades poder enviar sen problemas.

Entre otras cosas me indican, además, que haga una prueba de acceso al servidor de correo. Obviamente no han entendido bien que el problema es sólamente la resolución DNS, el resto funciona correctamente.

El 23 de noviembre vuelvo a escribirles explicando que el problema no es la conectividad, es sólo la resolución DNS y que al no poder resolver estamos cerrando a nuestra máquina cualquier host de xunta.es, adjuntando de nuevo las pruebas realizadas.

Unos días después me contestan que han hecho algunos cambios en sus DNS, que comprobemos si ya funciona, pero sigue sin hacerlo y así se lo hago saber el 1 de diciembre y les indico además, por si quieren hacer pruebas, el entorno (sistema operativo, versión de bind…).

10 días despues me contestan, atención:

Non me olvidei do voso problema co dns da Xunta… Simplemente comentarche que escalei a incidencia ó Centro de Xestión de Rede e como non me respostaran onte volvín a enviarlle a consulta e dinme que están preparando un escenario para reproducir o voso problema, porque en principio non hai ningún filtro no dns que impida que unha ip como a vosa realice consultas ó dns… Creo que van montar unha máquina cunha ip como a vosa para facer probas, mantereite informado dos progresos nas súas probas.

Es decir, que escalaron de nuevo la incidencia al centro de gestión de red y que, como no encontraban ningún problema,  iban a replicar nuestro entorno con nuestra misma IP para probar y ver in situ la situación.

Al día siguiente nos informan que, efectivamente, han visto el error que comentábamos y que nos avisarían cuando lo solucionasen. La verdad, temía que a ellos sí que les funcionase, pero no fue así.

Un par de días más tarde nos avisan que la incidencia está ya resuelta, que hagamos las pruebas oportunas para comprobarlo. En efecto, ahora todo volvía a funcionar correctamente.

En todo momento pensé que el problema iba a quedar sin solucionar, era bastante escéptico y creía que jamás se preocuparían por ver qué estaba pasando, sin embargo ocurrió todo lo contrario. Muchos centros de soporte y de sistemas deberían tomar nota y aprender de este caso. Hay ocasiones en que aunque parezca que tus sistemas están bien porque a todo el mundo le funcionan, puede haber algún caso aislado que presente una incidicencia que sea problema tuyo y no de él. El clásico “si a todo el muno le funciona es que funciona y si a uno no le va, será problema de él“, puede no ser siempre correcto, pero hay que molestarse en comprobarlo. Sé de buena tinta que en la inmensa mayoría de sitios habrían pasado de nosotros y mucho menos aún se habrían tomado las molestias de replicar nuestro escenario para comprobar lo que les contábamos.

Desde aquí dar las gracias a Silvia, la persona que se responsabilizó de nuestra incidencia y que puso todo su empeño en encontrar la solución, y agradecer a todo el Centro de Xestión de Rede de la Xunta de Galicia su colaboración y ayuda. No me han dicho el origen del problema, entiendo que puede ser información confidencial en cuanto a tipología de redes, firewalls, DMZ’s… pero el trabajo ha sido excelente.