¿Qué es DNS?
“El DNS (Domain Name System) es un conjunto de protocolos y servicios (base de datos distribuida) que permite a los usuarios utilizar nombres en vez de tener que recordar direcciones IP numéricas. Ésta es ciertamente la función más conocida de los protocolos DNS: la asignación de nombres a direcciones IP. Por ejemplo, si la dirección IP del sitio FTP de prox.ve es 200.64.128.4, la mayoría de la gente llega a este equipo especificando ftp.prox.ve y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas razones, sin que tenga que cambiar el nombre.
Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS.TXT que contenía todos los nombres de dominio conocidos. (técnicamente, este archivo aun existe - la mayoría de los sistemas operativos actuales todavía pueden ser configurados para chequear su archivo hosts).
El crecimiento explosivo de la red causó que el sistema de nombres centralizado en el archivo HOSTS.TXT resultara impráctico y en 1983, Paul Mockapetris publicó los RFCs 882 y 883 definiendo lo que hoy en día ha evolucionado al DNS moderno. (Estos RFCs han quedado obsoletos por la publicación en 1987 de los RFCs 1034 y 1035).“
¿Qué es BIND?
“BIND (Berkeley Internet Name Domain) es el servidor DNS más usado en Internet. Fue creado por Paul Vixie en 1988 a partir de un proyecto en la Universidad de Berkeley y cuenta con el apoyo de la Internet Systems Consortium. Sus orígenes se remontan al sistema operativo UNIX pero con el tiempo se ha implementado en otros sistemas operativos. Actualmente hay dos versiones soportadas: BIND 8 y BIND 9.”
De estas definiciones concluimos que BIND será nuestro servidor DNS.
Ya que es uno de los mejores programas que existen para tal fin.
Pero que es DNS entonces?
En pocas palabras un servidor DNS me permitirá hacer la resolución de nombres a direcciones IP’s dentro de mi red interna y hacia el exterior.
Como todos ya saben, siempre que usamos Internet con cualquier fin, usamos nombres de dominios que nos es fácil recordar. Esos nombres de dominios no son comprendidos por las computadoras que habitan Internet o al menos no directamente. Para poder que una estación reconozca un nombre de dominio y sepa que hacer con él, necesita una forma en convertirla a una dirección numérica con la que puede trabajar. Por eso al inicio del curso usábamos el archivo /etc/hosts para simular la resolución de nuestro nombre de dominio www.curso-servidores.edu.co. Hasta ahí todo estaba muy bien, pero que sucede cuando existen muchas mas estaciones dentro de nuestra red, o queremos que desde la red interna se salga hacia Internet?.
No podríamos configurar cada dirección IP que quisiéramos consultar en Internet.
Por eso existen los servidores DNS, que nos permiten automatizar la resolución de nombres de dominios e interconectarse con otros servidores DNS que hacen la misma labor.
La resolución de nombres se puede hacer en dos sentidos, directa e inversa.
Estas dos palabras son comunes sin importar el sistema DNS que estemos trabajando. Hacen referencia a la resolución:
DOMINIO à IP (Resolución directa)
o
IP à DOMINIO (Resolución inversa)
Un servidor DNS puede funcionar en ambas formas o solo en una de ellas, esto depende de lo que se quiera lograr con su configuración.
¿Qué se necesita?
Para configurar un servidor DNS no hace falta mas que el software DNS y mucho cuidado en l momento de hacer las configuraciones. A veces por descuido las configuraciones se toman mas tiempo del estimado.
Básicamente haremos lo siguiente:
-Definir las zonas de trabajo.
-Configurar el archivo principal del DNS.
-Configurar las zonas.
-Reiniciar el servicio DNS.
-Hacer pruebas de resolución de nombres e IP’s.
Algo de teoría . . .
Antes de proceder a la configuración, expliquemos que son las zonas.
Las zonas son agrupaciones lógicas de redes o dominios que BIND controlará. Esto significa que dentro de una red, podré definir diferentes zonas para las que quiera hacer resolución de nombres.
Una zona puede estar representada por: 192.168.0.0/24.
Esto querrá decir que BIND hará resoluciones en ese rango de direcciones IP.
Una zona puede estar definida por ejemplo por: curso-servidores.edu.co
Lo que indica que BIND hará la resolución de nombres para los hosts dentro de ese dominio.
Normalmente tendremos solo unas pocas zonas y tendremos las respectivas zonas inversas.
Existe una zona especial, llamada zona caché (así como el caché del SQUID). Esta zona caché como ya debe suponer, permite que el DNS haga caché de las peticiones más comunes y por lo tanto mejore la respuesta en la resolución de nombres. No es necesario que nuestro DNS haga caché, pero si tenemos muchos usuarios dentro de nuestra red haciendo consulta hacía Internet se debería considerar.
DNS funciona de forma jerárquica, esto quiere decir que la estructura que mantiene y la forma como lleva a cabo las resoluciones se hace partiendo desde el mismo punto y se expande como ramas de árboles dependiendo de la resolución que quiera hacer. Hablemos un poco mas sobre esto.
Existen clasificaciones para los dominios más comunes.
Dominios territoriales
Los dominios territoriales son aquellos que se le asignan a cada país, por ejemplo:
.uk, .co , .ve ,.us, cada uno indica que se trata de un país, ya todos sabemos que nuestro dominio territorial es .co.
Dominios primarios
Los dominios primarios son dominios de uso comun y que son ampliamente conocidos, esto son: .com, .net, .edu, .org, .gov, .mil, .info, el dominio mas conocido por todos es el .com, que asocia todas las compañías que son comerciales y los .org que son organizaciones sin animo de lucro.
Luego están los dominios secundarios que conocemos como nuestros dominios y son los que podemos comprar a través de los sitios de Internet que venden y negocian con estos. Son los dominios que tenemos para nuestras empresas, instituciones y demás. Por ejemplo:
Sena.edu.co
empresa-internet.com
curso-servidores.edu.co
Estos dominios son mas o menos difíciles de conseguir dependiendo del nombre que se use y del tipo de organización que lo requiera.
En Colombia el sitio www.nic.co gestionado por la Universidad de los Andes de Bogota se encarga de la asignación de dominios a todo el territorio nacional.
Será mucho mas fácil conseguir un dominio empresas.com.co que un dominio empresaX.edu.co, esto porque los dominios .edu.co, .gov.co, .mil.co, .org.co son restringidos para organizaciones que cumplan con ciertos requisitos.
Sin embargo si usted esta interesado en adquirir un dominio puede comunicarse con ellos y tramitarlo.
Cuando al DNS se le pide que resuelva un dominio como:
Realmente se le esta pidiendo la dirección IP del host www del dominio google.com.
El orden de jerarquia le indica al servidor DNS que se debe conectar con otros servidores DNS para averiguar la información de todos los dominios primarios .com, Entonces localizará el dominio secundario que tiene la información de la zona google.com y le pasará la consulta a este.
Cuando el servidor DNS encargado de la zona google.com recibe la petición, resuelve la dirección para el host www buscando en su base de datos y devuelve una respuesta. Esta respuesta viaja nuevamente entre los servidores utilizados para establecer la comunicación y finalmente llega a la estación del usuario que realizó la consulta.
Esto podría entenderse como un proceso lento, pero realmente es tan rápido que es transparente para el usuario que abre su navegador y digita www.google.com.
Gracias a los servidores DNS, Internet puede funcionar, si nó, debería existir otro método que permitiera conocer la dirección IP de cualquier servidor en cualquier lugar del mundo sin necesidad de hacer cadenas de peticiones DNS.
Configuración:
Para hacer nuestro ejemplo en el curso, crearemos una zona directa y una zona inversa que harán resolución de nombres para el dominio:
curso.servidores.edu.co.
El servidor BIND que trae SUSE 9.2 por defecto es la versión 9, se asume que usted debe tenerlo instalado en el sistema ahora mismo. Si tiene una versión de BIND diferente debe asociar las configuraciones con las de su versión, regularmente no es tan difícil hacerlo.
Existe un fichero de configuración ubicado normalmente en: /etc/named.conf.
Que contiene la información principal del demonio dns, Este archivo tiene parámetros que se deben configurar según nuestras necesidades.
Al inicio del archivo verá algo como:
options {
directory "/var/lib/named";
…
Estas son las definiciones de las opciones con las que el BIND trabajará.
Retomemos los parámetros principales:
directory
Normalmente no lo cambiaremos de valor a menos que deseemos que todos los archivos de zona de BIND sean almacenados en un lugar diferente.
forwarders
Me especifica los servidores DNS a los que deberia reenviar las consultas. Esto es util si nuestro DNS casi no tiene caché y tenemos información de otros servidores que puedan hacer las resoluciones más rapido, por ejemplo, los servidores DNS de un ISP. Ejemplo:
forwarders { 200.13.x.x ; 200.14.x.x; };
Todos los DNS se separan por punto y comas. Se esta asumiendo que esas IP’s corresponden a los DNS de nuestro ISP.
forward first
Esta opción se relaciona con la anterior y quiere decir que primero intente enviar la petición a los servidores configurados antes de intentar resolverla por si mismo. Si esta opción no aparece o esta comentada, nuestro servidor DNS intentará resolver primero la dirección y en caso de no poder hacerlo la reenviará a los servidores DNS configurados en forwarders.
Estas son las opciones más comunes para configurar un DNS.
}; // se cierra la sección de opciones.
En otra sección más adelante encontraremos la definición de los archivos de zona.
Estos bloques se especifican según la siguiente sintaxis:
zone "[NOMBRE ZONA]" {
type [TIPO DE ZONA];
file "[ARCHIVO DE ZONA]";
};
[NOMBRE ZONA]
Este campo me especifica como se llamará nuestra zona. Es muy importante saber definir el nombre puesto que no se puede configurar cualquier nombre al azar. Esta estrechamente relacionado con el tipo de resolución que se quiera hacer.
[TIPO DE ZONA]
Este campo me indica si la zona será maestra, esclava o de caché.
La zona de caché como lo ya lo sabiamos me permite hacer caché a traves de varios servidores DNS. Normalmente se usan para este fin los servidores raiz de Internet (Los principales, ubicados en puntos estratégicos del mundo).
La zona maestra me permite que el DNS controle la información para esta zona y sea el encargado directo de la misma.
La zona esclava, como su nombre lo dice, le servirá a la maestra en la labor de resolver direcciones. Esta zona depende de la información que le replique la zona maestra y por eso lleva un parámetro adicional donde se configura quienes son los servidores maestros.
[ARCHIVO DE ZONA]
El archivo de zona contiene la información real de nuestra zona, aquí se creará la base de datos para la resolución de hosts dentro de esta zona.
Veamos unos ejemplos:
Zona caché
zone "." {
type hint;
file "root.hint";
};
Esta zona se denota por un punto, es conocida como la zona caché, raiz o punto.
Esta zona tiene un archivo de configuración nombrado en la variable file cuyo contenido normalmente es la lista de los servidores DNS principales de Internet. Esta declaración es requerida cuando queremos que nuestro DNS se actualice a por medio de estos servidores y guarde un caché de las ultimas resoluciones a través de los mismos.
Zona Maestra
zone "curso-servidores.edu.co" {
type master;
file "curso-servidores.bd";
};
Esta zona es maestra y el nombre de la zona debe ser el dominio con el que vamos a trabajar. Se define como tipo maestra y se le asigna un nombre al archivo donde estará la configuración. El nombre del archivo de configuración carece de importancia, pero siempre se recomienda una palabra que pueda ser referenciado rápidamente.
Zona Maestra Inversa
zone "0.168.192.in-addr.arpa" {
type master;
file "curso-servidores-inverso.db";
};
Supongamos que nuestro dominio curso-servidores.edu.co esta asociado al rango 192.168.0.0/24. Necesitaremos crear una zona inversa para nuestro dominio.
Observer el nombre usado en a configuración, este nombre debe ser de esta forma y debe evitarse poner cualquier otro nombre que no corresponda al rango real de trabajo de la zona DNS principal.
Si observa bien el nombre, verá que se trata del mismo rango IP, pero al revez. Esto es porque así lo entiende BIND y así lo debemos configurar.
Si nuestro rango de trabajo es: 192.168.0.0/24, el nombre para nuestra zona inversa debe ser:
0.168.192.in-addr.arpa
El resto del nombre .in-addr.arpa debe ser agregado después de poner el rango de IP’s al revez menos el ultimo digito.
Note que el ultimo digito no aparece y es porque a estas direcciones serán a las que les haremos resolución en el archivo especificado en la variable file.
Una vez mas, este nombre de archivo no interesa, lo que nos interesa es que configuración tenga adentro.
Zona Esclava
zone "curso-servidores.edu.co" {
type slave;
file "curso-servidores-esclava.db";
masters {
192.168.0.100;
};
};
En esta zona esclava se realiza la misma configuración como se explico en la zona maestra. La unica diferencia es que en el parámetro type se especifica que es esclava y se agrega como lo habiamos mencionado una sección:
masters {
[SERVIDOR DNS MAESTRO];
};
[SERVIDOR DNS MAESTRO]
Contiene la dirección o direcciones IP’s (separadas por punto y coma) de los servidores maestros de los cuales tomará información la zona esclava.
Zona Esclava Inversa
zone "0.168.192.in-addr.arpa" {
type slave;
file "curso-servidores-esclava-inversa.db";
masters {
192.168.0.100;
};
};
Ahora conoce las posibilidades de zonas con las que trabaja BIND. Seguramente encontrará en el archivo de configuración zonas por defecto haciendo resolución de nombres locales (para el host localhost). Revise esta configuración y analice como funciona.
Ahora procederemos a configurar las zonas para nuestro servidor DNS, pero antes veamos que configuración tienen estos archivos:
Zonas Directas
permite hacer la resolución inversa de DOMINIO direcciones (IP à ).
Este es el archivo de configuración genérico para una zona directa, aquí se especifican varios parámetros importantes, pero más importantes aún son los registros de recursos que son los que verdaderamente le dan la funcionalidad al DNS.
Lo registros de recurso (R.R) indican como hacer algo. En este archivo modelo vemos los más importantes y se explican a continuación:
SOA
Significa Start Of Authority, es un recurso obligatorio, especifica para cual zona o cual dominio (si se trata de un dominio) el DNS tiene autoridad de responder a las peticiones DNS que se le hagan. Siempre debe encabezar el archivo de zona después de la variable $TTL que especifica cuanto tiempo es valida la información que el DNS replique.
La sintaxis de la linea de SOA es como se ve en el ejemplo. Se requiere configurar el host donde se encuentra, el dominio en el que esta trabajando y una cuenta de correo válida para cuando se presenten problemas graves. Observe que el correo no tiene @, si no un punto. Esto es porque la @ dentro del archivo de configuración significa el nombre de la zona con el que se esta trabajando.
BIND reemplazará (de forma transparente para el administrador) la @ por el nombre de la zona configurado en el archivo principal del DNS. Ejemplo:
@ IN SOA www.curso-servidores.edu.co. root.curso-servidores.edu.co.
A
El registro de recursos A, es el mas utilizado puesto que permite la resolución directa de un nombre a una IP. Como se ve en el archivo modelo, ingresamos al lado izquierdo un HOST y después del registro de recursos A agregamos la IP correspondiente al HOST. Ejemplo:
www IN A 192.168.0.100
NS
El registro de recursos NS me permite especificar el servidor DNS que usará la zona que estamos configurando. Normalmente será nuestra propia IP o nuestro propio nombre al que le agregaremos también un registro A. Ejemplo:
curso-servidores.edu.co. IN NS ns.curso-servidores.edu.co.
MX
El registro MX tiene utilidad cuando estamos manejando dentro del dominio un servidor de correos. Este registro especifica quien será el Mail Exchanger para nuestro dominio, esto es, quien estará encargado de recibir todos los correos enviados a los usuarios de nuestro dominio. Si usted no tiene un servidor de correo aún dentro de su zona, no configure este registro de recursos.
La sintaxis es un poco diferente ya que agrega un campo más llamado la prioridad. Por ejemplo:
@ IN MX 10 correo-principal.dominio.com.
@ IN MX 20 correo-secundario.dominio.com.
En caso que se quieran tener servidores de correo de respaldo dentro de la misma zona. Especificaremos la prioridad (dada por un numero entero cualquiera) que tendrá ese servidor de correo. BIND buscará por el numero entero mas pequeño (10) y ese servidor de correo lo tomará como el principal. Si por algún motivo el servidor principal deja de funcionar, el secundario (20) o los otros definidos en registros MX entrarán a reemplazarlo según el orden de prioridades (el numero mas bajo).
El nombre usado para el servidor de correo debe tener asociado un registro A para la resolución de su IP, NUNCA un registro CNAME.
CNAME
Este registro me permite definir alias para los hosts de la zona que este configurando. Por ejemplo:
www IN A 192.168.0.100
ftp IN CNAME www
esta configuración le dice al servidor DNS que existe un equipo llamado www, que tiene asociada la IP 192.168.0.100 y que existe un host llamado ftp que es el mismo equipo www, y por lo tanto es un alias (una manera diferente de llamarlo).
La creación de alias es util cuando queremos tener nombres diferentes para trabajar con un solo equipo. Por ejemplo si en nuestro servidor están configurados la mayoría de servicios, podríamos tener un nombre principal www y tener alias para : correo, ftp, proxy, dhcp, firewall, etc. Para todos los hosts que deseemos que existan sin necesidad de usar otros equipos o asignar otras IP’s.
Si ha sido buen observador se ha dado cuenta de algo que es MUY importante en BIND y tiene que ver con un PUNTO (.).
En algunos nombres de hosts o dominios aparece un PUNTO al final. BIND necesita que el punto exista al final si el nombre no ha sido completamente definido, esto es, tiene un nombre y todo el dominio. Si solo se tiene el nombre (por ejemplo www), BIND adicionará automáticamente en el momento en que inicie su funcionamiento el resto del dominio a ese nombre.
Por eso debemos asegurarnos que existe un PUNTO al final de cada dominio cuando haya sido escrito completamente y evitar ponerle puntos a los nombres a los que no se les ha puesto el dominio.
Esto es algo vital, se evitará muchos dolores de cabeza si tiene en cuenta esta advertencia. Para que le quede claro, revise los ejemplos y el modelo del archivo anterior.
Los parámetros que aparecen en la configuración:
Serial, refresh, retry, expire , ttl, son parámetros que por defecto funcionan y estan relacionados por el tiempo que dura la información enviada por el servidor DNS a estaciones remotas, si quiere saber más sobre ellos, visite los enlaces que están al finalizar el capitulo.
Zonas Inversas
La configuración de las zonas inversas son muy similares a las directas.
Tienen un nuevo registro de recurso que permite hacer la resolución inversa de direcciones (IP à DOMINIO).
PTR
Este registro me permite traducir la IP correspondiente a un host que este dentro de la zona, los registros PTR solo deben ir dentro de zonas inversas. Tenga cuidado al manipular las zonas, siempre debe tener claro cuales son las inversas y cuales son las directas. Ejemplo de PTR:
100 IN PTR www
100 IN PTR www.curso-servidores.edu.co.
Recuerda que el archivo de configuración del nombre de la zona decía algo así:
0.168.192.in-addr.arpa
Hablábamos que el ultimo campo no se ponía en el nombre y era porque lo usaríamos en el archivo de configuración. Pues bien, esto es real y por eso el recurso PTR solo toma el campo faltante.
Observe que aparece solo un 100 en el archivo de zona inversa asociado a un nombre de host www. Esto quiere decir que cuando el DNS interprete el archivo lo tomará así:
100.0.168.192.in-addr.arpa
Lo que permitirá tener completa la dirección al revez y podrá hacer la resolución para la IP 192.168.0.100, encontrando que esta asociada a www.
En el ejemplo del recurso PTR usamos dos configuraciones similares, no es posible tener ambas configuraciones dentro del archivo de zona, solo se expone como ejemplo. Ya que ambas formas son funcionales, todo depende si configuramos el nombre completo (y agregamos un punto al final) o solo ponemos el nombre del host y esperamos que el BIND agregue el resto de la información. Puede trabajar como le parezca mas sencillo, la recomendación es que lo haga con cuidado.
0 comentarios for this post