Categoría: Networking

Hay tres configuraciones de servidores de nombres basicas:

• Un Servidor de Cache, que es un servidor no autoritativo. Obtiene todas las respuestas a consultas de nombres de otros servidores de nombre.


• Un Servidor Esclavo, el cual es considerado autoritativo porque tiene un base de datos completa y exacta, la cual transfiere de los servidores maestros. Tambien son llamados Servidores Secundarios porque son respaldos a los servidores primarios.


• El Servidor Maestro es el servidor primario para el dominio. Carga la informacion del dominio directamente desde un fichero en el disco local, mantenido por el administrador del dominio. El servidor maestro es considerado autoritativo para el dominio, y sus respuestas a las consultas son siempre consideradas exactas.

Nota 1: Un servidor autoritativo es aquel que contiene datos maestros acerca de algo, es decir, son la fuente primaria de informacion acerca de algo. En contraste con los servidores de ‘cache’, quienes tienen una copia de la informacion.

Nota 2: La mayoria de los servidores combinan elementos de mas de una configuracion (de las antes mencionadas). Todos los servidores guardan en cache las respuestas, y muchos servidores primarios actuan como servidores secundarios de otros dominios.

Sugerencias:

a. Debes crear un solo servidor maestro para tu dominio. Es la fuente principal de informacion con respecto a este. El hecho de crear mas de un servidor maestro podria socavar la confiabilidad de la informacion.

b. Crea por lo menos un servidor esclavo; asi podras compartir la carga, y proveer respaldo para el servidor maestro.

c. Usa servidores de cache a travez de la red para reducir la carga sobre el servidor maestro y los secundarios.

Para la configuracion de named se requieren hasta 5 ficheros de configuracion.
Todas las configuraciones (Cache, Secundario, Primario) requieren de los siguientes ficheros basicos:

Fichero de configuracion de named, named.conf, el cual define parametros basicos, y apunta a las fuentes de informacion de las base de datos de los dominios, los cuales pueden ser ficheros locales o servidores remotos.

Fichero de sugerencias (hints), o cache, provee los nombres y direcciones de los servidores raiz que son usados durante la inicializacion.

Fichero del host local: Toda configuracion contiene una base de datos de dominio local para resolver el loopback al nombre de host ‘localhost’.

Los otros dos ficheros que son utilizados para configurar named son utilizados unicamente en el servidor maestro. Estos son los dos ficheros que definen la base de datos del dominio:

Fichero de zona el cual define la mayor parte de la informacion. Es utilizado para mapear nombres de hosts a direcciones, identificar el servidor de correo, y proveer una variedad de informacion acerca de otros dominios.

Fichero de zona reversa, el cual mapea direcciones IP’s a hostnames, lo que es exactamente lo opuesto a lo que hace el Fichero de Zona.

Nota 3: Una Zona es el contexto de un dominio sobre el cual un servidor maestro tiene autoridad. El fichero de base de dato de dominio que contiene la informacion acerca de la zona es llamado Fichero de Zona. Una Zona y un dominio NO son la misma cosa. Por ejemplo, todo lo que esta contenido en un fichero de base de datos esta en una misma zona, incluso si el fichero contiene informacion acerca de mas de un dominio. (Es decir, no importa si el fichero de base de datos contiene informacion acerca de varios dominios, aun asi estan en la misma zona).

Para configurar un servidor dns necesitas saber como configurar los cinco ficheros. Por lo cual empezaremos mirando el fichero named.conf, el cual es usado en cada servidor de dominios, y define la configuracion basica.

El Fichero De Configuracion De Named

La estructura de los comandos de configuracion de named.conf es similar a la estructura al lenguaje de programacion C. Un enunciado termina con un punto y coma ( ; ), Las literales son encerrados en comillas ( “” ), y los articulos relacionados estan agrupados en llaves ( {} ). BIND provee tres formas de insertar un comentario las cuales son:

/* Esto seria un comentario (Estilo C) */
// Esto seria otro comentario, estilo C++ 
# Esto seria otro comentario, tipo Shellscript

Existen once enunciados de configuracion validos para BIND 9.x, la cual es la version que trae Slackware (por lo menos, la version que tengo), a continuacion los menciono brevemente con una pequenia descripcion:

Comando	Uso
acl	Define una lista de control de acceso (Access Control List)
controls	Define el canal de control para el programa de control de named
include	Incluye otro fichero dentro del fichero de configuracion.
key	Define claves de seguridad para autenticacion.
logging	Define que cosas seran registradas y donde seran almacenadas.
lwres	Hace que el servidor actue como un servidor lightweight de resolucion.
options	Define opciones de configuracion globales y por defecto.
server	Define las caracteristicas de un servidor remoto.
trusted-keys	Define las llaves de encriptacion DNSSEC para el servidor
view	Muestra diferentes vistas de la informacion de la zona a clientes diferentes.
zone	Define una zona

