Blog
Apontar o seu próprio domínio para um servidor de tagging: o CNAME, o certificado e o erro 1014 da Cloudflare
Publicado · 4 min de leitura
O primeiro nome de anfitrião que recebe de nós é uma etiqueta aleatória sob signalhost.io. Funciona, e para muitos sites chega — já não é googletagmanager.com. Mas um subdomínio do seu próprio domínio é a versão que sobrevive a todas as listas de filtros e a todas as regras dos navegadores, porque para o navegador é simplesmente o seu site. Chegar lá leva um registo DNS e alguns minutos. Fazê-lo ligeiramente mal produz uma mensagem de erro que nada do seu lado consegue explicar, por isso aqui fica o procedimento completo, incluindo a falha.
Porquê um subdomínio do seu próprio site
Duas razões, e são diferentes. Para um bloqueador de anúncios, um pedido é de terceiros se o seu nome de anfitrião está numa lista, e signalhost.io hoje não está em nenhuma mas poderia estar amanhã; oseusite.com nunca estará. Para um navegador, um cookie definido por uma resposta de metrics.oseusite.com é um cookie de primeira parte para oseusite.com, com a duração mais longa que isso implica, enquanto um cookie de outro domínio é limitado ou recusado. O servidor de tagging é o mesmo em ambos os casos. O nome de anfitrião é o que muda a forma como é tratado.
O registo
Um CNAME, no seu fornecedor de DNS, a apontar o subdomínio que escolheu para o nosso ponto de entrada só DNS:
metrics.yoursite.com. CNAME tenants.signalhost.io.Não para o seu nome de anfitrião aleatório de inquilino, e não para um wildcard. tenants.signalhost.io é um nome que publicamos especificamente para isto, e a razão pela qual tem de ser esse nome está na secção seguinte.
Se o seu próprio domínio está na Cloudflare, crie o registo com o proxy DESLIGADO — a nuvem cinzenta, «DNS only». Um registo com proxy encaminharia os pedidos dos seus visitantes através da sua conta Cloudflare até nós, e o passo do certificado abaixo não consegue completar-se através dele.
O erro 1014 da Cloudflare, e porque o destino tem de ser só DNS
Os nossos próprios nomes de anfitrião estão atrás da Cloudflare. Se um cliente aponta o seu CNAME para um dos nossos nomes com proxy — o wildcard, ou um nome de anfitrião de inquilino — o seu tráfego chega à Cloudflare para um nome de anfitrião que pertence a uma conta Cloudflare diferente da nossa. A Cloudflare recusa-o com o erro 1014, «CNAME Cross-User Banned». A página que o mostra é da Cloudflare, não menciona nenhum de nós, e nada no seu DNS, no seu site ou no seu navegador o explica.
tenants.signalhost.io está sem proxy de propósito: resolve diretamente para os nossos servidores, por isso um CNAME para ele simplesmente funciona. A verificação de DNS do painel reconhece o caso do destino com proxy pelo nome e diz o que mudar, mas é mais rápido nunca o fazer.
O certificado
Assim que o registo resolve, pedimos um certificado Let's Encrypt para o seu nome de anfitrião. A validação é HTTP-01: a Let's Encrypt obtém um caminho específico por HTTP simples na porta 80 a partir do nome, e nós respondemos-lhe. HTTP simples porque ainda não há certificado — é isso que está a ser obtido — e este é o único caminho não cifrado a que a nossa edge responde. É uma comparação de nonce; nada mais é alcançável por essa via.
Conte com alguns minutos. O painel mostra três passos por ordem: o CNAME resolve, o certificado é emitido, o nome de anfitrião está a servir. Um passo preso no certificado com o CNAME a verde significa quase sempre um registo com proxy do seu lado — a Cloudflare responde ao pedido de validação com o seu próprio certificado e a sua própria página, e a Let's Encrypt vê a coisa errada.
Depois de estar a servir
A etiqueta do Google no seu contentor web contém o URL do contentor de servidor, e nós reescrevemo-lo para o domínio personalizado e republicamos o contentor quando o nome de anfitrião começa a servir — e reescrevemo-lo de volta para o nome de anfitrião de inquilino se remover o domínio. O excerto do seu site não muda; carrega o contentor, e o contentor sabe para onde enviar.
É por isso que a ordem da remoção importa. Remova primeiro o domínio no painel, depois apague o registo DNS. Apague primeiro o registo e, até o painel reparar, o contentor continua a apontar os seus visitantes para um nome que já não resolve.
Se não funcionar
- Erro 1014 no navegador: o CNAME aponta para um nome nosso com proxy. Mude o destino para tenants.signalhost.io.
- CNAME a verde, certificado pendente há mais de quinze minutos: o seu registo tem proxy. Ponha a nuvem a cinzento no seu fornecedor de DNS.
- O CNAME nunca fica a verde: procure um registo A ou AAAA em conflito no mesmo nome — um CNAME não pode coexistir com eles — e dê à propagação até uma hora.
- Está a servir, mas a página do contentor não mostra tráfego do novo nome: o contentor web ainda não foi republicado. Acontece nos minutos seguintes a o nome de anfitrião ficar ativo; a página do contentor mostra para que nome de anfitrião a etiqueta aponta atualmente.
