Por qué la raíz de un dominio no puede ser un CNAME y otras curiosidades sobre el DNS

Programación

Este post va a utilizar la pregunta anterior para explorar DNS, dig, Aexpedientes, CNAMEregistros, y ALIAS/ANAMElos registros desde la perspectiva de un principiante. Entonces empecemos.

Primero, algunas definiciones

  • Sistema de nombres de dominio (DNS): el sistema general para convertir un nombre de dominio memorable humano (ejemplo.com) en una dirección IP (93.184.216.34). La dirección IP es de un servidor, comúnmente un servidor web, donde se almacenan los archivos necesarios para mostrar una página web.
  • Servidor DNS (también conocido como servidor de nombres o servidor de nombres): utiliza software DNS para almacenar información sobre direcciones de dominio. Hay varios niveles: los que pertenecen a cada ISP, raíz (13 en total en todo el mundo), dominio de nivel superior (TLD, por ejemplo, '.com') y servidores DNS de nivel de dominio.
  • Nombre de dominio : el dominio (ejemplo) combinado con el TLD (.com). El término "dominio" se utiliza a menudo como sinónimo del nombre de dominio, aunque son diferentes. Cuando compra un 'dominio' a un registrador o revendedor, compra los derechos sobre un nombre de dominio específico (ejemplo.com) y cualquier subdominio que desee crear (mi-sitio.example.com, mail.example.com, etc).

Flujo de consultas de alto nivel

El flujo de alto nivel de lo que sucede cuando escribe "example.com" en su navegador se puede simplificar para eliminar los saltos a los servidores DNS ISP, Root y TLD como se muestra a continuación:

Un dominio suele tener dos o más servidores de nombres, que contienen registros relacionados con el nombre de dominio (ejemplo.com).

Se pueden almacenar muchos tipos de registros, la mayoría de los cuales pueden tener múltiples entradas por tipo:

  • A: Registros de direcciones que asignan el nombre de dominio a una dirección IP
  • CNAME: Registro de nombre canónico. Se utiliza para asignar un alias a un nombre de dominio (o subdominio) a otro. Veremos esto con más detalle más adelante.
  • MX: Registros de intercambio de correo que indican a los agentes de entrega de correo electrónico dónde deben entregar su correo electrónico.
  • TXT: registros de texto flexibles, para almacenar cadenas para una variedad de usos
  • SOA: registro de inicio de autoridad singular mantenido en el nivel superior del dominio. Contiene información requerida específica sobre el dominio, por ejemplo, su servidor de nombres primario
  • NS: Los servidores de nombres asociados con el dominio

Cuando su dispositivo envía una consulta que llega a un servidor de nombres, el servidor busca en el nodo de registro del dominio un Aregistro y la dirección IP almacenada asociada (ejemplo.com: 93.184.216.34). A continuación, se devuelve al dispositivo, que se utiliza para enviar una solicitud al servidor web correcto para recuperar la página web o el recurso solicitado.

Usando 'excavar'

dig( groper de información de dominio ) es una herramienta de línea de comandos para consultar servidores DNS. Este comando se usa generalmente para solucionar problemas o, como ahora, para comprender más sobre la configuración de un sistema.

$ dig example.comda como resultado una respuesta larga impresa en el terminal, la salida predeterminada que se detalla aquí, de la que estamos interesados ​​en ANSWER SECTION.

;; ANSWER SECTION: example.com. 72703 IN A 93.184.216.34

Y ahí vamos, podemos ver que example.comdevuelve un Arécord de 93.184.216.34. A veces, los dominios tendrán más de un Aregistro, si más de un servidor web puede proporcionar la información necesaria.

¡Hay más! Si tratamos a cabo algunos otros ejemplos, podemos ver pronto que aparece otro registro común: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION: www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net. www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net. e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

El uso de la +shortbandera nos permite ver claramente el camino formado:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net. e11316.a.akamaiedge.net. 23.217.6.192

CNAME

Un CNAMEregistro permite utilizar un nombre de dominio como alias de otro dominio canónico (verdadero).