En lo adelante estare utilizando ejemplos para ilustrar la funcion y formato de los comandos mas utilizados comunmente.

La sentencia options

La mayoria de los ficheros named.conf empiezan con la sentencia options. Solamente se puede utilizar una sentencia options. La sentencia options define parametros globales que afectan la forma en que opera BIND. Tambien indica los valores por defecto para otras setencias utilizadas en el fichero de configuracion. La opcion mas comunmente utilizada define el directorio de trabajo para el servidor:

options {
        directory "/var/named";
};

La sentencia empieza con el comando ‘options’. Las llaves encierran una lista de opciones, y la palabra directory define el directorio desde el cual named leera (y escribira) los ficheros. El nombre del directorio tambien es utilizado para completar cualquier nombre de fichero especificado en el fichero de configuracion. La parte encerrada entre comillas es la ruta del directorio. Fijate que tanto la opcion directory como las llaves, al final tienen ‘;’.

Mas adelante veras que named escribe varios ficheros diferentes que son usado spara chequear el estado el servidor de nombres. La opcion ‘options’ puede ser utilizada para cambiar las rutas por defecto de los ficheros individuales. Aunque realmente es recomendable mantener el nombre original para cada fichero de status y guardarlos en el fichero identificado por la opcion ‘directory’.

La sentencias zone

Las sentencias zone son las mas importantes en la configuracion del fichero, y constituyen la mayoria del fichero named.conf. Una sentencia zone lleva a cabo las siguientes configuraciones criticas:

• Identifica una zona que esta siendo servida por un servidor de nombres
• Define el tipo de servidor de nombre que representa este servidor para esta zona. Un servidor puede ser master o slave. Y debido a que esto se define por zonas, el server puede ser master para algunas zonas mientras lo es slave para otras.
• Define la fuente de informacion de dominio para una zona. La base de datos de dominio puede ser cargada de un fichero en el disco local o transferida desde un servidor maestro.
• Define opciones de procesamiento especial para la zona.

Este seria un ejemplo que ilustra todas estas funciones:

zone "eslackware.com" in {
        type master;
        file "eslackware.hosts";
        check−names fail;
        notify yes;
        also−notify { 172.16.80.3; };
        allow−update { none; };
};

La sentencia comienza con el comando ‘zone’. El nombre de la zona es escrita como un literal encerrado en comillas. La palabra clave in quiere decir que esta zona contiene direcciones de IP y nombres de dominios de Internet. Este es el valor por defecto, de modo que no es realmente requerida. Las llaves encierran una lista de opciones para esta zona.

El tipo ‘master’ indica que este es el servidor maestro (master) para el dominio eslackware.com. Otros valores posibles son:

slave: Identifica este servidor como esclavo, para este dominio.
hints: Identifica este como el fichero de hints (pistas) que es utilizado para inicializar el servidor de nombres durante el arranque.
stub: Identifica este como un servidor stub. (Servidores stub son servidores esclavos ’slaves’ que solo cargan los records del servidor de nombres desde el servidor maestro). Esto es principalmente para servidores no recursivos que quieren referir una consulta a otros servidores, de la misma manera que los servidores raiz refieren las consultas a otros servidores. Esto es rara vez utilizado en una red de una empresa.

la opcion ‘file “eslackware.hosts"‘ apunta al fichero que contiene la base de datos de informacion del dominio. Para un servidor maestro, este es el fichero que es creado por el administrador del dominio.

En proximos articulos pienso hacer ejemplos detallados y configuracion paso a paso acerca de la configuracion de los tres tipos de servidores de DNS (master, slave, cache)

--
Jose P. Espinal
http://www.eslackware.com

BIND DNS es un sistema cliente/servidor. El cliente se llama ‘resolvedor’ (resolver , en Inglés), y formula peticiones y envía al servidor de dominios. Cada equipo de la red corre un resolvedor. De hecho, muchos sistemas sólo ejecutan el resolvedor.

Tradicionalmente, el resolvedor BIND no es aplicado como un proceso (que suba con el sistema). Es una biblioteca (o librería, como deseen llamarle) de rutinas de software, llamado el código de resolución, que está vinculada a cualquier programa que requiera de servicio de nombres. La mayoría sistemas Linux usan la implementacion tradicional de resolución, que se denomina ’stub resolver’. Ya que es el más ampliamente usado, es al que le daremos cobertura en este artículo.

El lado servidor de BIND responde las peticiones que vienen del resolvedor.
El nombre del daemon es un proceso que se llama named. La configuración de named es mucho más compleja que la configuración del resolvedor; pero no hay necesidad de correr named en cada equipo.

