Introducción a los registros DNS

Actualizado el 6 de octubre, 2016. Por BlueHosting.

El sistema de nombres de dominio DNS (Domain Name System, por sus siglas en inglés) es la libreta de direcciones del Internet. DNS dirige el tráfico web a su BlueHosting y envía correos electrónicos a su bandeja de entrada mapeando nombres de dominio fáciles de recordar como ejemplo.com a direcciones IP como 123.45.67.8 o 0123:4567:89ab:cdef:0123:4567:89ab:cdef. Esta guía presenta los conceptos básicos de DNS y los distintos tipos de registros DNS.

Cómo funciona DNS

Antes de añadir algún registro DNS, debería aprender algunos conceptos básicos sobre este sistema. Comenzaremos por el análisis de un nombre de dominio y luego aprenderá sobre los mecanismos de resolución DNS, incluyendo los servidores de nombres, archivos de zona y registros DNS individuales.

Nombres de dominio

Los nombres de dominio se pueden comprender mejor si se leen de derecha a izquierda. La clasificación más extensa de un dominio está a la derecha y se vuelve más específica a medida que se mueve a la izquierda. En los ejemplos a continuación el dominio de nivel superior o TLD (Top-Level Domain) es .com:

ejemplo.com
mail.hola.ejemplo.com

Cada término a la izquierda del TLD está separado por un punto y se considera un subdominio más específico, aunque por convención, a los subdominios de primer nivel más sus TLDs se les denomina simplemente "dominios" (como en ejemplo.com). Moviéndose a la izquierda, hola y mail son subdominios de segundo y de tercer nivel, respectivamente. Generalmente, los subdominios se utilizan simplemente para identificar servicios o máquinas específicas, pero esto queda a criterio del propietario del dominio.

Servidores de nombres

Seleccionar y especificar los servidores de nombres es una parte esencial de la propiedad de un dominio. Si no lo hace, la Internet no sabrá dónde encontrar su información de DNS y su dominio no podrá ser resuelto. Los servidores de nombres alojan la información DNS de un dominio en un archivo de texto llamado "archivo de zona". También se conocen como Autoridad de la zona o SOA (start of authority, por sus siglas en inglés). Puede alojar su información DNS o sus servidores de nombres en una de las siguientes ubicaciones:

BlueHosting (recomendado)
Su registrador
Su propio servidor DNS
Alojamiento DNS de un tercero

Usar los servidores de nombres de BlueHosting es la forma más sencilla, ya que BlueHosting provee archivo de zona predeterminado con todas las direcciones IP para su sitio web y correo electrónico. Además la configuración es bastante sencilla. Sin embargo, si está buscando las opciones ofrecidas por su registrador y hosts DNS de terceros o si quiere alojar su propio DNS, entonces podrá tener un control total de todo el proceso.

Especificará los servidores de nombres en el sitio web de su registrador. Ellos se encargarán de publicar la información a los servidores de nombres de alto nivel. Debe especificar al menos dos servidores de nombres. De esa manera, si alguno se cae, el siguiente puede continuar sirviendo su información de DNS.

Registros DNS y archivos de zona

El siguiente aspecto de la administración DNS es especificar los registros DNS, los cuales en realidad hacen coincidir los nombres de dominio con direcciones IP. Los registros DNS son entonces agrupados en un archivo de zona, el cual es el que permite que Internet busque la dirección IP correspondiente a cierto dominio. Si decide usar los servidores de nombres de BlueHosting, nuestro gestor DNS creará un archivo de zona predeterminado con los campos adecuados.

Cada archivo de zona de dominio contiene la dirección de correo electrónico del administrador, los servidores de nombres y los registros DNS. Está claro que no está limitado a estas entradas predeterminadas. Puede crear una variedad de registros DNS para los subdominios que desee. Este tema, sin embargo, no se aborda en esta guía.

Resolución DNS

Entonces, ¿cómo funciona realmente el DNS? Primero, el nombre de dominio necesita ser traducido en la dirección IP de su BlueHosting. DNS hace coincidir un nombre de dominio legible para humanos —como ejemplo.com— con una dirección IP legible para computadores —como 123.45.67.8. Esto ocurre en un archivo de texto especial llamado archivo de zona, el cual tiene una lista de los dominios y sus direcciones IP correspondientes (y algunas cosas adicionales). Un archivo de zona es como una agenda que tiene una dirección correspondiente a cada nombre.

