Blog
Apuntar tu propio dominio a un servidor de etiquetado: el CNAME, el certificado y el error 1014 de Cloudflare
Publicado · 4 min de lectura
El primer nombre de host que recibes de nosotros es una etiqueta aleatoria bajo signalhost.io. Funciona, y para muchos sitios basta: ya no es googletagmanager.com. Pero un subdominio de tu propio dominio es la versión que sobrevive a cualquier lista de filtros y a cualquier regla del navegador, porque para el navegador es simplemente tu sitio. Llegar ahí lleva un registro DNS y unos minutos. Hacerlo un poco mal produce un mensaje de error que nada en tu lado puede explicar, así que aquí va el procedimiento completo, incluido el fallo.
Por qué un subdominio de tu propio sitio
Dos razones, y son distintas. Para un bloqueador de anuncios, una solicitud es de terceros si su nombre de host está en una lista, y signalhost.io hoy no está en ninguna pero podría estarlo mañana; tusitio.com nunca lo estará. Para un navegador, una cookie colocada por una respuesta de metrics.tusitio.com es una cookie de primera parte para tusitio.com, con la vida más larga que eso implica, mientras que una cookie de otro dominio se recorta o se rechaza. El servidor de etiquetado es el mismo en ambos casos. El nombre de host es lo que cambia cómo se le trata.
El registro
Un CNAME, en tu proveedor de DNS, que apunte el subdominio que elegiste a nuestro punto de entrada solo DNS:
metrics.yoursite.com. CNAME tenants.signalhost.io.No a tu nombre de host aleatorio de inquilino, y no a un comodín. tenants.signalhost.io es un nombre que publicamos específicamente para esto, y la razón por la que tiene que ser ese nombre es la siguiente sección.
Si tu propio dominio está en Cloudflare, crea el registro con el proxy APAGADO: la nube gris, «solo DNS». Un registro con proxy enrutaría las solicitudes de tus visitantes a través de tu cuenta de Cloudflare hasta nosotros, y el paso del certificado de abajo no puede completarse a través de él.
El error 1014 de Cloudflare, y por qué el destino debe ser solo DNS
Nuestros propios nombres de host están detrás de Cloudflare. Si un cliente apunta su CNAME a uno de nuestros nombres con proxy —el comodín, o un nombre de host de inquilino—, su tráfico llega a Cloudflare para un nombre de host que pertenece a una cuenta de Cloudflare distinta de la nuestra. Cloudflare lo rechaza con el error 1014, «CNAME Cross-User Banned». La página que lo muestra es de Cloudflare, no menciona a ninguno de los dos, y nada en tu DNS, tu sitio o tu navegador lo explica.
tenants.signalhost.io está sin proxy a propósito: resuelve directamente a nuestros servidores, así que un CNAME hacia él simplemente funciona. La comprobación de DNS del panel reconoce el caso del destino con proxy por su nombre y dice qué cambiar, pero es más rápido no llegar a hacerlo.
El certificado
En cuanto el registro resuelve, solicitamos un certificado de Let's Encrypt para tu nombre de host. La validación es HTTP-01: Let's Encrypt recupera una ruta concreta por HTTP sin cifrar en el puerto 80 desde el nombre, y nosotros la respondemos. HTTP sin cifrar porque todavía no hay certificado —eso es lo que se está obteniendo—, y esta es la única ruta sin cifrar que nuestro borde responde en absoluto. Es una comparación de nonce; nada más es accesible por ese camino.
Cuenta con unos minutos. El panel muestra tres pasos en orden: el CNAME resuelve, se emite el certificado, el nombre de host está sirviendo. Un paso atascado en el certificado con el CNAME en verde casi siempre significa un registro con proxy de tu lado: Cloudflare responde a la solicitud de validación con su propio certificado y su propia página, y Let's Encrypt ve lo que no debe.
Cuando ya está sirviendo
La etiqueta de Google de tu contenedor web lleva la URL del contenedor de servidor, y la reescribimos al dominio personalizado y republicamos el contenedor cuando el nombre de host empieza a servir, y la devolvemos al nombre de host de inquilino si quitas el dominio. El fragmento de tu sitio no cambia; carga el contenedor, y el contenedor sabe adónde enviar.
Por eso importa el orden al quitarlo. Quita primero el dominio en el panel y después borra el registro DNS. Si borras primero el registro, hasta que el panel se dé cuenta, el contenedor sigue apuntando a tus visitantes a un nombre que ya no resuelve.
Si no funciona
- Error 1014 en el navegador: el CNAME apunta a un nombre nuestro con proxy. Cambia el destino a tenants.signalhost.io.
- CNAME en verde, certificado pendiente durante más de quince minutos: tu registro tiene proxy. Pon la nube en gris en tu proveedor de DNS.
- El CNAME nunca se pone en verde: busca un registro A o AAAA en conflicto con el mismo nombre —un CNAME no puede coexistir con ellos— y dale a la propagación hasta una hora.
- Sirviendo, pero la página del contenedor no muestra tráfico del nombre nuevo: el contenedor web todavía no se ha republicado. Ocurre a los pocos minutos de que el nombre de host esté activo; la página del contenedor muestra a qué nombre de host apunta la etiqueta ahora mismo.