Debido a que todos los ordenadores de tu red -ya sean clientes o servidores- ejecutan el resolvedor, comenzaremos la configuración de DNS con la configuración del resolvedor.

Los Comandos de Configuracion Del Resolvedor (resolver)

El resolvedor de Linux está configurado por dos tipos de archivos. Un tipo le dice al resolvedor qué servidores de nombres de dominio va a utilizar y en qué orden. Eso lo discutiremos más adelante.

El otro archivo de configuración, /etc/resolv.conf, configura al resolvedor para su interacción con el Sistema de Nombres de Dominio (Domain Name System). Cada vez que un programa que utiliza el resolvedor inicializa, lee el fichero /etc/resolv.conf, y guarda en cache la configuración de dicho archivo, durante el lapso de vida del proceso.

Es decir, por ejemplo; en el momento que levantas Sendmail, este leerá el fichero /etc/resolv.conf y trabajará con esa información durante el tiempo de vida de ese proceso (hasta que finalice de alguna forma). Si le haces algun cambio a /etc/resolv.conf, tendrás que reinicializar Sendmail para que los cambios surtan efecto.

Si no se encuentra el fichero /etc/resolv.conf, una configuración por default será utilizada.

La configuración por default utiliza al sistema local como el servidor de nombres. Esto quiere decir que debes ejecutar named si no crearás un fichero /etc/resolv.conf. Generalmente, es recomendable crear un fichero resolv.conf, incluso si no estás corriendo named en el host local (Este fichero se crea cuando configuramos la red utilizando netconfig en Slackware, si no lo ves, crealo… no duele).

Hay tres razones principales por lo cual deberías crearlo:

Primero, el fichero resolv.conf provee los medios para documentar la configuración en tu sistema; es decir, cualquiera puede ver el fichero y saber la configuración que has utilizado para tu sistema.

Segundo, los valores por default que funcionan en una versión de BIND, pueden cambiar en una futura versión.

Y tercero, aún cuando estés utilizando tu máquina local como servidor de nombres, el fichero resolv.conf te permite configurar servidores de respaldo para incrementar la robustez.

Los Comandos de Configuración del Resolvedor

BIND 9 (quien comenzó a ser incluido en los tiempos de Red Hat 7.2) utiliza los mismos ficheros de configuración que BIND 8. El fichero resolv.conf es un fichero de texto que puede contener la siguiente información:

nameserver direccion-IP 

El comando nameserver define el la dirección IP de un servidor de nombres que debería utilizar el resolvedor. Los servidores son consultados en el orden que aparezcan en el fichero hasta que sea recibida una respuesta o se acabe el tiempo de espera. Por lo general el primer servidor de nombres responde la consulta. La única vez cuando el segundo servidor es consultado es cuando el primero no responde o está fuera de línea. El tercer servidor únicamente responderá las consultas si los primeros dos fallan. Si no se encuentra ningún servidor de dominios en el fichero resolv.conf, el servidor de nombres corriendo en el servidor local es utilizado (En caso de que estés corriendo uno, obviamente).

domain nombre-de-dominio 

El comando domain define el dominio local. El dominio local es utilizado para expandir el nombre de host en una consulta antes de ser enviado al servidor de nombres. Si el comando domain no es utilizado, los valores indicados en el comando search son utilizados. Ahora bien, si ninguno de los dos comandos son indicados en el fichero resolv.conf, el valor derivado del comando hostname es utilizado. Sin importar como sea seteado el valor del dominio local, podrá ser sobreescrito por cualquier individuo si setea la variable de entorno LOCALDOMAIN.

search lista-de-busqueda 

El comando search define una lista de dominios que son utilizados para expandir un nombre de host antes de que se envie la consulta al servidor de nombres. lista-de-busqueda contiene un maximo de seis nombres de dominios, separados por espacio en blanco. La busqueda se hace en cada dominio especificado en la lista hasta que la consulta sea contestada. A diferencia del comando domain, el cual crea una lista de busquedas por defecto la cual contiene unicamente el dominio local, el comando search crea una lista explicita conteniendo cada dominio especificado en la lista-de-busqueda.

options opcion 

La opcion options modifica el comportamiento estandard del resolvedor. Hay diferentes opciones diponibles para BIND:

debug 

Enciende el depurador. Cuando la opcion debug es indicada, el resolvedor imprime mensajes de depuracion a la salida estandard. Estos mensajes son bastante informativos para depurar problemas del resolvedor o del servidor, pero la verdad es que esta opcion es de valor marginal. Encender el depurador en la configuracion basica del resolvedor produce demasiada informacion de salida, en tiempo inapropiado.

ndots:n 