El proceso de búsqueda DNS funciona así:

Un usuario ingresa un nombre de dominio como ejemplo.com en su barra de direcciones.
Su computador se conecta al Internet a través de un proveedor de servicios de Internet (ISP).
El traductor DNS del ISP consulta al servidor de nombres raíz en busca del nombre del servidor TLD adecuado. En otras palabras, le pregunta al servidor de nombres raíz: "¿dónde puedo encontrar un servidor de nombres para el dominio .com?"
El servidor de nombres raíz responde con la dirección IP del servidor de nombres .com.
El traductor DNS del ISP visita el servidor de nombres .com, usando la dirección IP que obtuvo de la consulta anterior. Le pregunta al servidor de nombres .com: "¿dónde puedo encontrar el servidor de nombres de ejemplo.com".
El servidor de nombres .com le responde con la dirección IP correspondiente al servidor de nombres ejemplo.com.
El traductor DNS del ISP visita el servidor de nombres de su dominio y lee el archivo de zona.
El archivo de zona muestra cuál dirección IP va con el dominio.
Ahora que el ISP tiene la dirección IP de ejemplo.com, se puede conectar a su servidor.
Apache (o su servidor web) gestiona todo lo que ocurre después, asegurándose de que los archivos y carpetas sean mostrados en el navegador del visitante.

El escenario descrito arriba es lo que ocurre si el ISP no tiene información almacenada sobre el dominio solicitado. Hoy en día, los ISPs guardan en caché muchísima información DNS después de buscar por primera vez. Esto causa que las búsquedas sean más rápidas y menos forzadas para los servidores DNS. El almacenamiento en caché es muy bueno en general, pero puede ser un problema si ha hecho cambios recientes en su información de DNS, como cuando transfiere su sitio web desde otro proveedor hacia BlueHosting. En esos casos, debe prestar atención al parámetro TTL (Time to live —tiempo de vida) de su archivo de zona para que su DNS cambie lo más pronto posible.

Tipos de registros DNS

A y AAAA

Un registro A hace coincidencia de un dominio (o subdominio) con una dirección IP. En otras palabras, apunta su nombre de dominio a la dirección IP de su BlueHosting, lo que permite que el tráfico web llegue a dicho servidor. Esta es la función principal del DNS. Un registro A típico luce así:

ejemplo.com     A       123.45.67.8

También puede usar registros A para los subdominios que quiera dirigir a su servidor:

hola.ejemplo.com       A       12.34.56.78

Nota:
Puede apuntar subdominios diferentes a distintas direcciones IP.

Si quiere apuntar cada subdominio de ejemplo.com a la dirección IP de su BlueHosting, puede usar un asterisco (*) como subdominio:

*.ejemplo.com   A       12.34.56.78

Un registro AAAA es lo mismo que un registro A, pero para direcciones IPv6. Un registro AAAA típico luce como el siguiente:

ejemplo.com     AAAA        0123:4567:89ab:cdef:0123:4567:89ab:cdef

AXFR

Un registro AXFR es un tipo de registro DNS usado para replicación DNS, aunque hay algunas otras formas más modernas de hacer replicación DNS. Los registros AXFR no se utilizan en archivos de zona comunes. Más bien, se utilizan en un servidor DNS esclavo para replicar el archivo de zona del servidor DNS maestro.

CNAME

Un registro CNAME o Canonical Name (nombre canónico) por sus siglas en inglés, hace coincidir un dominio (o subdominio) con otro dominio distinto. Con un registro CNAME, los buscadores DNS usan la resolución del dominio de destino como la resolución del alias. Por ejemplo, observe la siguiente configuración:

alias.com       CNAME   ejemplo.com.
ejemplo.com     A       123.45.67.8

