Jorge De Nova Segundo

Formato general.

SOA El registro SOA (Start of Authority) es el segundo registro que nos encontramos en un archivo de zona. Debe haber uno (y solo uno) por cada archivo de zona directo o inverso que creemos. Su sintaxis es: Donde: zona es o bien el nombre de la zona (terminado en punto) o bien la nombreDNSprimario indica el FQDN del servidor donde está almacenado el archivo de zona (terminado en un punto). Administrador es la dirección de de la persona responsable de este dominio (la arroba se remplaza con un punto y la dirección entera también termina con un punto).

numeroSerie indica el número de versión del archivo de zona. Sirve de referencia a los servidores DNS secundarios para saber cuándo deben hacer una transferencia de zona. Si el número de serie del servidor secundario es menor que el número de serie del primario significa que este ha cambiado su información. Este número debe ser incrementado de forma manual por el administrador de red cada vez que realiza un cambio en el archivo de zona. Una costumbre es la de escribir los número de serie como AAAAMMDDNN, es decir 4 cifras para el año, 2 para el mes, 2 para el día y una o dos para el numero de revisión dentro de ese día (01, 02, etc.). actualización es el intervalo, en segundos, tras el cual los servidores secundarios deben comprobar el registro SOA del servidor primario, con el fin de verificar si la información del dominio ha cambiado. El valor típico es de una hora (3600).

TTLminimo antiguamente (en versiones 8.3 de BIND y anteriores) establecía el tiempo de validez en segundos para permanecer en cachés de otros servidores o de resolvers. En la actualidad esto se consigue con la directiva $TTL, por lo que el valor indicado en este campo se ignora. reintento especifica el tiempo que el servidor secundario espera antes de volver a intentar una transferencia de zona que haya fallado. caducidad es el tiempo en segundos tras el cual un servidor DNS secundario que no haya podido realizar transferencias de zona en todo ese tiempo descartará los datos que posee. El valor típico es de 42 días, o sea

El registro de recursos NS (name Server) indica los servidores de nombres autorizados para la zona. Cada zona debe contener registros indicando tanto los servidores principales como los secundarios. Por tanto, cada zona debe contener, como mínimo, un registro NS. Por otra parte, estos registros también se utilizan para indicar quiénes son los servidores de nombres con autoridad en subdominios delegados, por lo que la zona contendrá al menos un registro NS por cada subdominio que haya delegado. Ejemplos de registros NS serían los siguientes: admin.com. IN NS pc01.admin.com. valencia.admin.com. IN NS pc0102.valencia.admin.com. El registro de recursos NS

Registros de recursos de host (A) Los registros de recursos de host (A) se utilizan en una zona para asociar nombres de dominio DNS de equipos (o hosts) a sus direcciones IP y se pueden agregar a una zona de varias formas: El registro de recursos de host (A) no es requerido para todos los equipos, pero es necesario para los equipos que comparten recursos en una red. Cualquier equipo que comparta recursos y tenga que identificarse por su nombre de dominio DNS, tiene que utilizar registros de recursos A para facilitar la resolución de nombres DNS a la dirección IP del equipo. La mayor parte de los RR A requeridos en una zona puede incluir otros servidores o estaciones de trabajo que comparten recursos, otros servidores DNS, servidores de correo electrónico y servidores Web. Estos registros de recursos contienen la mayoría de los registros de recursos de la base de datos de una zona.

AAAA Descripción: Registro de recursos de direcciones de host IPv6 (AAAA). Asigna un nombre de dominio DNS a una dirección de 128 bits del Protocolo Internet (IP) versión 6. Ejemplo: host1ipv6.ejemplo.microsoft.com. IN AAAA 4321:0:1:2:3:4:567:89ab A6 Se utilizan para mapear nombres a direcciones IPv6 Son el equivalente a los Registros “A” de un archivo de zona IPv4 y a los Registros “AAAA” en IPv6. Facilitan la escritura Agilizan los procesos de renumeración y multi-proveedor Realizan consultas en forma “iterativa” Formato de un registro A6 a.b.c A6 Ejemplo: pc1.retina.ar A6 64 ::4444:00e:7db0:7295 sla.retina.ar sla.retina.ar A6 0 3ffe:b00:c18:1234::