Define el numero de puntos (’.') que indican cuando el resolvedor deberia adjuntar valores extraidos de la lista-de-busqueda al nombre de host antes de enviar la primera consulta al servidor de nombres. Por defecto el resolvedor no modificara un nombre de host si este contiene un punto ‘.’
¿Que es lo que intento decir? (porque imagino que algunos podrian estar confundidos con lo antes dicho)

Por ejemplo, si este fuera mi resolv.conf:

search eslackware.com slackware-es.com # Estos dos dominios constituyen 
                                       # mi lista-de-busqueda

nameserver 208.67.222.222              # Servidor de nombres primario
nameserver 208.67.220.220              # Servidor de nombres secundario
options ndots:1

Y este fuera mi /etc/hosts:

127.0.0.1 localhost
10.0.0.204 pbx pbx
10.0.0.202 slackbox.ejemplo.com slackbox
10.0.0.44 agonzalez.ejemplo.com agonzalez
10.0.0.111 ylaborda.ejemplo.com ylaborda
10.0.0.76 jrobinsonc.ejemplo.com jrobinsonc

La opcion ‘ndots:2′ en mi resolv.conf le esta diciendo al resolvedor que use mi lista de busqueda (los dominios (la que le indique mediante ‘search‘) antes de intentar enviar la primera consulta al primer servidor de nombres, para todos los nombres de host que tengan menos de dos puntos (’.'). De modo que lo que hara es ver si existe pbx.eslackware.com o pbx.slackware-es.com antes de preguntarle al primer servidor de nombres.

En caso de yo hacer ping a ‘agonzales.ejemplo.com’, como este registro contiene una cantidad igual al valor minimo de puntos (’.'), la consulta se envia directamente al primer servidor de nombres.

Realmente esta opcion solo te seria de utilidad si algun componente de tu dominio podria confundir a un top-level domain, y tienes usuarios que consecuentemente suelen truncar (acortar, para los indoctos , broma) los nombres de dominio. Entonces cuando alguien escriba el hostname de un equipo en tu dominio, resulta que la consulta seria primero enviada a los servidores raiz, para que estos luego hagan referencia a tu servidor de nombres (horrible, no?).

timeout:n 

Indica la cantidad de tiempo que el resolvedor esperara una respuesta del servidor de nombres antes de reintentar la consulta a travez de un servidorde nombrs diferente.

attempts:n 

Define el numero de veces que el resolvedor reintentara una consulta. El valor por defecto es 2, lo que quiere decir que el resolvedor reintentara una consulta dos veces con cada servidor de nombres antes de retornar un error a la aplicacion.

rotate 

Enciende el round-robin (seleccion en orden recursivo) de servidores de nombres. Normalmente el resolvedor envia la consulta al primer servidor en la lista, y unicamente envia la consulta al segundo servidor si el primero ha fallado. Tradicionalmente el segundo y tercer servidor de nombres fueron definidos para proveer servidores de nombres de respaldo. Estos no fueron concebidos para proveer balance de carga. La opcion rotate configura al resolvedor para compartir la carga de servidores de nombres de manera equilibrada sobre todos los servidores.

no-check-names 

Deshabilita el chequeo de nombres de dominio con respecto al RFC 952, “DOD Internet Host Table Specification.". (Para los que no lo sabian, RFC = Request For Comments, son documentos que describen estandares de como deben hacerse las cosas en internet, mas o menos).

Por defecto, los nombres de dominio que contienen un subrayado (underscore ‘_’), caracteres no-ASCII, o caracteres ASCII de control, son considerados como error. Usa esta opcion para trabajar con hombres de host que contengan subrayado.

inet6 

Esto produce que el resolvedor intente resolver IP’s del protocolo IPv6. La version del protocolo de internet que usamos actualmente es IPv4.
Usa esta opcion si te estas conectando a una red IPv6 experimental.

sortlist lista-de-direcciones 

El comando sortlist define una lista de redes que son preferidas sobre otras. La lista-de-direcciones es una lista de pares de direcciones y mascaras (por ejemplo, 66.128.63.0/255.255.255.0).
¿Para que te seria util esto?, bueno, Imagina que el nombre mp3local.com tenga mas de una direccion asignada a el, y que conoces cual de las dos direcciones tiene una red superior a la otra (mas rapida, menos latencia, lo que sea), pues con esta opcion puedes indicarle al resolvedor que a la hora de hacer una peticion a mp3local.com, tenga preferencia por la red que le indiques en lista-de-direcciones sobre otras las otras.

Consideraciones y Notas finales:

i. Las opciones domain y search son mutuamente excluyentes (o sea, o usas una, o usas la otra; NO las dos). Si mas de una de estas opciones es encontrada, la ultima prevalecera sobre la otra.

ii. La opcion search del fichero resolv.conf de un sistema puede ser sobreescrito a raiz de la ejecucion de un proceso al setear la variable de entorno ‘LOCALDOMAIN’ con una lista separada (por espacios) de dominios de busqueda.

Es decir, no importa lo que hayas puesto en la opcion search de resolv.conf, si alguien (antes de ejecutar algun programa o comando), hace algo como:

# LOCALDOMAIN=eslackware.com
# export LOCALDOMAIN

Lo que hayas puesto en search, no tendra validez.

iii. De igual forma, no importa lo que hayas indicado en resolv.conf utilizando options, si alguien setea la variable de entorno RES_OPTIONS a una lista (separada por espacio) de opciones para el resolvedor, este ultimo conjunto de parametros prevalecera.

Como siempre, espero que esto les haya sido de utilidad.
Proximamente veremos como configurar un servidor de DNS, vayan leyendo

--
Jose P. Espinal
http://eslackware.com

Aprovecho la oportunidad para tocar el tema de BIND, el cual es el daemon que nos sirve como DNS Server.

Como no me había visto con la necesidad de configurar uno, solo hasta recientemente fue que hice una investigacion al respecto, sin embargo, creo que ya es hora; para esto me estaré apoyando de varias fuentes de documentación que mencionaré al final.

Entre los servicios más fundamentales en las redes TCP/IP tenemos el servicio de nombres, el cual es el servicio que traduce hostnames a direcciónes IP’s.

Los sistemas Linux usan básicamente dos técnicas para convertir hostnames a direcciónes:
a) La tabla de ‘host’ (/etc/hosts)
b) DNS (Domain Name System)

En el primer caso, el archivo /etc/hosts, es una tabla que traduce nombres a direcciónes. Es un archivo de texto simple en el cual se busca secuencialmente para aparear hostnames con direcciónes IP.

El sistema de Nombres de Dominio (DNS) es una base de datos jerárquica, distribuida por toda la internet a travez de miles de servidores.

Nota: Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que, como su nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo.

El Archivo Hosts

Por ejemplo, el archivo hosts podría contener las siguientes entradas:

127.0.0.1 localhost
10.0.0.202 slackbox.localdomain slackbox
10.0.0.44 agonzalez.localdomain agonzalez
10.0.0.111 ylaborda.localdomain ylaborda
10.0.0.76 jrobinsonc.localdomain jrobinsonc

Cada entrada en el archivo /etc/hosts contiene una dirección IP y los nombres asociados con esa dirección.

La primera entrada en está tabla asigna el nombre ‘localhost’ a la dirección 127.0.0.1. (Cada computador corriendo TCP/IP asigna la dirección de loopback al nombre de host ‘localhost’). La red 127 es una red especial reservada para la red de loopback, y el host 127.0.0.1 es la dirección de loopback reservada para la maquina local.

La dirección de loopback es una convención (es decir, un estandard asumido por acuerdo general) que permite a la PC local referirse a sí misma de forma semejante a como lo hace con otros computadores en la red. Esto simplifica la programación de softwares ya que el mismo código puede ser usado para referirse a cualquier sistema, y ya que la dirección es asignada a la interfaz (lo), ningún tráfico es enviado a la red física.

La segunda entrada en el archivo es para el mismo ’slackbox.localdomain’. La entrada hace referencia al IP 10.0.0.202 y al alias slackbox. Los nombres de alias son usados generalmente para proveer un nombre mas corto, tambien para proveer nombres genericos como mailhost, news, www. Cada computador conectado a la red, que tiene un IP fijo tiene su propio hostname y dirección en la tabla de /etc/hosts.

Cada sistema Linux tiene una tabla ‘hosts’ con las dos entradas discutidas previamente.

Entendiendo DNS

Las limitaciones de la tabla de ‘hosts’ resulta obvia cuando es usada con un gran número de hosts. La tabla de hosts requiere que cada computador tenga una copia local de la tabla, y cada copia debe ser completa porque sólo las computadoras listads en la tabla de hosts local son accesibles por el nombre.

Si tomamos en consideración el Internet como lo conocemos hoy día: Tiene millones de hosts. Una tabla de ‘hosts’ con millones de entradas es muy ineficiente y, lo que es más importante, imposible de mantener. Los hosts son agregados y quitados del internet cada segundo. Ningún sistema podría mantener una tabla tan grande y variante, mucho menos si es distribuida en todos los computadores de la red.

El sistema de DNS rompe con esta problemática eliminando la necesidad de una fuente centralizada para mantener estas tablas, e introduce el concepto de tablas distribuidas de manera jerárquica. Actualmente la información acerca de DNS esta distribuida en decenas de miles de servidores.

Adicionalmente, El sistema de DNS usa una cache local para migrar información a aquellos que la necesiten, sin enviar información innecesaria. Un server de cache empieza con la información necesaria requerida unicamente para alcanzar la raíz de la base de datos jerárquica. Luego guarda todas las respuestas a queries de usuarios que recibe y toda la información adicional requerida para obtener dichas respuestas. De esta forma, construye una base de datos interna de la información que necesita proveer a sus usuarios.

La jerarquía DNS

La jerárquia de DNS puede ser comparada a la jerarquía del sistema de archivos en Linux. Nombres de host en dominios independientes, nombres de archivos paralelo en directorios individuales, y, al igual que el directorio raíz (root) del sistema de archivos, DNS tiene un dominio raíz.

En ambos, el sistema de archivos, y el sistema DNS, los nombres de los objetos revelan la estructura jerarquica arraigada. Los nombres de archivos van desde lo más general, la raíz (/), a lo mas específico, el fichero individual.

Los nombres de dominio comienzan con lo más específico, el host, y van hasta lo mas general, la raíz (.).

Un nombre de dominio que empiece por un host y vaya hasta la raíz se llama nombre de dominio completamente calificado (FQDN -Fully Qualified Domain Name-). Por ejemplo, packages.eSlackware.com es el FQDN de uno de los sistemas en mi red (asumiendo que hubiese tenido uno, llamado ‘packages’).

Los dominios de nivel superior (top-level, TLDs), tales como .org, .edu, .jp y .com son servidos por los servidores raíz. Los dominios de segundo nivel (second-level domain), eSlackware en nuestro ejemplo, es el dominio que ha sido oficialmente asignado a nuestra organizacion. Cuando se te ha asignado oficialmente un dominio por tu dominio padre, un se~nalador es puesto en el dominio padre el cual apunta hacia tu servidor como el servidor responsable por tu dominio. Es esta delegacion de autoridad lo que hace a tu dominio parte del conglomerado de sistema de dominios. La forma de delegar autoridad para subdominios es discutida más adelante.

La analogía del sistema de archivos va mas alla que solo la estructura de los nombres. Los archivos son encontrados al seguir una ruta desde la raíz hasta los directorios subordinados, hasta el directorio destino. La informacion de DNS es encontrada de una manera semejante. Linux aprende la ubicacion del directorio raíz en el proceso de booteo tomandola de lilo.conf (o grub.conf , para quienes usen eso). De manera similar, tu server de DNS localiza los servidores raíz durante el arranque al leer un archivo, llamado ‘hints file’ (archivo de pistas, en espa~nol), el cual contiene los nombres y direcciónes de los servidores raíz. (Vas a crear ese archivo mas adelante). A travez de consultaes, el server puede encontrar cualquier host en el sistema de dominios al empezar en la raíz y siguiendo se~naladores a travez de los dominios hasta que llegue al dominio destino.

Respondiendo Consultas

Para responder una consulta con respecto a la informacion de DNS, el servidor local debe:

a. Tener la respueta a la consulta o
b. Saber cual servidor de dominio la sabe.

Ningun sistema puede tener un completo conocimiento por si solo acerca de todos los nombres en la internet; los servidores saben acerca de sus dominios locales y construyen una cache acerca de otros dominios tomando una consulta a la vez.

Ok, veamos como funciona. Asumiendo que quieres acceder a la dirección http://www.eslackware.com. En efecto, estas pidiendo por el record de dirección para ‘www’ de la base de datos eslackware.com. Una consulta para el record de esa dirección viene al servidor de nombres local. Si el servidor se sabe la dirección de http://www.eslackware.com, respondera la consulta directamente. Si no se sabe la respueta, pero sabe cual servidor maneja eslackware.com, hara la consulta a ese servidor. Si no tiene informacion del todo, hara la consulta a los servidores raíz.

El servidor raíz no responde la consulta directamente. En cambio, le indica al server local cual servidor puede responder las consultaes para eslackware.com. Hace esto enviandole al servidor local un record nombre de dominio que dice el nombre del servidor para eslackware.com y el record de dirección que dice la dirección de ese servidor. El servidor local podra entonces hacer consultaes a eslackware.com y recibe la dirección para http://www.eslackware.com/.

De esta manera, el servidor local se entera de la dirección del host, así como el nombre y la dirección de los servidores para el dominio. Estas respuestas y los cachés se utilizan para responder directamente a consultas sobre el dominio www.eslackware.com sin molestar de nuevo los servidores raíz.

En el próximo artículo estaremos hablando acerca de BIND, y la resolución de dominios.
Todo esto antes de entrar en materia con lo más pesado (la configuración de named) en si mismo.

Cualquier comentario, sugerencia o duda, recuerden escribirme.

–
Jose P. Espinal
http://eslackware.com

En este artículo estaremos incursionando un poco en la seguridad y criptografía al referirnos a Transport Layer Security (TLS) y su predecesor, Secure Sockets Layer (SSL).

TLS y SSL son protocolos de criptografía que proveen comunicación segura para cosas tales como navegacion web, emails, Fax en internet, mensajería instantanea y otros tipos de transferencia de datos. Hay diferencias ligeras entre SSL y TLS, pero son en escencia lo mismo.

Ok, viene la pregunta: ¿Para que sirve eso?

El protocolo TSL permite que las aplicaciones se comuniquen de manera tal que se evite la intercepcion de paquetes, manipulación y forjamiento de mensajes. TLS provee autentifiación de destino final y privacidad de comunicaciones sobre internet a travez del uso de criptografía.

Por lo general, solo el server se autentifica (se tiene seguro su autenticidad) mientras que el cliente (quien se conecta al server) permanece sin autentifiación. El siguiente nivel de seguridad (en el cual ambos lados se autentifican) se conoce como ‘autentificación mutua’ (la cual require de infraestructura de llaves).

TLS envuelve tres fases básicas:

• Negociacion con el peer (otro punto que se conecta) para determinar que algoritmo soporta.
• Intercambio de llaves y autentificación
• Encriptacion simetrica y autentifiacion de mensajes

Durante la primera fase, el cliente y el server se ponen de acuerdo en el tipo de cifrado que van a utilizar, los algoritmos de autentifiacion para el intercambio de llaves, asi como tambien los codigos de autentificacion de mensajes.

En sintesis (para nuestros fines):
Un protocolo es un conjunto de normas y convenciones que establecen como las computadoras van a interconectarse entre si (digamos que son como el lenguaje entre las computadoras para determinados servicios).
TLS y SSL son lenguajes de criptografía que nos permiten conectarnos de manera SEGURA a un server, y en cuya conexion la informacion pasara totalmente cifrada, de modo que sea casi imposible para un tercero el poder entender dicha información en caso de que capture paquetes mediante alguna técnica.

Para información adicional pueden buscar documentación en Google, y así profundizar más en este tópico.

--
Jose P. Espinal
http://blog.slackware-es.com

Buenas noches!! (es de noche mientras escribo esto); Hoy tendremos la oportunidad de configurar un server FTP para nuestro sistema.

He elegido VSFTPD (Very Secure FTP Daemon) por varias razones muy personales (es decir, no tienen que tomarlas como punto de referencia para elegir un server FTP para su sistema):

a) Es MUY rapido. Como trabajo administrando servers de hosting he tenido la oportunidad de probar otros, y definitivamente, este es rapido!.

b) Seguro, muy seguro. Es tanto asi que es el server FTP que trae OpenBSD; que, creanlo o no, es el Sistema operativo mas seguro.