Con esta configuración, cuando se solicita alias.com, la búsqueda DNS inicial encontrará la entrada CNAME con el destino de ejemplo.com. Se comenzará entonces una búsqueda para ejemplo.om, el cual encontrará la dirección 123.45.67.8. Finalmente, los visitantes de alias.com serán redirigidos a la IP 123.45.67.8.

Los registros CNAME existen con el fin de que los dominios puedan tener alias. No debe usar un registro CNAME para un dominio que recibe correos electrónicos, porque algunos servidores de correo administran el correo de forma errónea para los dominios con registros CNAME. De igual modo, los registros MX no pueden hacer referencia a nombres de host definidos por CNAME. Además, el dominio de destino para un registro CNAME debe tener una resolución normal de registro A. No se recomienda anidar o hacer bucles de registros CNAME.

Nota:
En algunos casos, un registro CNAME puede ser una forma efectiva de redirigir tráfico de un dominio a otro mientras mantiene el mismo URL. Sin embargo, tenga en mente que un registro CNAME no funciona de la misma forma que una redirección URL. Un registro CNAME dirige el tráfico web de un dominio particular a la dirección IP del dominio de destino. Una vez que el visitante llega a esa IP, la configuración del servidor web determinará cómo se maneja el dominio. Si el dominio no está configurado en el servidor, el servidor simplemente mostrará la página web predeterminada (si existe). Esta puede o no ser la página web del dominio de destino en el registro CNAME, dependiendo de cómo esté configurado el servidor.

DKIM

Un registro DKIM (Domain Keys Identified Mail) muestra la clave pública para autenticar mensajes que han sido firmados con el protocolo DKIM. Esta práctica aumenta la capacidad de comprobar la autenticidad de los correos electrónicos. Un registro DKIM típico será similar al siguiente:

selector1._domainkey.ejemplo.com        TXT     k=rsa;p=J8eTBu224i086iK

Los registros DKIM se implementan como registros de texto. El registro debe ser creado para un subdominio, el cual tiene un selector único para esa clave, luego un punto (.) y luego _domainkey.example.com. El tipo es TXT, y el valor incluye el tipo de clave, seguido por dicha clave.

MX

Un registro MX o Mail Exchange establece el destino de entrega de correos electrónicos de un dominio (o subdominio). Un registro MX típico será similar al siguiente:

ejemplo.com         MX      10  mail.ejemplo.com.
mail.ejemplo.com    A           12.34.56.78

Los registros arriba dirigen el correo electrónico para ejemplo.com al servidor mail.ejemplo.com. El dominio de destino (mail.ejemplo.com) necesita tener su propio registro A que resuelva a su BlueHosting. En condiciones ideales, un registro MX debe apuntar a un dominio que también es el hostname para su servidor.

Sus registros MX no tienen que apuntar a su BlueHosting obligatoriamente. Si está usando un servicio de correo de un tercero, como Google Apps, debe usar los registros MX que ellos proporcionen.

La prioridad (priority) es otro componente de los registros MX. Este el número escrito entre el tipo de registro y el servidor de destino (en el ejemplo arriba asignamos el valor 10). La prioridad le permite designar un servidor (o servidores) de reserva para el correo electrónico de un dominio particular. Los números más bajos significan que la prioridad es más alta. Aquí hay un ejemplo de un dominio que tiene dos servidores de correo de reserva:

ejemplo.com         MX      10  mail_1.ejemplo.com
ejemplo.com         MX      20  mail_2.ejemplo.com
ejemplo.com         MX      30  mail_3.ejemplo.com

En este ejemplo, si mail_1.ejemplo.com está caído, entonces el correo electrónico será entregado a mail_2.ejemplo.com. Si este último también está caído, entonces el correo electrónico a mail_3.ejemplo.com.

NS

Los registros NS (NameServer) establecen los servidores de nombres de un dominio (o subdominio). Los registros del servidor primario de su dominio se establecen tanto en su registrador como en su archivo de zona. Los registros NS típicos se ven así (se necesitan al menos dos registros NS):

ejemplo.com     NS      ns1.BlueHosting.com.
ejemplo.com     NS      ns2.BlueHosting.com.
ejemplo.com     NS      ns3.BlueHosting.com.
ejemplo.com     NS      ns4.BlueHosting.com.
ejemplo.com     NS      ns5.BlueHosting.com.

