Registros DNS

Cuando buscamos una web por internet, ésta se carga gracias a unas direcciones IP que localizan los dispositivos que contienen dicha página. Hoy en día, casi nos cuesta recordar el número de nuestro teléfono móvil, así que recordar esta serie de números separados por puntos no es muy práctico, así que los servidores utilizan nombres de dominios que resultan más sencillos de recordar. Para traducir estos nombres de dominios en direcciones IP, están las DNS.

¿Qué tipo de registros DNS existen y para qué sirven?

El lugar donde se configuran las entradas DNS para cada dominio son los servidores de nombres. Los diferentes tipos de entradas de registro son:

  • Registro A:
  • Registro CNAME:
  • Registro NS:
  • Registro MX:
  • Registro SPF: define qué servidores están autorizados para enviar correo electrónico con nuestro dominio.

Registro A

Este registro se utiliza para convertir nombres de host en direcciones IP.
Un registro A o de direcciones (también denominado "registro de host") vincula un dominio con la dirección IP física de un ordenador en que se alojan los servicios de ese dominio.

Registro CNAME

Se utiliza para crear nombres de host adicionales (alias), y para crear diferentes servicios bajo una misma dirección IP.
Un nombre canónico o registro CNAME enlaza un nombre de alias con otro nombre de dominio canónico o auténtico. Por ejemplo, www.example.com puede enlazar con example.com.

Registro NS

Indica los servidores de DNS autorizados para el dominio, es decir, a quién hay que preguntar para saber acerca de los registros de midominio.com.
Los registros de Servidor de nombres (NS, del inglés "Name Server") determinan los servidores que comunicarán la información del DNS de un dominio. Por lo general, dispones de registros de servidor de nombres principales y secundarios para tu dominio.

Registro MX

Se utiliza para asociar un nombre de dominio a una lista de servidores de correo para la recepción de emails. Nos interesa si queremos realizar redirecciones de nuestro correo o utilizar nuestro correo electrónico con otro proveedor.
Los registros MX (del inglés "Mail Exchange", intercambio de correo) dirigen el correo electrónico de un dominio a los servidores que alojan las cuentas de usuario del dominio.

 

Configurando adecuadamente estos registros podemos exprimir al máximo todas las funcionalidades que poseen las DNS de nuestro dominio.

Primero que nada el registro SOA, es el Registro de “Start of Authority” para un dominio. Contiene identificadores del servidor de nombres con autoridad sobre la denominación y su operador, y diversos contadores que regulan el funcionamiento general del sistema de nombres de dominio (DNS) para la denominación. Todo servidor de nombres de una denominación debe responder a una consulta por el registro SOA de esa denominación en forma autoritativa.

Además escribe los valores por defecto para el resto de parámetros de registro SOA en los archivos de zona que mantiene.

Dentro de los valores SOA se pueden configurar varios parámetros de opciones:

  • TTL. Esto es el tiempo que los servidores DNS deben guardar el registro en el caché. Plesk establece el valor por defecto de un día.
  • Actualizar. Esto es la frecuencia con la que los servidores de nombres secundarios verifican el servidor de nombres primarios para ver si se han realizado cambios en el archivo de zona de dominio. Plesk establece el valor por defecto de tres horas.
  • Reintento. Esto es el tiempo que un servidor secundario espera para recuperar una transferencia de zona fallida. Este tiempo suele ser menor al intervalo de actualización. Plesk establece el valor por defecto de una hora.
  • Expiraración. Esto es el tiempo antes que un servidor secundario deje de responder a las búsquedas una vez se haya producido un intervalo de actualización de la zona. Plesk establece el valor por defecto de una semana.
  • Mínimo. Esto es el tiempo en que un servidor secundario debe cachear una respuesta negativa. Plesk establece el valor por defecto de tres horas.
  • Número de Serie: Puede estar en varios formatos, tanto en IETF o en Unix-timestamp (menos utilizado).
  • Persona responsable: Contiene la dirección de correo electrónico de la persona responsable donde la @ es un . (punto).
  • Propietario: Es el nombre de dominio de la zona.

La sintaxis del registro SOA es la siguiente:

nombre-dominio ttl-RR IN SOA nombre-servidor-maestro correo-electrónico-administrador numero-serie t-refresco t-reintento t-expiración nx