c) Facil de configurar!! (muy facil, en serio)

El archivo de configuracion trae por default (en Slackware, no en la instalacion desde el source) las siguientes opciones con las cuales se puede correr el server FTP luego de ser modificadas a tu gusto:

#
# Los settings compilados por default son casi paranoicos. Este
# ejemplo floja un poco las cosas para hacer el server de FTP un
# poco mas util.
#
# LEE ESTO!!!!!!!!: Este ejemplo no es exhaustivo en los detalles
# de configuracion. Favor de dirigirse a la documentacion en la
# pagina oficial y al man page.
#
# Permitir FTP anonimo? (Ten cuidado, porque estara habilitado por
# default si comentas esta opcion ).
anonymous_enable=NO

# Permitir a los usuarios locales loggearse?
local_enable=YES

# Permitir cualquier tipo de escritura via FTP
write_enable=YES

# El umask por default para los usuarios locales es 007.
# Tal vez desees cambiar esto a 002, si eso es lo que esperan
# tus usuarios. (002 es el default en la mayoria de ftpd's)
local_umask=022

# Activar mensajes de directorios - mesajes dados a los usuarios
# cuando se dirijan a cierto directorio.
dirmessage_enable=YES

# Activar el registro de transferencias
xferlog_enable=YES

# Asegurarnos de que el puerto de transferencia se origine 
# desde el puerto 20 (ftp-data)
connect_from_port_20=YES

