Manual de Sistemas de
Resolución de Nombres
(DNS) en Canaima
GNU/Linux
Créditos y licencia
© 2008-2009 Centro Nacional de Tecnologías de
Información
© 2008-2009 ONUVA Integración de Sistemas
Este documento se distribuye al público como
documentación y conocimiento libre bajo los términos de la
Licencia Pública General GNU, que puede obtener en la
dirección Web:
http://www.gnu.org/copyleft/gpl.html
Convenciones tipográficas
Texto enfatizado, anglicismos, texto resaltado, comandos,
salidas, paquetes o contenido de archivos.
Indica información muy importante con respecto al contenido
Indica comandos, salidas en pantalla o contenido de archivos
Contenido
Créditos y licencia... 2
Convenciones tipográficas... 2
INTRODUCCIÓN... 6
UNIDAD I: BASES DEL SISTEMA DE NOMBRES DE DOMINIO – DNS...7
Tema 1: Fundamentos de DNS...7
Elementos de un Sistema de nombres de dominio...7
Sistema jerárquico de nombres de dominio...10
Dominios nivel superior...13
Tema 2: Tipos de servidores DNS ...14
Servidores DNS Autoritarios...14
Servidor de cache DNS... 15
Tema 3: Proceso de resolución de nombres de dominio y resoluciones reversas...16
Tema 4: Registros DNS... 18
Estructura y elementos de un registro DNS...18
Descripción del contenido de una cabecera DNS...19
Tipos de registros DNS... 20
Tipos de consultas DNS...22
Consultas iterativas. ...22
Consultas recursivas... 22
UNIDAD II: SERVIDOR DNS ISC BIND9...23
Tema 1: ISC BIND... 23
Tema 2: Instalación de BIND9 sobre Canaima GNU/Linux...25
Archivos de registro básico...25
Elementos de configuración del servicio...26
Parámetros globales de operación del servicio...26
Tema 3: Puesta en funcionamiento de una infraestructura DNS...28
Despliegue de un servidor de DNS cache...28
Pruebas de funcionamiento...29
Despliegue de un servidor DNS maestro autoritario...31
Declaración de la zona DNS directa y la zona DNS reversa...31
Ejemplo de un registro o cabecera SOA en un archivo de zona...33
Ejemplo del contenido de un archivo de zona...35
Ejemplo del contenido de un archivo de zona reversa...36
Pruebas de funcionalidad...37
Despliegue del servidor DNS esclavo autoritario...39
Despliegue de subdominios DNS...40
Ejercicio práctico del curso...41
Solución del ejercicio... 42
GLOSARIO DE TÉRMINOS... 46
FICHA DESCRIPTIVA
CURSO: Sistema de Resolución de Nombres (DNS) en Canaima GNU/Linux.
MODALIDAD: a distancia. DURACIÓN: 3 semanas.
DIRIGIDO A: público y comunidad en general, así como personal docente, técnico y estudiantil de Colegios Universitarios y Politécnicos.
REQUISITOS PREVIOS: nociones básicas en el manejo de: • Permisos y ACL POSIX.
• Gestión de usuarios y permisos bajo Linux. • Manejo de servicios SysV.
• Gestión de procesos POSIX. • Manejo de Linux bajo CLI.
• Herramientas de paginación y visualización de texto. • Manejo del sistema de paquetes APT.
OBJETIVO DEL CURSO: comprender los procedimientos para la configuración de un servicio de DNS en GNU/Linux.
INTRODUCCIÓN
El Domain Name System (DNS) es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet.
Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. Anteriormente se alojaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos, pero el crecimiento masivo de la red hizo que este procedimiento no resultara práctico y entonces se cuenta hoy en día con esta base de datos distribuida que almacena gran cantidad de información.
A lo largo de este manual podremos estudiar y comprender los diferentes procedimientos que nos permitirán realizar la configuración de servicios de DNS en ambiente GNU/Linux.
UNIDAD I: BASES DEL SISTEMA DE NOMBRES DE DOMINIO – DNS
Tema 1: Fundamentos de DNS
El DNS1 es un sistema de nombres que permite traducir de nombres de dominio a
direcciones IP y viceversa. Aunque la comunicación en Internet sólo funciona en base a direcciones IP, el DNS permite que usemos nombres de dominio que además de ser más simples de recordar, permiten una abstracción útil para los usuarios en general
Elementos de un Sistema de nombres de dominio
Sistema que, al recibir una petición para resolver un nombre o una dirección, consulta su base de datos interna de equipos conocidos u otro sistema DNS para entregar bien sea la dirección IP de un dominio, o, si se le provee la dirección IP conocida, este 1 Sistema de Nombre de Dominio, por sus siglas en inglés. (Domain Name System)
devuelve el nombre de equipo y dominio al que pertenece.
Son programas que se ejecutan en la computadora del usuario y que generan peticiones DNS de resolución de nombres a un servidor DNS. Por ej: ¿qué dirección IP corresponde a www.venezuela.com?.
La configuración de equipos cliente DNS suele implicar la ejecución de las siguientes tareas administrativas:
• Configurar en el computador cliente los nombres para cada computador en la red. • Configurar un sufijo DNS principal para el computador. El sufijo DNS principal del
equipo es el nombre del dominio del cual este es miembro.
• Identificar los servidores DNS para los clientes y así realizar la consulta de resolución de nombres de forma rápida. Puede configurar los servidores DNS preferidos y alternativos. Los servidores DNS alternativos o suplentes se consultan cuando el preferido no contesta.
• Edición del archivo /etc/resolv.conf2, cuyo formato básico es el siguiente:
Línea Campo Valor
1 domain (dominio) Opcional
Un nombre de dominio que se agregará a los nombres consultados que no terminen en punto (.) , el formato de este valor es una cadena. p.ej: “domain midominio.com”. Solo puede existir una línea domain.
2 Resolv.conf(5) - Linux man page (consultado mayo 2009), “resolv.conf - resolver configuration file”. Disponibleen: http://linux.die.net/man/5/resolv.conf
2 search (búsqueda) Opcional
Una entrada de búsqueda define los dominios en que se buscará para resolver los nombres de host (máquina). p. ej: “search midominio.com cantv.net”, esta línea puede tener un máximo de 1024 caracteres. Es importante recalcar que search y domain son mutuamente excluyentes, se utilizará la última en aparecer en el archivo de existir ambas. 3 nameserver
(servidor de nombres o DNS) Obligatoria
Pueden existir un máximo de 3 entradas nameserver, (ya que las posteriores se ignorarán) y debe existir al menos una. ejemplo: “nameserver 192.168.1.1”. El orden en el cual se coloquen los servidores DNS es predominante para la rapidez de las consultas, y de no responder alguno especificado se procederá al próximo. En caso de solo existir una entrada nameserver, cuya IP no responda a la solicitud, el sistema será incapaz de resolver un nombre del host que no exista en su archivo /etc/hosts.
Nombres de dominio: son direcciones nemotécnicas o alias que identifican un sitio de Internet. Esta dirección, es la "traducción" a caracteres alfanuméricos de una dirección IP, que en realidad es lo que entienden los enrutadores que hacen la conexión del usuario hacia el sitio requerido. Cada dominio es único en Internet.
Zonas DNS: permiten al servidor maestro o primario cargar la información de una zona. Cada zona de autoridad abarca al menos un dominio y posiblemente sus sub-dominios, si estos últimos no son delegados a otras zonas de autoridad. La información de cada zona de autoridad es almacenada de forma local en un archivo en el servidor DNS.
Sistema jerárquico de nombres de dominio
El sistema de nombres de dominios en Internet es un sistema distribuido, jerárquico, replicado y tolerante a fallas. Aunque estos objetivos parecen muy difíciles de lograr, la solución no es tan compleja en realidad. El punto central se basa en un árbol que define la jerarquía entre los dominios y los subdominios.
En un nombre de dominio, la jerarquía se lee de derecha a izquierda. Por ejemplo, en lab.dominio.com, el dominio más alto es com. Para que exista una raíz del árbol, se puede ver como si existiera un punto al final del nombre: lab.dominio.com., y todos los dominios están bajo esa raíz (también llamada ``punto"). Un término que veremos comúnmente será FQDN3, lo que se refiere a un nombre como www.misitio.com.
Un nombre de dominio usualmente consiste en dos o más partes4 , separadas por
puntos cuando se las escribe en forma de texto. P. ej. www.mohamedali.org. En este último ejemplo la etiqueta ubicada más a la derecha se le llama dominio de nivel superior o TLD5. Como org en www.mohamedali.org.
Cada etiqueta a la izquierda especifica una subdivisión o subdominio. Nótese que estos expresan dependencia relativa, no dependencia absoluta. En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta puede contener hasta 63 caracteres, pero restringidos a que la longitud total del nombre de dominio no exceda los 255 caracteres, aunque en la práctica los dominios son casi siempre mucho más cortos.
3 Nombre de dominio completamente calificado, por sus siglas en inglés 4 Técnicamente, etiquetas
Finalmente, la parte más a la izquierda del dominio suele expresar el nombre de la máquina6. El resto del nombre de dominio simplemente especifica la manera de crear una
ruta lógica a la información requerida. Por ejemplo, el dominio es.wikipedia.org tendría el nombre de la máquina "es", aunque en este caso no se refiere a una máquina física en particular.
Dominios y servidores raíz
Ejemplo de la jerarquización de dominios y subdominios
La raíz del sistema de dominios es provista por algunos servidores ''bien conocidos o autorizados'', llamados servidores raíz. Todo servidor de nombres debe ser configurado con la lista de los servidores raíz conocidos (en general, vienen de fábrica configurados con estos valores).
Estos servidores dicen cuales dominios de primer nivel existen y cuales son sus 6 Comúnmente llamado nombre de host o hostname
servidores de nombres. Recursivamente, los servidores de esos dominios dicen qué subdominios existen y cuales son sus servidores.
Existen trece (13) servidores raíz principales en toda Internet distribuidos en diferentes partes de la red. Cuyo nombre sigue la convención: letra.root-servers.net Estos servidores reciben miles de consultas por segundo, la mayoría no está compuesta de un solo nodo, en cambio, su carga está distribuida entre varios servidores que pueden estar o no en regiones geográficas cercanas.
Letra
Dirección IP
Operador
Ubicación
A 198.41.0.4 VeriSign Dulles, VA, EEUU.
B 192.228.79.201 USC-ISI Marina del Rey, CA, EEUU. C 192.33.4.12 Cogent Communications, Inc. Distribuido. D 128.8.10.90 Universidad de Maryland College Park, MA, EEUU.
E 192.203.230.10 NASA Mountain View, CA, EEUU.
F 192.5.5.241 ISC Distribuido.
G 192.112.36.4 Agencia de Defensa de los Sistemas de Información Columbus, OH, EEUU.
H 128.63.2.53 de la Armada EstadounidenseLaboratorio de Investigación Campos de prueba de Aberdeen, MA, EEUU. I 192.36.148.17 Autonomica/NetNod Distribuido.
J 192.58.128.30 VeriSign Distribuido.
K 193.0.14.129 RIPE NCC Distribuido.
L 199.7.83.42 ICANN Distribuido.
M 202.12.27.33 Proyecto WIDE Distribuido.
Dominios nivel superior
El sistema DNS permite la resolución en ambas direcciones. La conversión hacia adelante convierte los nombres en direcciones IP, y la resolución reversa convierte direcciones IP en nombres. Existen muy pocos dominios de nivel superior, pero en cada nivel se despliegan muchos más. Siguiendo esta lógica, las direcciones IP deben tener también un dominio de alto nivel. Este dominio se llama in-addr.arpa.
Diagrama de resolución reversa de un nombre de host
A diferencia del FQDN, como se muestra en el gráfico anterior, las direcciones IP se resuelven de izquierda a derecha, una vez que están bajo el dominio in-addr.arpa. Cada octeto de una dirección IP reduce aún más los posibles nombres de máquinas. Esta resolución devuelve nombres FQDN para las búsquedas hechas por direcciones IP. Los grandes proveedores de servicio, y en algunos casos las empresas, son quienes se hacen cargo de las zonas de resolución una resolución reversa.
Tema 2: Tipos de servidores DNS
Servidores DNS Autoritarios
Los servidores DNS autoritarios hacen visibles y accesibles los servicios de red para los usuarios. Mientras los servicios de redes IP crecen para incluir nuevos canales de comunicación y aplicaciones, el rol del servidor autoritario se torna más crítico.
La experiencia inicial del usuario como cliente o suscriptor de los servicios de red es usualmente a través de los servidores autoritarios de dominios (nombres), los cuales ayudan a los clientes para recibir los servicios de una manera rápida y consistente. El rendimiento y la fiabilidad son esenciales a la experiencia del cliente usuario. En el encontramos los siguientes servidores:
Servidor DNS maestro. Los servidores DNS maestros, son los que se consideran autorizados para uno o más dominios en particular, en estos residen los archivos de configuración de los dominios para los cuales responden en forma autoritativa. Cuando se produzca una actualización de las tablas de dominio DNS se harán en este servidor.
Servidor DNS esclavo. Los servidores DNS esclavos se encargan de copiar la información de los servidores maestros, de manera que si el servidor maestro deja de funcionar, el servidor esclavo retoma el trabajo y puede seguir proporcionando información sobre las zonas.
Servidor de cache DNS
Este tipo de servidores DNS no poseen archivos de configuración de ningún dominio, en cambio, cuando una máquina cliente realiza una petición a un servidor DNS cache para que resuelva un nombre, este servidor comprueba su cache7 local. Si no
encuentra un registro, buscará en un servidor primario y le preguntará por la dirección de ese servidor, luego, esta respuesta del primario pasará a un cache que este mantiene. Un servidor DNS cualquiera podría actuar como cache de otros dominios sin importar si son primarios o secundarios, siempre que sea configurado para reenviar las peticiones.
7 En informática, cache es todo duplicado del una información original que se almacena en un lugar de acceso más rápido que el original.
Tema 3: Proceso de resolución de nombres de dominio y resoluciones
reversas
Cuando una aplicación (cliente) necesita resolver un FQDN envía un requerimiento al servidor de nombres configurado en el sistema, el cual es normalmente entregado por el proveedor de servicios. A partir de entonces se desencadena el proceso de resolución del nombre:
1. El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente). 2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
3. El servidor inicial interroga al nuevo servidor.
4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
6. El servidor resuelve el nombre correspondiente, si este existe.
7. El servidor inicial informa al cliente el nombre resuelto.
Si el proceso es con una IP, es decir, una resolución reversa, el proceso es idéntico, solo que se sigue al servidor con la raíz in-addr.arpa para la dirección IP particular para la cual se desea conocer el nombre FQDN.
Supongamos que el navegador necesita resolver el nombre “blog.smaldone.com.ar“.
1. El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto envía a éste el requerimiento de resolver “blog.smaldone.com.ar“.
2. El servidor de 200.49.156.3 envía la consulta al servidor raíz 198.41.0.4.
3. 198.41.0.4 le informa que el servidor con autoridad sobre el dominio de nivel superior “ar” es athea.ar, cuya dirección IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)
4. 200.49.156.3 envía nuevamente el requerimiento a athea.ar (el cual, recordemos, también tiene autoridad sobre “com.ar“).
5. athea.ar responde que la autoridad sobre smaldone.com.ar la tiene ns1.mydomain.com cuya dirección IP es 64.94.117.213.
6. 200.49.156.3 envía ahora la consulta a ns1.mydomain.com.
7. ns1.mydomain.com informa que la dirección IP de “blog.smaldone.com.ar” es 208.97.175.41.
8. Finalmente, 200.49.156.3 devuelve este resultado a la aplicación que originó la consulta.
Tema 4: Registros DNS
Estructura y elementos de un registro DNS
El servidor ISC BIND8 trabaja en la capa de aplicación. Si el segmento a enviar es
menor a 512 Bytes utiliza el protocolo UDP, de lo contrario utiliza el protocolo TCP.
El número de puerto que utiliza el protocolo DNS para comunicarse con la capa de aplicación es el número 53. Todos los mensajes generados por el protocolo DNS, sean o no generados por la implementación de referencia ISC BIND, utilizan un único formato de cabecera, descrito a continuación:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 Internet Systems Consortium (consultado abril 2009), “ISC BIND”. Disponible en:
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Cabecera del protocolo DNS
Descripción del contenido de una cabecera DNS
ID. Es un identificador de dieciséis (16) bits asignado por el programa. Este identificador se copia en la respuesta correspondiente del servidor de nombres y se puede usar para diferenciar respuestas cuando concurren múltiples consultas.
QR. Bandera de un bit que indica consulta (0) o respuesta (1).
Opcode. Código de operación. campo de cuatro (4) bits que especifica el tipo de consulta:
0 consulta estándar (QUERY). 1 consulta reversa (IQUERY).
2 solicitudes del estado del servidor (STATUS). - Se reservan los otros valores para su uso en el futuro.
• AA. Bandera de respuesta autoritativa. Si está activa en una respuesta, especifica que el servidor de nombres que responde tiene autoridad para el nombre de dominio enviado en la consulta.
• TC. Bandera de truncado. Se activa si el mensaje es más largo de lo que permite la línea de transmisión.
• RD. Bandera de recursividad. Este bit se copia en la respuesta e indica al servidor de nombres una resolución recursiva.
• RA. Bandera de recursividad disponible. Indica si el servidor de nombres soporta resolución recursiva.
• RCODE. Código de respuesta de cuatro (4) bits. Los posibles valores son: 0. Ningún error.
1. Error de formato. El servidor fue incapaz de interpretar el mensaje.
2. Fallo en el servidor. El mensaje no fue procesado debido a un problema con el servidor.
3. Error en nombre. El nombre de dominio de la consulta no existe. Sólo válido si el bit AA está activo en la respuesta.
4. No implementado. El tipo solicitado de consulta no está implementado en el servidor de nombres.
5. Rechazado. El servidor rechaza responder por razones políticas. Los demás valores se reservan para su usuario en el futuro.
• QDCOUNT. Un número entero sin signo de 16 bits que especifica el número de entradas en la sección "question".
• ANCOUNT. Un número entero sin signo de 16 bits que especifica el número de registros en la sección "answer".
• NSCOUNT. Un número entero sin signo de 16 bits que especifica el número de registros la sección "authority".
• ARCOUNT. Un número entero sin signo de 16 bits que especifica el número de registros en la sección "additional records".
Tipos de registros DNS
• MX (Mail exchanger). Este registro especifica el FQDN de el servidor dentro del dominio consultado que está encargado de recibir el correo electrónico para ese dominio.
• NS (Name server). Servidor de nombres. Este registro posee la información de los servidores de nombres autoritativos y esclavos asociados con uno o más dominios, es crucial y se considera una práctica altamente recomendada para los servidores de nombres alrededor de la Internet tener la posibilidad de contactar a más de un servidor de nombres para un dominio de manera de proveer tolerancia a fallos, en caso de que alguno de los primarios se encuentre inalcanzable.
• LOC (Localizator). Localización. Este registro contiene coordenadas en latitud y longitud de la ubicación en el planeta del servidor de nombres consultado.
• PTR (Pointer). Registro apuntador. Este registro posee el registro in-addr.arpa principal del dominio, de manera de ubicar los registros reversos que están presentes en el dominio y está comprendido por direcciones IP.
• A (Address). Dirección, este registro es el que contiene la dirección IP de un nombre particular dentro del dominio. P. ej: www.dominio.com tiene un registro tipo “A” con la dirección: 192.204.44.12, lo que significa que a www.dominio.com le corresponde la dirección: 192.204.44.12. También existe el registro “AAAA” para direcciones IP de 128bit del protocolo IPv6.
• CNAME (Canonical Name). Nombre canónico. Es un alias para un nombre determinado, no define direcciones IP. p.ej: se puede definir: ejemplo.dominio.com como un nombre canónico para www.dominio.com, lo que quiere decir que una misma IP en un registro tipo “A”, pertenece tanto a: www.dominio.com como a ejemplo.dominio.com.
• TXT (Text). Registro de texto, en este campo se almacena un texto que puede ser entregado a los clientes DNS para la consulta de algún parámetro adicional. Entre sus usos más habituales está la configuración de SPF9, o para guardar un registro
de una llave pública para los clientes de una red privada virtual segura que pertenece al dominio donde se encuentra configurada.
9 Wikipedia (modificada por última vez el 09:16, 4 mar 2009), “Sender Policy Framework”. Disponible en:
• SRV (Server). Registro de servidor, estos registros especiales son usualmente utilizados para hacer difusión de servicios provistos por uno o más servidores dentro de la red.
• SOA (Start of authority). Inicio de autoridad, este registro contiene los datos principales de cabecera de la zona, como su última fecha de modificación, tiempos de vida para su refrescamiento contra otros servidores de nombre y tiempos de expiración para clientes que hacen consultas al mismo.
Tipos de consultas DNS
Consultas iterativas.
El cliente hace una consulta al servidor DNS y este le responde con la mejor respuesta que pueda darse basada sobre su cache o en las zonas locales. Si no es posible dar una respuesta, la consulta se reenvía hacia otro Servidor DNS repitiéndose este proceso hasta encontrar al Servidor DNS que tiene la Zona de Autoridad capaz de resolver la consulta.
Consultas recursivas
El servidor DNS asume toda la carga de proporcionar una respuesta completa para la consulta realizada por el cliente DNS. El servidor DNS desarrolla entonces consultas iterativas separadas hacia otros servidores DNS (en lugar de hacerlo el cliente DNS) para obtener la respuesta solicitada.
UNIDAD II: SERVIDOR DNS ISC BIND9
Tema 1: ISC BIND
BIND, como ya es sabido, significa: Berkeley Internet Name Domain, es la implementación del estándar DNS de uso más habitual en la Internet, especialmente en los sistemas tipo Unix, en los cuales es un estándar de facto. Es patrocinado y desarrollado por la Internet Systems Consortium10. BIND fue creado originalmente por
cuatro estudiantes de grado en la universidad de california en Berkeley y liberado por primera vez en el sistema operativo 4.3BSD. Paul Vixie comenzó a mantenerlo en 1988 mientras trabajaba para la Digital Equipment Corporation.
La última versión del popular sistema de resolución de nombres, es una reescritura total del código de la aplicación, principalmente para hacer frente a necesidades de rendimiento, seguridad, facilidad de configuración y operación, además de incluir las últimas características del estándar que rige al protocolo DNS.
Este software contiene tres partes importantes:
• Un servidor de resolución de nombres (DNS): es un programa, cuyo nombre es: named, y significa demonio de nombres, su función es, principalmente, contestar a las preguntas sobre nombres de dominios recibidas por red, siguiendo para ello, los estándares de Internet acerca de DNS.
• Una librería de resolución de nombres: cuya función es enviar las preguntas recibidas por named a los servidores de nombres, inclusive cuando el dominio por el que se pregunta no es un dominio manejado directamente por la instalación actual. Una ventaja de esta separación, es que cualquier programador que deba preocuparse por escribir funciones que se encarguen de la resolución de nombres 10 Internet Systems Consortium (consultado abril 2009), “Internet Systems Consortium”. Disponible en:
en su programa, que podría ser, por ejemplo, un navegador web, sólo necesita integrar su programa a esta librería, la cual le ahorrará la necesidad de escribir funciones de resolución de nombres y cometer posibles errores desviándose del estándar DNS que está implementado en la librería que provee BIND.
• Herramientas para la prueba de los servidores: Permiten al usuario hacer pruebas extensivas de funcionamiento de los servicios DNS de BIND.
Tema 2: Instalación de BIND9 sobre Canaima GNU/Linux
La instalación de un servidor DNS es sencilla. Está a cargo del paquete bind9 y a continuación veremos como realizarla:
aptitude install bind9 dnsutils
Archivos de registro básico
Los siguientes archivos son parte básica de cualquier instalación BIND, en ellos se mantiene información básica de operación local para el servidor de nombres, como norma común de la configuración de BIND, todos sus archivos de configuración están bajo el directorio /etc/bind.
/etc/bind/db.local. Datos de resolución directa para interfaz local "loopback".
/etc/bind/db.127. Datos de resolución reversa para interfaz local "loopback".
/etc/bind/db.0. Registros inversos para zona de difusión, según lo requerido por las normas.
/etc/bind/db.255. Registros inversos para zona de difusión, según lo requerido por las normas.
/etc/bind/db.root. Información de servidores de nombres raíz de Internet, autoridades máximas en servicio de nombres; estos servidores son la referencia esencial para iniciar la actividad del servidor DNS local en búsqueda de nombres por Internet.
Elementos de configuración del servicio
Los elementos de configuración que encontramos en el proceso de instalación del servicio son:
/etc/bind. Archivos de configuración, archivos de números IP y nombres de máquinas de la zona local atendida por esta máquina.
/var/cache/bind. Directorio de trabajo donde bind guarda la información sobre números IP y nombres de máquinas que va recogiendo en sus actividades de búsqueda consultando otras máquinas DNS de la red.
Parámetros globales de operación del servicio
A continuación se presentan los archivos con los parámetros globales de operación del servicio:
/etc/bind/named.conf. Archivo de configuración para el servidor DNS local. Aquí figuran todos los nombres de archivos locales consultados, direcciones de servidores DNS próximos y ajustes de operación para el DNS.
/etc/bind/named.conf.options. Opciones genéricas. /etc/bind/named.conf.local. Especificación de configuración para este servidor DNS.
/etc/bind/rndc.key. Llave cifrada para la comunicación con el servidor de nombres en comunicaciones TCP con
autenticación, también es útil para la comunicación con el servidor de protocolo de configuración de host dinámico: DHCP11
/etc/bind/zones.rfc1918. Direcciones IP válidas especificadas en el RFC191812 para diseñar redes privadas
o intranets y recomendadas cuando se experimenta con redes. Estas son: 10. - 172.16 – 172.31 y 192.168
/etc/bind/db.empty. Archivo vacío de ejemplo.
11 Fábrega, Pedro Pablo (consultado mayo 2009), “DHCP Guía básica”. Disponible en: http://dns.bdat.net/dhcp/
12 Rekhter, Y., Moskowitz B.(Febrero 1996), “Asignación de direcciones para Internet privadas”, Network Working Group. Disponible en: http://www.rfc-es.org/rfc/rfc1918-es.txt
Tema 3: Puesta en funcionamiento de una infraestructura DNS
El primer paso a seguir para configurar un servidor DNS implica la edición de los archivos /etc/bind/named.conf, /etc/bind/named.conf.options y /etc/bind/named.conf.local, respectivamente. El primero de estos archivos se considera el archivo maestro y según el esquema de configuración, el mismo no debería (en la mayoría de los casos) ser modificado ya que las configuraciones adicionales se pueden realizar en named.conf.local y named.conf.options.
Despliegue de un servidor de DNS cache
Por defecto al instalar BIND, este actuará como un servidor cache. Recordemos que la función de un servidor cache es consultar a otros servidores DNS, por lo que las respuestas de esas consultas realizadas por los clientes, se almacenan en el cache del servidor local. Veremos a continuación los pasos para configurar los clientes y el servidor para realizar las pruebas del funcionamiento del servidor DNS cache.
Configuración de DNS cache
• Configuración del Cliente. Es necesario editar el archivo /etc/resolv.conf de la siguiente forma:
editor /etc/resolv.conf
search pruebadns.org cantv.net nameserver (Servidor DNS LOCAL) nameserver (Dirección IP DNS1) nameserver (Dirección IP DNS2)
/etc/bind/named.conf.options y localizaremos la línea que tiene comentados los forwarders13. Aquí asignaremos los DNS externos a los cuales podrán consultar:
editor /etc/bind/named.conf.options forwarders {
200.44.32.12; };
Nota: En este caso se coloco en forwarders la dirección IP del
servidor DNS de CANTV, lógicamente esto puede variar según su
proveedor de servicios de Internet.
Luego de haber editado los archivos correspondientes en el cliente y en el servidor, reiniciaremos los servicios:
En el cliente:
invoke-rc.d networking restart En el servidor:
invoke-rc.d bind9 restart
Pruebas de funcionamiento
Para realizar las pruebas de funcionamiento utilizaremos el comando “dig”14:
13 Forwarders: (castellano: reenviadores), para denotar los servidores DNS que el servidor DNS local consultará para obtener la información de nombres y direcciones IP de dominios que no tiene configurados localmente.
http://www.scribd.com/doc/7549379/IMSI-dig www.yahoo.com
Buscaremos una línea casi al final de la respuesta de la consulta realizada: ;; Query time: 97 msec
;;SERVER: 190.75.126.72#53(190.75.126.72) ;; WHEN: Sat May 19 17:06:08 2007
;; MSG SIZE rcvd: 403
Vemos que la consulta anterior ha tardado 97 milisegundos. Ahora, si realizamos la consulta nuevamente tendremos un cambio:
;; Query time: 9 msec
;;SERVER: 190.75.126.72#53(190.75.126.72) ;; WHEN: Sat May 19 17:09:26 2007
;; MSG SIZE rcvd: 403
La consulta ahora ha tardado tan solo 9 milisegundos. ¿Por qué?, la respuesta es sencilla: anteriormente hemos consultado www.yahoo.com; ya que nuestro servidor DNS no poseía la información, debió consultar a alguno de sus DNS reenviadores, que a su vez, debieron consultar a otros servidores DNS, sin embargo, al realizar la segunda vez esta consulta, no se realizo una consulta a un servidor DNS externo, ya que la información de la dirección para www.yahoo.com entró en el cache de nuestro servidor DNS local, lo que optimiza las consultas a nombres de maquinas externas a nuestra red local. También puede hacerse una
prueba ad-hoc al intentar abrir una página web más de una vez y comparar los tiempos de respuesta para la resolución de nombres.
Nota: No olvidemos revisar constantemente los registros /var/log/messages y /var/log/daemon.log, si deseamos obtener mayor información de las actividades de los servicios asociados con BIND.
Despliegue de un servidor DNS maestro autoritario
Declaración de la zona DNS directa y la zona DNS reversa
Ahora configuraremos un dominio simple. Para ello solo debemos crear dos archivos nuevos. Una zona directa y una zona reversa para la resolución de nombres a IP y viceversa. Agregaremos esta información sobre nuestro dominio al archivo /etc/bind/named.conf.local: editor named.conf.local //resolución directa. zone "dominio.com" { type master; notify no; file "/etc/bind/db.dominio"; }; // resolución reversa. zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.168.192";
};
• La orden zone especifica la zona que estamos configurando, si es reversa, es común que el nombre posea el rango de direcciones IP escritas de derecha a izquierda en el nombre del archivo, de manera de ubicar la zona con facilidad al explorar el directorio.
• El parámetro notify, indica si debemos notificar cambios en la zona a algún otro servidor, en este ejemplo, no se está notificando a ningún otro servidor.
• El parámetro file, indica el nombre de archivo de donde se leerá la zona, o “archivo de zona”.
• El parámetro type, indica si el servidor DNS configurado es maestro o esclavo, si es maestro la orden type es precedida por master, en caso contrario, es precedida por la palabra slave.
Archivos de zona DNS
La información de cada zona de autoridad es almacenada de forma local en un archivo en el servidor DNS. Este archivo puede contener varios tipos de registros, como se especificó anteriormente, aunque, obligatoriamente deben poseer el registro de tipo SOA, que normalmente también es conocida como cabecera SOA. Estos archivos de zona tienen dos partes importantes, la cabecera SOA, que contiene información acerca de la zona especificada presente en el archivo y el contenido en sí, que puede estar compuesto por registros de diferentes tipos para el dominio o subdominio. El archivo de zona es entonces creado según el nombre declarado en named.conf.local a través de la palabra reservada file. Siguiendo nuestro ejemplo, el archivo en este caso es “db.dominio”
Ejemplo de un registro o cabecera SOA en un archivo de zona
$TTL 86400 ;Tiempo de vida
@ IN SOA ns.dominio.com. root.dominio.com. (
1 ;Serial
6048000 ;Tiempo de refrescamiento
86400 ;Tiempo de reintento
2419200 ;Expiración
86400 ); ;Tiempo de vida para el cache negativo
Nota: Los archivos de zona, en todo su contenido (cabecera SOA y registros) están constituidos por información en texto plano separada por tabulaciones, que deben ser respetadas ya que es la forma correcta en que BIND las interpreta al leerlas.
El registro de recursos SOA o cabecera SOA, contiene la siguiente información:
• Tiempo de vida mínimo, o TTL15. El valor del tiempo de vida mínimo se aplica a todos los registros de diferentes tipos presentes en el contenido del archivo de zona. Este valor se proporciona en respuestas de consulta para informar a otros servidores cuánto deben mantener los datos en cache.
• El nombre del computador en el que se creó el archivo zona de origen.
• Serial: el número de revisión de este archivo de zona. Se debe incrementar este número cada vez que cambie el archivo de zona. Es importante incrementar este 15 Tiempo de vida mínimo, por sus siglas en inglés: time to live
valor cada vez que se realiza un cambio, para que los cambios se distribuyan a los servidores DNS esclavos o a los clientes (que podrían ser otros servidores DNS) y estos puedan saber que la información fue cambiada.
• Tiempo de refrescamiento: usando caduca el tiempo de refrescamiento, un servidor de DNS esclavo solicitará una copia del registro SOA actual desde el maestro. El servidor maestro DNS cumple con esta solicitud, entonces el servidor de DNS esclavo compara el número de serie del registro SOA actual del servidor DNS maestro y el número de serie en su propio registro SOA. Si estos difieren, el servidor de DNS esclavo solicitará una transferencia de zona desde el servidor DNS maestro.
• Tiempo de reintento: tiempo de espera de un servidor DNS esclavo antes de intentar una transferencia de zona con errores. Normalmente, el tiempo de reintento es menor que el tiempo de refrescamiento.
• Tiempo de expiración: tiempo durante el cual un servidor esclavo seguirá intentando completar una transferencia de zona. Si se agota este tiempo antes de una transferencia de zona correcta, el servidor esclavo expirará automáticamente su archivo de zona. Lo que significa que detendrá la respuesta de las consultas, ya que considera sus datos muy poco confiables, por su antigüedad, como para ser válidos.
• Tiempo de vida para el cache negativo: el cache negativo es aquel cache en que se almacenan entradas de DNS que se saben no resolvibles, es decir, no existen respuestas válidas, para el servidor que consulta acerca de una entrada en particular, como de igual manera, el servidor podría estar resolviendo una diferente cantidad de dominios, que muy probalmente sean ajenos a sus zonas, también se les aplica un tiempo de vida máximo, ya que, de existir la información actualizada y válida, querremos proveerla a los clientes en un futuro cercano, que naturalmente será refrescada cuando el tiempo de vida máximo para el cache negativo cese.
Un ejemplo de la cabecera SOA puede extraerse del archivo /etc/bind/db.empty , también puede, opcionalmente, iniciar la configuración de este ejemplo copiando db.empty con el nombre de archivo de zona especificado con anterioridad en: /etc/bind/named.conf.local
cp /etc/bind/db.empty /etc/bind/db.dominio
Ejemplo del contenido de un archivo de zona
IN NS dns1 ;Registro NS
dns1 IN A 192.168.8.7
siga IN A 192.168.8.9 ;Registro A (dirección IP)
licitaciones IN CNAME siga ;Registro CNAME (alias)
Los registros de tipo NS usualmente están de primero luego de la cabecera SOA del archivo de zona, ya que apuntan al nombre del servidor de nombres principal del dominio para la zona que se está describiendo. Por otro lado, el registro NS debe estar acompañado de un registro tipo A que mencione la dirección IP del servidor de nombres. A esta combinación se le llama: registro GLUE16, ya que “pega”, si se quiere, ambos registros para su correcto funcionamiento, este registro glue, es una práctica bien aceptada en el estándar de operación de DNS. Como se mencionó anteriormente, el archivo de zona en este ejemplo se llama: /etc/bind/db.dominio
Los registros siguientes a la combinación antes descrita, suelen ser registros tipo A, con direcciones IP específicas de los equipos o hosts presentes en la red. No es inusual conseguir registros con definiciones de alias (registros CNAME) para un mismo host, ya que usualmente se desea conseguir al mismo equipo aún con nombres diferentes. Esto es especialmente común en los subdominios.
En el caso de la resolución reversa, se repite el proceso anterior, así, creando el archivo maestro de la zona para la resolución reversa.
Ejemplo del contenido de un archivo de zona reversa
$ORIGIN .
168.192.in-addr.arpa
IN
SOA dominio.com. root.dominio.com. (
1
62
3600
70
38400 );
$ORIGIN 168.192.in-addr.arpa.
IN
NS
dns1
9.8
IN
PTR dns1.dominio.com.
7.8
IN
PTR siga.dominio.com.
Podrá observarse como se coloca el fragmento de octetos faltantes en el archivo, de manera que al completar con la zona reversa “168.192” se completen los cuatro octetos de la dirección IP en forma consistente para que la resolución de IP a nombre sea exitosa. Esta misma información, podríamos volcarla en el archivo de nuestro ejemplo “/etc/bind/db.168.192”, adicionalmente, la palabra clave “$ORIGIN” junto con la especificación de la parte de la zona, es necesaria, para especificar de forma correcta en que parte de la zona se debe comenzar la búsqueda inversa de la IP que deseamos resolver. Cuando la palabra clave “$ORIGIN” le precede un “.” significa que estamos especificando que estamos en la parte más superior de la zona.
Pruebas de funcionalidad
Antes de realizar las pruebas, debemos configurar nuestro sistema de ejemplo para que busque prioritariamente a nuestro servidor de nombres, esto se hace, editando el archivo “/etc/resolv.conf” y colocando en él, la siguiente información:
editor /etc/resolv.conf
search dominio.com (dominio de ejemplo)
nameserver 127.0.0.1 (DNS Local
configurado)
nameserver (Dirección IP DNS Adicional, si aplica)
Para realizar entonces las pruebas de funcionamiento, arrancaremos bind e inmediatamente, chequearemos los registros utilizando el comando tail17:
invoke-rc.d bind9 restart tail -f /var/log/syslog
También, podemos probar haciendo ping a los equipos,pero utilizando nombres, lo cual nos mostrará o resolverá, la dirección IP del mismo:
ping siga
PING siga.dominio.com (192.168.8.9) 56(84) bytes of data.
64 bytes from siga.dominio.com
(192.168.8.9): icmp_seq=1 ttl=64 time=0.084 ms
64 bytes from siga.dominio.com
(192.168.8.9): icmp_seq=2 ttl=64 time=0.060 ms
...
O también, inclusive, mediante el uso de herramientas como los comandos dig, que ya mencionamos previamente y adicionalmente, el comando host18:
dig -x (ip-del-servidor) host (nombre de máquina)
http://www.monkey.org/cgi-bin/man2html?tail
18 Swoolley (consultado abril 2009), “host(1,5) - DNS lookup utility”. Disponible en:
Despliegue del servidor DNS esclavo autoritario
Ya con las configuraciones correctas en nuestras zonas, en el servidor maestro, puede que necesitemos al menos un servidor esclavo en la red local. Al hacerlo, se instala BIND en otro computador y se le agrega lo siguiente en el archivo: /etc/bind/named.conf.local zone “dominio.com” { type slave; file “/etc/bind/db.dominio; masters { 192.168.8.7; }; allow-notify { 192.168.8.7; }; }; zone "168.168.192.in-addr.arpa" { type slave; file "/etc/bind/db.8.168.192"; masters { 192.168.8.7; }; allow-notify { 192.168.8.7; }; };
No es necesaria la creación o copia de los archivos de zona “db.dominio” y “db.8.168.192”, ya que el servidor esclavo se encargará exclusivamente de crearlos, borrarlos y actualizarlos dependiendo de los cambios generados en el servidor DNS maestro. Si el servidor DNS maestro llegase a fallar, el servidor esclavo podrá hacer la resolución de nombres para todos los hosts del dominio mientras que se mantenga por debajo del parámetro SOA de refrescamiento, si el tiempo de refrescamiento llega y se
superan también los tiempos de expiración, se deberá intervenir en el servidor DNS maestro para devolverlo a funcionamiento, de manera que otorgue datos actualizados al servidor DNS esclavo.
Despliegue de subdominios DNS
Aunque las zonas regulares de cada servidor DNS maestro pueden tener tantos subdominios como se desee, es posible hacer que un DNS esclavo realice la resolución de nombres de un subdominio cualquiera del servidor DNS maestro, para esto, es necesario defiinir en el archivo /etc/bind/named.conf.local, una zona adicional que contendrá los registros SOA y demás para ese subdominio, p.ej:
zone “redes.dominio.com” { type master; file “/etc/bind/db.redes.dominio; masters { 192.168.8.7; }; allow-notify { 192.168.8.7; }; };
Cabe aclarar, que los registros aquí configurados, no expirarán después de un tiempo si, por ejemplo, el servidor de dominio maestro llegase a fallar, ya que es el servidor DNS esclavo y sólo él, quien posee la zona.
Ejercicio práctico del curso
Su unidad productiva es seleccionada para realizar la instalación de un servidor DNS cache para una red pequeña en la villa olímpica del estado Carabobo, ya que su enlace hacia la internet es deficiente y desean reducir los tiempos de espera para la resolución de nombres. Asimismo, poseen un servidor web donde alojan tres (3) diferentes aplicaciones web: una de administración de los recursos de la villa, otra para el seguimiento y registro del hospedaje de atletas y finalmente, la que utilizan para llevar el control de el rendimiento de los atletas en sus prácticas en las instalaciones de la villa olímpica; se desea acceder por nombre ya que tienen diferentes hosts virtuales configurados en el servidor web para la separación de cada aplicación.
Premisas del ejercicio:
1.La dirección IP del servidor DNS es 172.31.1.1 y su nombre es “dnsolimpica” 2.La dirección IP del servidor web es 172.31.1.120 y su nombre es “olimpicaweb” 3.El dominio calificado de la red es “villaolimpicacarabobo.org.ve”
4.Los servidores DNS externos entregados por el proveedor de servicios de internet son: 200.84.115.20 y 200.84.115.22
5.Los nombres por los que se debe acceder a las aplicaciones web son: administracion.villaolimpicacarabobo.org.ve,registro.villaolimpicacarabobo.org.ve y atletas.villaolimpicacarabobo.org.ve., todas ellas residen en “olimpicaweb” bajo diferentes hosts virtuales que ya han sido pre-configurados en el servicio web instalado en el mismo.
Solución del ejercicio
# Se instala el servicio de DNS y las utilidades
aptitude install bind9 bind9utils
# Editaremos el archivo /etc/bind/named.conf.local para
definir la zona local, allí agregaremos una definición para
la zona “villaolimpicacarabobo.org.ve”:
zone "villaolimpicacarabobo.org.ve" {
type master;
file "/etc/bind/villaolimpica.hosts";
};
#
Creamos el archivo
/etc/bind/villaolimpica.hosts,
agregándole una cabecera común de registro SOA que luego
modificaremos, para esto, podemos utilizar el archivo
db.empty que está ubicado en el directorio /etc/bind
cp /etc/bind/db.empty /etc/bind/villaolimpica.hosts
editor /etc/bind/villaolimpica.hosts
# Cambiaremos el registro SOA por defecto que hemos creado
al copiar el ejemplo para ajustarse a los parámetros que
deseamos,a continuación un ejemplo de una configuración
ideal modificada para ajustarse a este ejercicio:
villaolimpicacarabobo.org.ve.
IN SOA dnsolimpica.
root.localhost. (
1190304042
60
3600
70
38400 )
IN NS dnsolimpica
IN A
172.31.1.1
# Aquí puede observarse como se crea el registro “GLUE”
para la zona, al especificar que el DNS es “dnsolimpica”
seguido de un registro tipo “A” con su dirección IP, a
continuación luego del último registro tipo “A” agregaremos
los registros necesarios para el servidor web y los demás
nombres por los cuales también será conocido:
olimpicaweb IN A 172.31.1.120
administracion IN CNAME olimpicaweb
registro IN CNAME olimpicaweb
atletas IN CNAME olimpicaweb
# Ya hemos configurado la IP principal de olimpicaweb y
definido sus aliases (CNAME), ahora debemos configurar las
opciones del servidor de nombres para la resolución de
nombres que no pertenecen a la red de la villa olímpica,
para esto, es necesaria la edición del archivo
/etc/bind/named.conf.options
editor /etc/bind/named.conf.options
# La parte relevante de esta configuración, es la
definición de los “forwarders” que resolverán nombres
desconocidos para este servidor que nos encontramos
configurando, tomando en cuenta las direcciones IP
entregadas como servidores DNS de nuestro proveedor de
servicio de internet, las configuramos en este archivo:
forwarders {
200.84.115.20;
200.84.115.22;
};
# Al tener estos configurados, efectivamente estaremos
definiendo un cache DNS para cualquier equipo que no se
encuentre en las zonas locales de nuestro servidor DNS
# Por último, para que los clientes puedan resolver
apropiadamente tanto “olimpicaweb” como sus aliases, es
necesario editar su configuración DNS para que apunte al
nuevo servidor DNS, a través del archivo /etc/resolv.conf
(en el equipo cliente)
search villaolimpicacarabobo.org.ve
nameserver 172.31.1.1
# Ahora, podrá accederse a olimpicaweb tanto por su nombre
original como por administracion, registro y atletas,
además, el cliente aprovechará la cache de consultas a
cualquier otro dominio que ha sido delegada al servidor DNS
que acabamos de configurar.
GLOSARIO DE TÉRMINOS
• BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon): es la implementación del estándar DNS de uso más habitual en la Internet, especialmente en los sistemas tipo Unix, en los cuales es un estándar de facto.
• BIND9: es una nueva versión de BIND. Fue escrita desde cero en parte para superar las dificultades arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de BIND, y también para incorporar DNSSEC. BIND 9 incluye entre otras características importantes: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Es comúnmente usado en sistemas GNU/Linux. • Cache: es todo duplicado del una información original que se almacena en un
lugar de acceso más rápido que el original.
• Canaima: es una distribución GNU/Linux Venezolana basada en Debian que surge como una solución para cubrir las necesidades ofimáticas de los usuarios finales de la Administración Pública Nacional (APN) y para dar cumplimiento al decreto presidencial Nro. 3.390 sobre el uso de Tecnologías Libres.
• Cliente DNS: son programas que se ejecutan en la computadora del usuario y que generan peticiones DNS de resolución de nombres a un servidor DNS.
• Datagramas: es un fragmento de paquete que es enviado con la suficiente información como para que la red pueda simplemente encaminar el fragmento hacia el equipo terminal de datos receptor, de manera independiente a los fragmentos restantes.
• DHCP (Dynamic Host Configuration Protocol / Protocolo de Configuración Dinámica de Servidores): permite asignar IPs de forma dinámica, e indica servidores de nombre de dominios y gateways desde un servidor a todos los clientes que se la pidan.
• Direcciones IP: es un número que identifica de manera lógica y jerárquica a una interfaz de un dispositivo (habitualmente una computadora) dentro de una red que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red o nivel 3 del modelo de referencia OSI.
• Distribución: es una recopilación de programas y ficheros (paquetes), organizados y preparados para su instalación en las diferentes arquitecturas de hardware disponibles en el mercado, las cuales se pueden obtener a través de Internet, o adquiriendo los CD de las mismas.
• DNS (Domain Name System): es un sistema de nombres que permite traducir de nombres de dominio a direcciones IP y viceversa.
• DNSO (Domain Name Supporting Organization): es un cuerpo asesor que aconseja el ICANN el Consejo de Administración en la política referente al Sistema de Nombre de dominio.
• DNSSEC (DNS Security Extensions): es una suite de datos específicos IETF para asegurar ciertas clases de información proporcionada por el Sistema de Nombre de Dominio (DNS), como cuando es usado sobre el Protocolo de Internet (IP). Es un juego de extensiones a DNS que proveen a clientes DNS.
• Dominio: nombre básico de un conjunto de dispositivos y computadores dentro de una red, los equipos o dispositivos que lo componen cada uno posee un nombre perteneciente a ese dominio, que lo hace más fácil de recordar en vez de utilizar direcciones numéricas para acceder a los mismos.
• FQDN (Fully Qualified Domain Name): es un nombre que incluye el nombre de la computadora y el nombre del dominio asociado a ese equipo. La longitud máxima permitida para un FQDN es 255 caracteres (bytes), con una restricción adicional a 63 bytes por etiqueta dentro de un nombre de dominio. Las etiquetas FQDN se restringen a un juego de caracteres limitado: letras A-Z de ASCII, los dígitos, y el carácter «-», y no distinguen mayúsculas de minúsculas.
General de GNU o más conocida por su nombre en inglés GNU General Public License o simplemente su acrónimo del inglés GNU GPL, es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software.
• HTML (HyperText Markup Language / Lenguaje de Marcas de Hipertexto): es el lenguaje de marcado predominante para la construcción de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes.
• IP (Internet Protocol): el protocolo de comunicaciones IP permite que redes grandes y geográficamente diversas de computadoras, se comuniquen con otras rápida y económicamente a partir de una variedad de eslabones físicos.
• IPv4: es la versión 4 del Protocolo IP (Internet Protocol). Esta fue la primera versión del protocolo que se implementó extensamente, y forma la base de Internet. IPv4 usa direcciones de 32 bits, limitándola a 232 = 4.294.967.296 direcciones únicas, muchas de las cuales están dedicadas a redes locales (LANs). • IPv6: es una nueva versión de IP (Internet Protocol) y está destinado a sustituir a
IPv4, cuyo límite en el número de direcciones de red admisibles está empezando a restringir el crecimiento de Internet y su uso; pero el nuevo estándar mejorará el servicio globalmente; por ejemplo, proporcionará a futuras celdas telefónicas y dispositivos móviles con sus direcciones propias y permanentes.
• ISC BIND: el nombre completo original del servidor BIND9 desarrollado por la Internet Systems Consortium.
• LAN (Local Área Network): es la interconexión de varias computadoras y periféricos. Su extensión está limitada físicamente a un edificio o a un entorno de hasta 200 metros; su aplicación más extendida es la interconexión de computadoras personales y estaciones de trabajo en oficinas, fábricas, etc., para compartir recursos e intercambiar datos y aplicaciones.
sitio de Internet.
• Nsupdate: es una red de mantenimiento multiuso usada por administradores de redes para pedir el nombre del servidor de una zona DNS y actualizar su data. El nombre del servidor puede ser local o a un dominio o con una autenticación apropiada, y un permiso dado por dnssec un servidor de Internet.
• OSI (Open Source Initiative): es una organización dedicada a la promoción del código abierto. Fue fundada en febrero de 1998 por Bruce Perens y Eric S. Raymond.
• Servidor DNS: sistema que, al recibir una petición para resolver un nombre o una dirección, consulta su base de datos interna de equipos conocidos u otro sistema DNS para entregar bien sea la dirección IP de un dominio, o, si se le provee la dirección IP conocida, este devuelve el nombre de equipo y dominio al que pertenece.
• Servidores DNS autoritarios: hacen visibles y accesibles los servicios de red para los usuarios.
• SGML (Standard Generalized Markup Language / Estándar de Lenguaje de Marcado Generalizado): consiste en un sistema para la organización y etiquetado de documentos. El lenguaje SGML sirve para especificar las reglas de etiquetado de documentos y no impone en sí ningún conjunto de etiquetas en especial.
• Sistema Operativo: es un software que administra y controla las actividades, y recursos de la computadora. Comprende todos aquellos paquetes que le permiten al computador funcionar como un conjunto de herramientas e intérpretes de comandos.
• Subdominio: es un subgrupo o subclasificación del nombre de dominio, el cual es definido con fines administrativos u organizativos, que podría considerarse como un dominio de segundo nivel. Normalmente es una serie de caracteres o palabra
que se escriben antes del dominio. En Internet se podría decir que el subdominio se utiliza para referirse a una dirección web, que trabaja como un anexo (o sitio relacionado) de un dominio principal.
• SOA (Start of Authority / Inicio de la Autoridad): Este registro designa el inicio o autoridad de la zona, contiene la información básica de la zona como: nombre del servidor de nombres principal, número de serial, intervalo de refrescamiento, intervalo de reintento, tiempo de expiración y el tiempo mínimo de vida (TTL).
• SOAP (Simple Object Access Protocol): es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
• SOAPHeader (Cabeceras SOAP): es una clase especial de bajo nivel para pasar o devolver cabeceras SOAP. Es simplemente un contenedor de datos y no tiene métodos especiales aparte de su constructor.
• TCP/IP (Transfer Control Protocol / Internet Protocol): conjunto de protocolos definidos por catedráticos en el proyecto ARPANet del Departamento de Defensa de Estados Unidos, para la red universitaria Internet en los años setenta. Esta familia de protocolos es un estándar para el intercambio de comunicaciones entre computadores.
• TLD (Top Level Domain): son los nombres en lo alto de la jerarquía de los DNS. Aparecen en los nombres de dominio, como "net" en "www.example.net". Los administradores del "dominio de la raíz" o "zona de la raíz" ("root domain" or "root zone") controlan lo que los TLDs sean reconocidos por los DNS. Los TLDs comúnmente usados incluyen a .com, .net, .edu, .jp, .de, etc.
• TSIG (Transaction SIGnature): usa llaves o claves secretas compartidas y germinador de una sola vía para proveer un significado seguro criptograficado para identificar cada punto final de una conexión así como el estar permitido a hacer o responder a la actualización DNS.
• TTL (Time To Live): es el tiempo que un paquete permanece activo en una red. Hay un numero TTL en cada header de paquete IP, y a medida que un paquete pasa por cada router o enrutador, lo reduce por 1 este número. Si el paquete llega a 0, los routers o enrutadores no seguirán reenviando el paquete.
• UDP (User Datagram Protocol): es un protocolo del nivel de transporte basado en el intercambio de datagramas. Permite el envío de datagramas a través de la red, sin que se haya establecido previamente una conexión; ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. • UNIX: es un sistema operativo portable, multitarea y multiusuario; desarrollado,
en principio, en 1969 por un grupo de empleados de los laboratorios Bell de AT&T. • XML (Extensible Markup Language / Lenguaje de Marcas Ampliable): es un
metalenguaje extensible de etiquetas desarrollado por el Word Wide Web Consortium (W3C). Consiste en una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto, XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades.
• Zonas DNS: permiten al servidor maestro o primario cargar la información de una zona.
REFERENCIAS
•Fábrega, Pedro Pablo (consultado mayo 2009), “DHCP Guía básica”. Disponible en: http://dns.bdat.net/dhcp/
•Hernández, Andrés (consultado abril 2009), “DIG”. Disponible en:
h
ttp://www.scribd.com/doc/7549379/IMSI-U02-Anexo-Dig
•Internet Systems Consortium (consultado abril 2009), “ISC BIND”. Disponible en: https://www.isc.org/software/bindWikipedia (modificada por última vez el 09:16, 4 mar 2009), “Sender Policy Framework”. Disponible en: http://es.wikipedia.org/wiki/SPF
•Internet Systems Consortium (consultado abril 2009), “Internet Systems Consortium”. Disponible en: http://www.isc.org
•Monkey (consultado abril 2009), “tail - display the last part of a file”. Disponible en: http://www.monkey.org/cgi-bin/man2html?tail
•Resolv.conf(5) - Linux man page (consultado mayo 2009), “resolv.conf - resolver configuration file”. Disponible en: http://linux.die.net/man/5/resolv.conf
•Rekhter, Y., Moskowitz B.(Febrero 1996), “Asignación de direcciones para Internet privadas”, Network Working Group. Disponible en: http://www.rfc-es.org/rfc/rfc1918-es.txt •Swoolley (consultado abril 2009), “host(1,5) - DNS lookup utility”. Disponible en: http://swoolley.org/man.cgi/host