Los servidores de nombres que designe en su registrador entonces llevarán el archivo de zona de su dominio.

También puede configurar distintos servidores de nombres para cualquiera de sus subdominios. Los registros NS de subdominios son configurados en el archivo de zona del dominio primario. Por ejemplo, si está usando los servidores de nombre de BlueHosting, puede configurar registros NS separados en el archivo de zona para un subdominio como mail.ejemplo.com, por ejemplo:

mail.ejemplo.com    NS      ns1.nameserver.com
mail.ejemplo.com    NS      ns2.nameserver.com

Los servidores de nombres primarios son configurados en su registrador, los servidores de nombres de subdominios secundarios son configurados en el archivo de zona del dominio. El orden de los registros NS no importa; las peticiones DNS se envían aleatoriamente a los distintos servidores, y si uno no responde, se hará la solicitud a otro.

PTR

Un registro PTR o Pointer (registro apuntador) hace coincidir una dirección IP con un dominio (o subdominio), permitiendo que funcionen las solicitudes de Reverse DNS o DNS Inverso. Lleva a cabo un servicio opuesto al que realiza un registro A, permitiendo que se busque el dominio asociado con una dirección IP particular.

Los registros PTR se establecen generalmente con su proveedor de alojamiento. No son parte del archivo de zona de su dominio. Esto significa que siempre debe configurar el servicio de Reverse DNS dentro del panel de control de BlueHosting, aun cuando sus servidores de nombres estén en otro lugar. De igual forma, si tiene servidores en algún otro lugar pero está usando servidores de nombres de BlueHosting, aún tendrá que configurar los registros PTR con su proveedor de hosting.

Como requisito previo para añadir un registro PTR, necesita crear un registro A o AAA válido que apunte el dominio deseado a esa IP. Si usted quiere un registro PTR IPv4, apunte el dominio (o subdominio) a su dirección IPv4 de BlueHosting. Si requiere un registro PTR IPv6, apunte el dominio a su dirección IPv6 de BlueHosting. Más allá de esto, los registros PTR IPv4 e IPv6 funcionan de la misma forma.

Nota:
Es posible tener distintas IP (incluyendo direcciones IPv4 e IPv6) que tengan el mismo dominio configurado para el DNS inverso. Para hacer esto, tendrá que configurar varios registros A o AAAA para ese dominio que apunte a varias IPs.

SOA

Un registro SOA (Start of Authority —o autoridad de la zona) etiqueta un archivo de zona con el nombre del host donde se creó originalmente. Luego, coloca la dirección de correo electrónico de contacto de la persona responsable del dominio en una lista. Un registro SOA típico se muestra a continuación:

@   IN  SOA ns1.linode.com. admin.ejemplo.com. 2013062147 14400 14400 1209600 86400

Nota:
La dirección de correo electrónico administrativa está escrita con un punto (.) en lugar del símbolo arroba (@).

A continuación una lista de lo que significa cada campo en el archivo:

Nombre serial (Serial number): el nombre de revisión del archivo de zona de este dominio. Cambia cuando el archivo se actualiza.
Tiempo de actualización (Refresh time): la cantidad de tiempo en segundos en el que un servidor DNS secundario mantendrá el archivo de zona antes de que compruebe si hay cambios.
Tiempo de reintento (Retry time): la cantidad de tiempo en que un servidor DNS secundario esperará antes de volver a intentar la transferencia fallida del archivo de zona.
Tiempo de expiración (Expire time): la cantidad de tiempo en que un servidor DNS secundario esperará hasta expirar su copia del archivo de zona si no puede actualizarse por su cuenta.
TTL mínimo (Minimal TTL): el tiempo mínimo en que otros servidores deben mantener los datos almacenados en caché para este archivo de zona.

El servidor de nombres mencionado en el registro SOA es considerado el maestro primario para propósitos de DNS dinámico y es el servidor donde se hacen los cambios de archivo de zona antes de ser propagados a todos los otros servidores de nombre.

SPF