# Si quieres, puedes cambiar los permisos a un usuario diferente
# del usuario utilizado para subir los archivos. Por favor no 
# uses 'root', te puedes arrepentir luego.
chown_uploads=YES
chown_username=ftp

# Puedes sobreescribir donde se tendra el archivo de logs.
# El default es el siguiente:
xferlog_file=/var/log/vsftpd.log

# Si quieres, puedes tener tu logfile en un formato standard de
# ftpd-xferlog
xferlog_std_format=YES

# Puedes cambiar el valor por default para desconectar una conexion
# resagada
idle_session_timeout=1300

# Puedes cambiar el valor por default para desconectar una conexion
# de data
data_connection_timeout=300

# Es recomendable que definas un usuario en tu sistema, unico, el
# cual pueda ser utilizado totalmente aislado y sin privilegios.
nopriv_user=ftp #slackware trae este creado ya ;)

# Habilita esto y tu server reconocera peticiones ABOR asincronicos.
# Se considera no recomendable por cuestiones de seguridad.
# Sin embargo no usarlo podria confundir viejos clientes FTP
async_abor_enable=YES

# Por default el server pretendera permitir ASCII mode pero en 
# realidad ignorara esas peticiones. Enciende la opcion mas abajo
# para que el server en realidad maneje peticiones ASCII.
# Ten MUY en cuenta que en algunos FTP servers, soportar ASCII
# puede permitir un ataque de denegacion de servicio (DoS) a travez
# del comando "SIZE /big/file/" en ASCII mode. vsftpd predijo este
# ataque y siempre ha sido seguro reportando el tama~no del archivo
# en crudo.
# 
ascii_upload_enable=YES
ascii_download_enable=YES

