Torna al blog

Blog

Puntare il tuo dominio a un server di tagging: il CNAME, il certificato e l’errore 1014 di Cloudflare

Pubblicato · 4 min di lettura

Il primo nome host che ricevi da noi è un’etichetta casuale sotto signalhost.io. Funziona, e per molti siti basta: non è già googletagmanager.com. Ma un sottodominio del tuo dominio è la versione che sopravvive a ogni lista di filtri e a ogni regola del browser, perché per il browser è semplicemente il tuo sito. Arrivarci richiede un record DNS e qualche minuto. Sbagliarlo di poco produce un messaggio di errore che nulla dalla tua parte può spiegare, quindi ecco l’intera procedura, guasto compreso.

Perché un sottodominio del tuo sito

Due ragioni, e sono diverse. Per un ad blocker, una richiesta è di terze parti se il suo nome host è in una lista, e signalhost.io oggi non è in nessuna ma potrebbe esserlo domani; tuosito.com non lo sarà mai. Per un browser, un cookie impostato da una risposta di metrics.tuosito.com è un cookie first-party per tuosito.com, con la durata più lunga che ciò comporta, mentre un cookie di un altro dominio viene limitato o rifiutato. Il server di tagging è lo stesso in entrambi i casi. È il nome host a cambiare il modo in cui viene trattato.

Il record

Un CNAME, presso il tuo provider DNS, che punta il sottodominio scelto al nostro endpoint solo DNS:

metrics.yoursite.com.   CNAME   tenants.signalhost.io.

Non al tuo nome host casuale di tenant, e non a un wildcard. tenants.signalhost.io è un nome che pubblichiamo apposta per questo, e il motivo per cui deve essere proprio quel nome è nella sezione successiva.

Se il tuo dominio è su Cloudflare, crea il record con il proxy SPENTO: la nuvola grigia, «DNS only». Un record con proxy instraderebbe le richieste dei tuoi visitatori attraverso il tuo account Cloudflare fino a noi, e il passaggio del certificato qui sotto non può completarsi attraverso di esso.

L’errore 1014 di Cloudflare, e perché la destinazione deve essere solo DNS

I nostri nomi host stanno dietro Cloudflare. Se un cliente punta il suo CNAME a uno dei nostri nomi con proxy — il wildcard, o un nome host di tenant — il suo traffico arriva a Cloudflare per un nome host che appartiene a un account Cloudflare diverso dal nostro. Cloudflare lo rifiuta con l’errore 1014, «CNAME Cross-User Banned». La pagina che lo mostra è di Cloudflare, non menziona nessuno dei due, e nulla nel tuo DNS, nel tuo sito o nel tuo browser lo spiega.

tenants.signalhost.io è senza proxy di proposito: risolve direttamente ai nostri server, quindi un CNAME verso di esso funziona e basta. Il controllo DNS della dashboard riconosce per nome il caso della destinazione con proxy e dice cosa cambiare, ma è più rapido non arrivarci mai.

Il certificato

Non appena il record risolve, richiediamo un certificato Let’s Encrypt per il tuo nome host. La validazione è HTTP-01: Let’s Encrypt recupera un percorso specifico in HTTP in chiaro sulla porta 80 dal nome, e noi rispondiamo. HTTP in chiaro perché non c’è ancora un certificato — è esattamente ciò che si sta ottenendo — e questo è l’unico percorso non cifrato a cui il nostro edge risponde. È un confronto di nonce; nient’altro è raggiungibile per quella via.

Conta qualche minuto. La dashboard mostra tre passaggi in ordine: il CNAME risolve, il certificato viene emesso, il nome host sta servendo. Un passaggio bloccato sul certificato con il CNAME verde significa quasi sempre un record con proxy dalla tua parte: Cloudflare risponde alla richiesta di validazione con il proprio certificato e la propria pagina, e Let’s Encrypt vede la cosa sbagliata.

Quando sta servendo

Il tag Google nel tuo container web contiene l’URL del container server, e noi lo riscriviamo sul dominio personalizzato e ripubblichiamo il container quando il nome host inizia a servire — e lo riportiamo al nome host di tenant se rimuovi il dominio. Lo snippet del tuo sito non cambia; carica il container, e il container sa dove inviare.

Per questo l’ordine della rimozione conta. Rimuovi prima il dominio nella dashboard, poi cancella il record DNS. Cancella prima il record e, finché la dashboard non se ne accorge, il container continua a mandare i tuoi visitatori a un nome che non risolve più.

Se non funziona

  • Errore 1014 nel browser: il CNAME punta a un nostro nome con proxy. Cambia la destinazione in tenants.signalhost.io.
  • CNAME verde, certificato in attesa da più di quindici minuti: il tuo record ha il proxy. Metti la nuvola in grigio presso il tuo provider DNS.
  • Il CNAME non diventa mai verde: cerca un record A o AAAA in conflitto sullo stesso nome — un CNAME non può coesistere con essi — e concedi alla propagazione fino a un’ora.
  • Sta servendo, ma la pagina del container non mostra traffico dal nuovo nome: il container web non è ancora stato ripubblicato. Succede entro un paio di minuti da quando il nome host è attivo; la pagina del container mostra a quale nome host punta attualmente il tag.

Smetti di perdere dati per gli ad blocker

Diecimila richieste al mese, gratis, per tutto il tempo che vuoi. Quattro minuti per scoprire se serve.