Registros de recursos de alias (CNAME) Los registros de recursos de alias (CNAME) también se llaman, en ocasiones, nombres canónicos. Estos registros permiten utilizar más de un nombre para señalar a un único host, lo que facilita tareas como alojar un servidor FTP y un servidor Web en el mismo equipo. Por ejemplo, los nombres de servidor conocidos (ftp, www) se registran utilizando los RR CNAME que asignan el nombre host de DNS, como "servidor-1", al equipo servidor que aloja estos servicios. Se recomienda utilizar los RR CNAME en los casos siguientes: Cuando se necesita cambiar el nombre a un host especificado en un RR A de la misma zona. Cuando se necesita resolver un nombre genérico de un servidor conocido como www en un grupo de equipos individuales (cada uno con RR A individuales) que proporcionan el mismo servicio. Por ejemplo, un grupo de servidores Web redundantes.

Cuando cambie el nombre de un equipo con un RR A existente en la zona, podrá utilizar un RR CNAME de forma temporal con el objeto de permitir un período de gracia para que los usuarios y los programas dejen de especificar el nombre de equipo antiguo y usen el nuevo. Para ello, tiene que hacer lo siguiente: Para el nombre de dominio DNS nuevo del equipo, se agrega un RR A nuevo a la zona. Para el nombre de dominio DNS antiguo, se agrega un RR CNAME que señala al RR A nuevo. El RR A original del nombre de dominio DNS antiguo (y su RR PTR asociado, si procede) se quita de la zona. Cuando utilice un RR CNAME para asignar un alias o cambiar el nombre a un equipo, establezca un límite temporal en la frecuencia con la que utiliza el registro en la zona antes de quitarlo de DNS. Si olvida eliminar el RR CNAME y después se elimina su RR A asociado, el RR CNAME puede desperdiciar recursos del servidor al intentar resolver consultas de un nombre que ya no se utiliza en la red.

Registros de recursos del agente de intercambio de correo (MX) El RR del agente de intercambio de correo (MX) es usado por las aplicaciones de correo electrónico para ubicar el servidor de correo electrónico en función del nombre de dominio DNS utilizado en la dirección de destino para el destinatario de un mensaje de correo electrónico. Por ejemplo, se puede utilizar una consulta DNS del nombre "example.microsoft.com" para buscar un RR MX y habilitar una aplicación de correo electrónico para reenviar o intercambiar correo electrónico con un usuario con la dirección de correo electrónico "user(EN)example.microsoft.com". El RR MX muestra el nombre de dominio DNS del equipo o equipos que procesan correo en un dominio. Si hay varios RR MX, el servicio Cliente DNS intenta entrar en contacto con los servidores de correo en el orden de preferencia desde el valor más bajo (prioridad más alta) al valor más alto (prioridad más baja). A continuación se muestra la sintaxis básica que se utiliza en un RR MX. nombreDeDominioDeCorreoIN MXpreferencia hostServidorDeCorreo

Registros de recursos de ubicación de servicio (SRV) Permite localizar varios servidores que proporcionen un servicio basado en TCP/IP similar mediante una única operación de consulta DNS. Este registro permite mantener una lista de servidores con un tipo de protocolo de transporte y un puerto de servidor conocidos, ordenada por preferencia, de un nombre de dominio DNS. Por ejemplo, en el DNS de Windows Server 2003, proporciona los medios para localizar los controladores de dominio que utilizan el servicio LDAP (Protocolo ligero de acceso a directorios) a través del puerto TCP 389.

Registros de recursos de puntero (PTR) Los RR de puntero (PTR) se utilizan para compatibilizar el proceso de búsqueda inverso, basado en zonas creadas que tienen su raíz en el dominio in-addr.arpa. Estos registros se utilizan para localizar un equipo por su dirección IP y resolver esta información en el nombre de dominio DNS de ese equipo. Los RR PTR se pueden agregar a una zona de varias formas: Puede crear manualmente un RR PTR para un equipo cliente TCP/IP estático con el complemento DNS, como procedimiento independiente o como parte del procedimiento para crear un RR A. Los equipos que ejecutan Windows 2000 pueden utilizar el servicio Cliente de DHCP para registrar y actualizar dinámicamente sus RR PTR en DNS cuando ocurre un cambio en la configuración IP. Todos los demás equipos cliente habilitados para DHCP pueden hacer que el servidor DHCP registre y actualice sus RR PTR si obtienen su concesión de IP de un servidor calificado. El servicio DHCP que proporciona Windows 2000 ofrece esta capacidad.

Para que una zona especifique que uno de sus subdominios está delegado en una zona diferente, es necesario agregar un registro de delegación y, generalmente, el denominado "registro de pegado" (glue record). El registro de delegación es un registro NS en la zona principal (padre) que define el servidor de nombres autorizado para la zona delegada. El registro de pegado es un registro tipo A para el servidor de nombres autorizado para la zona delegada, y es necesario cuando el servidor de nombres autorizado para la zona delegada también es un miembro de ese dominio (delegado). Delegación y Glue Record.