# Puedes customizar completamente la cadena de anuncio al
# iniciar sesion
ftpd_banner=Bienvenido a Slackware-ES FTP Server

# Si se activa esta opcion, puedes proporcionar una lista de 
# usuarios que seran colocados en su directorio home mediante 
# chroot() cuando inicien sesion.
# Ahora bien, el significado es un poco diferente si se usa la 
# opcion chroot_local_user en YES.
# En este caso, la lista se vuelve un listado de usuarios a los que 
# NO se le hara chroot() a su home.
chroot_list_enable=YES
chroot_local_user=YES
chroot_list_file=/etc/vsftpd.chroot_list

# Nota: Esto se vuelve medio confuso, si activas chroot_list_enable
# se supone que le daras al sistema una lista de usuarios para
# hacerles chroot() a su home. Si activas chroot_local_user, 
# entonces la lista indicara cuales usuarios NO quieres que se le 
# haga chroot() a su home.
# Yo personalmente activo chroot_list_enable y tambien activo
# chroot_local_user, sin embargo, dejo la lista vacia, asi le hago
# chroot() a TODOS ;)

#
# Puedes activar la opcion "-R" para el comando interno ls.
# Esto esta deshabilitado por predeterminado para evitar que los 
# usuarios remotos sean capaces de causar un excesivo I/O en sitios
# bastante grandes.
# De todas formas, algunos clientes FTP defectuosos asumen la 
# precedencia de "-R", asi que hay una razon de peso para
# habilitarla.
ls_recurse_enable=YES

