Los Registros de Recursos definen los tipos de datos en el Domain Name System (DNS). Los Registros de Recursos identificados por el RFC 1035 se almacenan en formato binario internamente para su uso por parte del software DNS. Pero los registros de recursos se envían a través de una red en formato de texto mientras que realizan transferencias de zona. Este documento explica algunos de los tipos más importantes de Registros de Recursos.
Nota: Existen otros tipos de registros para los que ya no se brinda soporte de manera activa. Algunos son el de destino de correo (MD), el de reenviador de correo (MF), el de grupo de correo (MG), el de información de casilla de correo o de lista de correo (MINFO), elde cambio de nombre de correo (MR) y NULL. Puede ver una lista completa de los tipos de registros de DNS en los parámetros de DNS de IANA.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
En el nivel superior de un dominio, la base de datos de nombres debe contener un registro de inicio de autoridad (SOA, Start of Authority). Este registro SOA identifica cuál es la mejor fuente de información para los datos dentro del dominio. El registro SOA contiene la versión actual de la base de datos de DNS y otros parámetros que definen el comportamiento de un servidor de DNS en particular.
Debe haber exactamente un registro SOA para cada dominio del servidor de nombres (cada subdominio). Esto se aplica a los subdominios de IN-ADDR.ARPA (dominios inversos). Cuando una región de espacio de nombres tiene un SOA independiente, se la denomina zona.
El formato para este registro se puede ver en este resultado. Los valores presentados para los intervalos de tiempo en este SOA son los recomendados por RFC 1537.
DOMAIN.NAME. IN SOA Hostname.Domain.Name. Mailbox.Domain.Name. ( 1 ; serial number 86400 ; refresh in seconds (24 hours) 7200 ; retry in seconds (2 hours) 2592000 ; expire in seconds (30 days) 345600) ; TTL in seconds (4 days) The SOA record for the fictional foo.edu might look something like this: FOO.EDU. IN SOA FOO.EDU. Joe_Smith.Foo.EDU. ( 910612 ; serial number 28800 ; refresh in 8 hours 7200 ; retry in 2 hours 604800 ; expire in 7 days 86400 ) ; TTL is 1 day
En esta lista se brinda una explicación de los campos de datos del registro SOA ficticio.
DOMAIN.NAME.: Nombre del dominio al que pertenece el registro SOA. Observe el punto final (.). Esto significa que no se debe agregar ningún sufijo al nombre.
IN: Clase del registro DNS. IN significa "Internet".
SOA: Tipo de registro de DNS, el inicio de autoridad en este ejemplo.
Hostname.Domain.Name.: El "campo de origen" debe contener el nombre de host del servidor de nombres principal para esta zona, el host donde residen los datos autorizados.
Mailbox.Domain.Name.: La casilla de correo de la persona responsable de (el servicio de nombres de) este dominio. Para convertir este campo en una dirección de correo electrónico utilizable, reemplace el primer punto (.) con una @ (arroba). En este ejemplo, si hay problemas con foo.edu, envíe un mensaje a Joe_Smith@foo.edu.
Serial number: Número de serie de la versión actual de la base de datos de DNS para este dominio. El número de serie es el medio por el cual otros servidores de nombres se dan cuenta de que usted ha actualizado su base de datos. Este número de serie comienza siendo 1 y debe ser un número entero que va subiendo de manera pareja. No incluya un punto decimal en el número de serie, ya que esto puede producir resultados confusos y desagradables. Algunos administradores de DNS utilizan la fecha de la última modificación como número de serie, con el formato AAMMDDHHMM, pero otros simplemente incrementan levemente el número de serie cada vez que se actualiza la base de datos. El paréntesis que se abre antes del número de serie y se cierra después del número mínimo de tiempo de vida (TTL, Time to Live) permite que el SOA abarque varias líneas.
Cuando un servidor de nombres secundario del dominio foo.edu se comunica con el servidor de nombres principal para verificar si se ha producido un cambio en la base de datos de DNS del principal, y si el secundario debe realizar una transferencia de zona, compara su propio número de serie con el del servidor de nombres principal.
Si el número de serie del servidor de nombres secundario es mayor que el del primario, no se produce una transferencia de zona. Si el número de serie del servidor de nombres principal es mayor, el servidor de nombres secundario realiza una transferencia de zona y actualiza su propia base de datos de DNS.
Los otros campos numéricos se denominan campos de TTL. Estos controlan la frecuencia con que los servidores de nombres se sondean entre sí para obtener actualizaciones de información (por ejemplo, cuánto tiempo se almacenan en caché los datos, etc.).
Refresh: Le indica al servidor de nombres secundario con qué frecuencia sondear el servidor de nombres principal y con qué frecuencia verificar si hay un cambio de número de serie. Este intervalo afecta el tiempo que tardan en propagarse los cambios de DNS realizados en el servidor de nombres principal.
Retry: El intervalo en segundos para que el servidor de nombres secundario intente volver a conectarse con el servidor de nombres principal, en caso de que no se haya conectado en el intervalo de Refresh.
Expire: Cantidad de segundos tras la cual un servidor de nombres secundario debe "hacer caducar" los datos del servidor de nombres principal, si no puede volver a conectarse al servidor de nombres principal.
TTL: Valor predeterminado que se aplica a todos los registros de la base de datos de DNS de un servidor de nombres. Cada registro de recursos de DNS puede tener configurado un valor de TTL. El TTL predeterminado del registro SOA solo se utiliza si un registro de recursos en particular no tiene configurado un valor explícito. Este valor es suministrado por servidores de nombres autorizados (servidores de nombres principales y secundarios de una zona en particular) cuando responden consultas de DNS.
Cada subdominio que tenga un servidor de nombres independiente debe tener al menos un registro de servicio de nombres (NS, Name Service) correspondiente. Los servidores de nombres utilizan registros NS para encontrarse entre sí.
Los registros NS tienen este formato:
DOMAIN.NAME. IN NS Hostname.Domain.Name.
El valor de un registro NS para un dominio es el nombre del servidor de nombres de ese dominio. Usted debe indicar un registro NS para cada servidor de nombres principal o secundario del dominio.
El registro de dirección (registro A, por Address) genera una dirección IPv4 que corresponde a un nombre de host. Puede haber varias direcciones IP que correspondan a un mismo nombre de host; también puede haber varios nombres de host que tengan asignada la misma dirección IP.
Los registros "A" tienen este formato:
Host.domain.name. IN A xx.xx.xx.xx(IPv4 address)
Debe haber un registro "A" válido en el DNS de Host.domain.name para que un comando, como telnet host.domain.name , funcione (o debe haber un CNAME que apunte a un nombre de host con un registro "A" válido).
Nota: RFC 1886 se ocupa de las extensiones de DNS para admitir direcciones IPv6.
El registro de información de host (HINFO, Host Info) se puede configurar para que brinde información sobre el tipo de hardware y el sistema operativo (SO) de cada host. Su presencia es opcional, pero se trata de información que puede ser útil.
Solo puede haber un registro "HINFO" por nombre de host.
Los registros "HINFO" tienen este formato:
Host.DOMAIN.NAME. IN HINFO "CPU type" "Operating System"
Nota: Los campos CPU type (Tipo de CPU) y Operating System (Sistema operativo) son obligatorios. Si desea dejar uno de estos campos en blanco, configúrelo como " " (un espacio en blanco entre comillas). No puede utilizar solo un par de comillas [""].
Nota: Los nombres de máquinas oficiales que necesita para HINFO están disponibles en RFC 1700. En RFC 1700 se brinda información útil, como valores de /etc/services, direcciones de hardware de fabricantes de Ethernet y valores predeterminados de HINFO.
El registro de texto (TXT) le permite asociar cualquier texto arbitrario con un nombre de host. Algunas implementaciones deficientes del comando bind no admiten el registro "TXT". Sin embargo, algunas implementaciones deficientes del comando bind sí admiten un tipo de registro falso denominado "UINFO" que hace lo mismo. Cisco recomienda utilizar solo el tipo de registro "TXT".
Usted puede tener varios registros "TXT" para un mismo nombre de host.
Los registros "TXT" tienen este formato:
Host.DOMAIN.NAME. IN TXT "system manager: melvin@host.domain.name" IN TXT "melasu"
Una zona puede tener uno o más registros de intercambio de correo (MX, Mail Exchange). Estos registros apuntan a hosts que aceptan mensajes de correo en nombre del host. Un host puede ser su propio "MX". Los registros MX no necesitan apuntar a un host de la misma zona.
Los registros "MX" tienen este formato:
Host.domain.name. IN MX nn Otherhost.domain.name. IN MX nn Otherhost2.domain.name.
Los números de preferencia de "MX" nn (valor de 0 a 65535) indican el orden en que los remitentes de correo seleccionan registros "MX" al intentar enviar correo al host. Cuanto menor es el número de "MX", mayor es la prioridad del host.
El registro de nombre canónico (CNAME, Canonical Name) se utiliza para definir un alias para el nombre de host.
Los registros "CNAME" tienen este formato:
alias.domain.name. IN CNAME otherhost.domain.name.
Aquí se define alias.domain.name como alias para el host cuyo nombre canónico (estándar) es otherhost.domain.name.
Nota: Un nombre de host que existe como CNAME no puede tener aplicado ningún otro registro de DNS. Por ejemplo, si su dominio se llama philosophy.arizona.edu y tiene un servidor de nombres independiente (para que tenga sus propios registros SOA y NS), no puede asignar un registro CNAME a philosophy.arizona.edu. Para enviar un correo electrónico a anyuser@philosophy.arizona.edu, debe utilizar un registro MX o A.
Los registros de puntero son lo opuesto a los registros A y se utilizan en archivos de zona de asignación inversa para asignar una dirección IP a un nombre de host. A diferencia de los otros registros SOA, los registros de puntero (PTR) se utilizan solo en dominios inversos (IN-ADDR.ARPA). Debe haber exactamente un registro PTR para cada dirección de Internet. Por ejemplo, si el host gadzooks.poetry.arizona.edu tiene la dirección IP 128.196.47.55, debe haber un registro PTR con este formato:
55.47.196.128.IN-ADDR.ARPA. IN PTR gadzooks.poetry.arizona.edu.
Los dominios inversos contienen principalmente registros PTR (más registros SOA y NS en la parte superior).
Las utilidades r de Berkeley utilizan el valor del registro PTR para la autenticación de nombres de host. Aunque DNS especifica que en los nombres de host no se distingue entre mayúsculas y minúsculas, tenga en cuenta que algunos sistemas operativos sí detectan la diferencia.