Un registro SPF (Sender Policy Framework —Marco de directivas de remitente) enumera los servidores de correo designados para un dominio o subdominio. Ayuda a establecer la legitimidad de su servidor de correo electrónico y reduce la probabilidad de spoofing, el cual ocurre cuando alguien crea una cabecera falsa de correo para hacer parecer que viene desde su dominio, aunque el mensaje no haya sido originado en su BlueHosting. Los creadores de spam a veces intentan hacer esto para evitar los filtros de spam. Un registro SPF para su dominio le dice a otros que reciben su correo electrónico cuál(es) servidor(es) son fuentes válidas de correo electrónico, de modo que puedan rechazar correos usurpados de su dominio que hayan sido generados por servidores no autorizados. Un registro SPF muy básico tiene la siguiente forma:

ejemplo.com   TXT     "v=spf1 a ~all"

Debe enumerar en su registro SPF todos los servidores de correo electrónico confiables para luego excluir el resto. Su registro SPD tendrá un dominio o subdominio, un tipo (que será TXT o SPF si su servidor de nombres lo soporta), y un fragmente de texto que comienza con "v=spf1" y contiene los ajustes del registro SPF.

Si su BlueHosting es el único servidor de correo electrónico que usted utiliza, debe poder usar el registro de ejemplo expuesto arriba. Con este registro SPF, el servidor receptor verificará las direcciones IP del servidor remitente y las direcciones IP de ejemplo.com. Si las IPs coinciden, la comprobación se aprueba. Si no coinciden, la comprobación pasará al estado "soft tail", en otras palabras, el mensaje será marcado pero no será descartado automáticamente por fallar la comprobación SPF.

Nota:
Asegúrese de que los registros SPF no sean demasiado estrictos. Si excluye accidentalmente algún servidor de correo legítimo, sus mensajes podrían ser marcados como spam. Es muy recomendable visitar openspf.org para aprender cómo funcionan los registros SPF y para más información sobre cómo estructurar uno que cumpla con sus requisitos.

SRV

Un registro SRV (Service Record —registro de servicio) hace coincidir un servicio específico que se ejecuta en su dominio con un dominio de destino. Esto permite redirigir tráfico de servicios específicos, como mensajería instantánea, a otro servidor. Un registro SRV típico luce así:

_service._protocol.ejemplo.com  SRV     10      0       5060    service.ejemplo.com

A continuación un desglose de los parámetros que incluye:

Servicio (Service): el nombre del servicio, el cual debe estar precedido por un guion bajo (_) y seguido por un punto (.). El servicio podría ser _xmpp., por ejemplo.
Protocolo (Protocol): el nombre del protocolo debe estar precedido por un guion bajo (_) y seguido por un punto (.). El protocolo podría ser algo como _tcp..
Dominio (Domain): el nombre del dominio que recibirá el tráfico original para este servicio.
Prioridad (Priority): el primer número (10 en el ejemplo arriba) le permite establecer la prioridad del servidor de destino. Puede establecer destinos con prioridades diferentes, lo cual le permitiría tener uno o más servidores de reserva para ese servicio. Los números más bajos suponen prioridades más altas.
Peso (Weight): si dos registros tienen la misma prioridad, entonces se usará el peso en su lugar.
Puerto (Port): el puerto TCP o UDP en el cual se ejecuta el servicio.
Destino (Target): el dominio o subdominio de destino. Este dominio debe tener un registro A o AAAA que traduzca a una dirección IP.

TXT

Un registro TXT o registro de texto, provee información sobre el dominio en cuestión a otros recursos en el Internet. Es un tipo de registro DNS flexible que puede servir para varios propósitos dependiendo de su contenido. Un uso común de los registros TXT es la creación de un registro SPF en servidores de nombres que no soportan SPF de forma nativa. Otro uso es crear un registro DKIM para el inicio de sesión en correo electrónico.

Recursos adicionales

La información provista en este tutorial le da una base teórica bastante completa sobre DNS. Puede consultar los siguientes recursos en busca de información adicional con respecto a este tema. Aunque este material es provisto esperando que sea útil, no podemos comprobar su actualidad o precisión.

Consulte el siguiente libro de código abierto, el cual contiene información muy completa sobre DNS Manual sobre DNS - Zytrax.