El significado de los campos es el siguiente:

  • nombre-servidor-maestro: Especifica un servidor DNS maestro del dominio, pero este significado de maestro es solo en el contexto del DNS dinámico (DDNS), indicando cuál es el servidor que podrá ser actualizado vía transacciones DDNS. Si no se ha configurado el DDNS, y por lo tanto no se usa, podemos poner cualquier servidor autoritario para el dominio, maestro o esclavo. Este servidor puede ser interno al dominio o externo, pero siempre debe llevar un RR NS. Es normal escribirlo en formato FQDN, pero esto solo es obligatorio en el caso de que sea un servidor externo.
  • correo-electrónico-administrador: Se pone la dirección de correo electrónico (interna al dominio o externa) de la persona responsable de la zona. Se aconseja (RFC 2412) que sea una cuenta de correo exclusiva para este menester. En el ejemplo, el e-mail especificado es Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo., pero como el símbolo @ tiene un significado especial, se sustituye por un punto: hostmaster.asir.com. Es habitual escribirlo en formato FQDN, pero solo es obligatorio para direcciones de correo externas al dominio.
  • numero-serie: Valor entero de 32 bits sin signo que va desde 1 hasta 4294967295. Este número lo utilizan los servidores DNS esclavos para ver si se han producido cambios en el fichero de zona y así actualizarse. Debemos incrementar este número cada vez que se hagan modificaciones sobre el fichero de zona. Se aconseja que se utilice un número con el siguiente formato basado en la fecha de la modificación: yyyymmddnn, donde nn es un número que comienza en 00 y es la parte que se incrementará cuando se hagan varias modificaciones en el mismo día, pues el resto del número no cambia. En el ejemplo, el número de serie está indicando que es la primera modificación realizada el 8 de abril de 2016. Se debe tener extremo cuidado de no cometer errores con este número.
  • t-refresco: Indica el intervalo de tiempo tras el cual un servidor esclavo intentará actualizarse con la zona del servidor maestro. El RFC 1912 recomienda utilizar valores comprendidos entre 1200 segundos (20 minutos) y 43200 segundos (12 horas) según lo volátil que sean los RR. Si se usan los mensajes NOTIFY para la actualización, se pueden poner valores más elevados. Valor entero de 32 bits con signo.
  • t-reintento: Indica el intervalo de tiempo entre reintentos del servidor esclavo, para cuando la conexión con el servidor maestro tras el tiempo de refresco ha fallado. El valor dependerá del conocimiento que tengamos del estado de la red, pero los valores van de 180 segundos (2 minutos) a 900 segundos (15 minutos). Valor entero de 32 bits con signo.
  • t-expiración: Indica el intervalo de tiempo que el servidor esclavo estará haciendo reintentos de conexión con el servidor maestro porque este no contesta. Hasta que no pase este tiempo, aunque el servidor esclavo no se pueda actualizar, responde a las consultas de forma autoritaria, pero llegado el momento de expiración, deja de contestar a las consultas de la zona que no ha podido actualizarse. El RFC 1912 recomienda utilizar valores comprendidos entre 1209600 y 2419200 segundos, de 2 a 4 semanas. Valor entero de 32 bits con signo.
  • nx: Indica el intervalo de tiempo que se mantendrá una consulta no resuelta en la caché de los servidores de nombres; transcurrido dicho tiempo, se volverá a intentar resolver la consulta (RFC 2308). Por ejemplo, si se hace una consulta del FQDN fpg.asir.com, y no es posible resolverla, el servidor devolverá un error de nombre (Name Error o NXDOMAIN). Durante los siguientes nx segundos, si se vuelve a hacer la misma consulta, se responderá de la misma forma; pero pasadas las dos horas, se intentaría de nuevo resolver la consulta fallida. Los valores posibles van de 0 hasta 10800 (3 horas). Anteriormente, este campo era el TTL por defecto de los RR, pero luego se introdujo la directiva $TTL como obligatoria y se le dio al campo el actual significado. Es por esto que nos podemos encontrar valores superiores a 10800 en antiguas configuraciones (versiones 4 y 8 de BIND); en estos casos BIND manda un mensaje log cuando se carga la zona y asume el valor 10800 para el parámetro nx. Valor entero de 32 bits con signo.
Volver