Cuando el servidor DNS devuelve un CNAMEregistro, no se lo devolverá al cliente. Más bien buscará nuevamente el nombre de dominio devuelto y, a su vez, devolverá la Adirección IP del registro. Esta cadena puede continuar a muchos CNAMEniveles de profundidad, pero luego sufre pequeños impactos en el rendimiento de múltiples búsquedas antes de que se lleve a cabo el almacenamiento en caché.

Un ejemplo simple de esto podría ser si tiene un servidor donde guarda todas sus fotos. Normalmente puede acceder a él a través de photos.example.com. Sin embargo, es posible que también desee permitir el acceso a través de photographs.example.com. Una forma de hacer esto posible es agregar un CNAMEregistro que apunte photographsa photos. Esto significa que cuando alguien visite, photographs.example.comse le dará el mismo contenido que photos.example.com.

Usando la consulta $ dig photographs.example.comveríamos:

photographs.example.com IN CNAME photos.example.com photos.example.com IN A xx.xxx.x.xxx

Es importante tener en cuenta que CNAMEes esa pieza del lado derecho. El lado izquierdo es el nombre de alias o etiqueta.

Otro uso común es para el wwwsubdominio. Haber comprado example.comprobablemente también quiera que los usuarios que escriben www.example.comvean el mismo contenido.

Vale la pena señalar aquí que example.comse puede llamar nombre de dominio ápice, raíz o simple.

Una opción sería configurar otro Aregistro, apuntando a la misma dirección IP que para example.com. Esto es completamente válido, y es lo que hace el real example.com, pero no escala bien. ¿Qué sucede si necesita actualizar la dirección IP a la que example.comapunta? También necesitaría actualizarlo para el wwwsubdominio y cualquier otro que pueda usar.

Si CNAMEse utilizó un registro www.example.compara señalar con alias example.com, solo se debería actualizar el dominio raíz, ya que todos los demás nodos apuntan a él.

Limitaciones de CNAME

En el momento en que se redactaron los estándares DNS, se establecieron algunas reglas para regir su uso. RFC 1912 y RFC 2181 establecen que:

  • SOAy los NSregistros son obligatorios para estar presentes en el dominio raíz
  • CNAMEregistros sólo pueden existir como registros individuales y no pueden ser combinadas con cualquier otro registro de recursos (DNSSEC SIG, NXTy KEY RRregistros exceptuados)

Esto excluye un CNAMEuso en el dominio raíz, ya que las dos reglas se contradecirían entre sí.

Lo importante aquí es que se trata de una limitación contractual, no técnica. Es posible usar un CNAMEen la raíz, pero puede resultar en errores inesperados, ya que está rompiendo el contrato de comportamiento esperado.

Cloudflare cuenta un ejemplo de esto, describiendo los problemas que encontraron con los servidores de correo de Microsoft Exchange después de haber usado un CNAMEen su dominio raíz:

Los dominios generalmente designan los servidores que manejan su correo electrónico a través de lo que se conoce como registro MX. El problema era que los servidores de Exchange ... podían recoger el CNAME en el registro raíz y luego no respetar adecuadamente el CNAME establecido en el registro MX. Realmente no se puede culpar a Exchange. Operaron bajo los supuestos establecidos por la especificación DNS.

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

The modern internet

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

example.com IN CNAME my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.example.com IN CNAME my-app.herokuapp.com. www.example.com IN CNAME my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

The solution

Several DNS providers have now developed custom solutions to work around this problem, including:

  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME (virtual) at CloudFlare

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

These virtual records can sit alongside other records at the root without any fear of unintended behaviours. Depending on the provider’s method of DNS resolution when following the CNAME chain, they may also have performance benefits from caching previous lookups.

For a DNSimple setup, we would then configure as below. This solution has all the advantages of domain name aliasing, and none of the risks of using it at root level.

example.com IN ALIAS my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.

Thanks for reading! ?

As always, open to any corrections or additional points.

Resources

  • What is a DNS Server
  • Set Up a DNS Name Server
  • DNSimple support pages and ALIAS blog
  • Cloudflare support and CNAME blog
  • dig HowTo
  • Several great Stack Overflow or StackExchange posts
  • Well written Wikipedia entries
  • Netlify blog ‘To www or not www’