# Para correr vsftpd en modo standalone (o sea, individual, no 
# por medio de inetd), descomenta la linea siguiente 
#listen=YES

Ahora bien, puedes copiar esa configuracion como ejemplo y guardarla como
/etc/vsftpd.conf y hacer lo siguiente:

Para iniciar tu servidor FTP en modo standalone (individual, no iniciado por inetd) ejecuta el comando ‘/usr/sbin/vsftpd &‘ (recuerda quitar el comentario a la linea liste=YES de vsftpd.conf para que no te de error)

Si quieres que cada vez que tu ordenador suba, el servicio FTP inicie automaticamente, simplemente edita el archivo ‘/etc/inetd.conf‘ y descomenta la linea que dicen lo siguiente:

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  vsftpd

Y listo, subira automaticamente siempre ,

No olvides crear el archivo /etc/vsftpd.chroot_list si utilizaste esta opcion

Puedes crear uno vacio de la siguiente forma (como root, claro esta):

# touch /etc/vsftpd.chroot_list

Ya si, todo esta listo!.

Puedes probar conectandote por FTP (una vez que el server este ejecutandose), utilizando un usuario de tu sistema (el mismo que usas para loggearte tu, por ej.)

NOTAS:

a) La configuracionde vsftpd es (MUY!) amplia, si quieres ver mas opciones para ir configurando mas a fondo tu sistema, puedes ver la pagina del manual de vsftpd.conf

man vsftpd.conf

b) cuando hablo de hacer chroot() a un usuario a su /home , me refiero a que TODOS los comandos que ejecute cierto usuario por FTP estaran encapsulados (o enjaulados, como quieras) a su directorio /home a travez del comando chroot. Asumo que no te gustaria que ningun usuario de FTP este rondando por /var/lib o /etc/X11 , verdad?, lo mas prudente es que nadie salga de su /home asignado, cierto? Pues para eso es que se usa chroot()

Espero que esta info haya sido util!, cualquier cosa no dudes escribirme o enviarme un mensaje.

Cuidense!

--
Jose P. Espinal
http://www.slackware-es.com