Pointer votre propre domaine vers un serveur de tagging : le CNAME, le certificat et l’erreur 1014 de Cloudflare

Deux raisons, et elles sont différentes. Pour un bloqueur de publicité, une requête est tierce si son nom d’hôte figure dans une liste ; signalhost.io n’en figure dans aucune aujourd’hui mais pourrait demain ; votresite.com n’y figurera jamais. Pour un navigateur, un cookie déposé par une réponse de metrics.votresite.com est un cookie first-party pour votresite.com, tandis qu’un cookie d’un autre domaine est un cookie tiers, que Safari refuse purement et simplement. C’est ce cookie qui conserve un clic sur une annonce pour Google Ads, Meta et TikTok jusqu’à l’achat. Cela ne lui donne pas pour autant une durée de vie plus longue : Safari plafonne toujours à sept jours les cookies posés par un serveur situé à une autre adresse. Le serveur de tagging est le même dans les deux cas. C’est le nom d’hôte qui change la façon dont il est traité.

Vous partez de zéro avec un serveur de tagging ? Configurer Google Tag Manager côté serveur, étape par étape.

Un CNAME, chez votre fournisseur DNS, qui fait pointer le sous-domaine choisi vers notre point d’entrée DNS seul :

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

Pas vers votre nom d’hôte aléatoire de locataire, et pas vers un joker. tenants.signalhost.io est un nom que nous publions spécialement pour cela, et la raison pour laquelle ce doit être ce nom-là fait l’objet de la section suivante.

Si votre propre domaine est chez Cloudflare, créez l’enregistrement avec le proxy DÉSACTIVÉ — le nuage gris, « DNS only ». Un enregistrement proxifié ferait passer les requêtes de vos visiteurs par votre compte Cloudflare jusqu’à nous, et l’étape du certificat ci-dessous ne peut pas aboutir à travers lui.

Nos propres noms d’hôte sont derrière Cloudflare. Si un client pointe son CNAME vers l’un de nos noms proxifiés — le joker, ou un nom d’hôte de locataire — son trafic arrive chez Cloudflare pour un nom d’hôte appartenant à un autre compte Cloudflare que le nôtre. Cloudflare le refuse avec l’erreur 1014, « CNAME Cross-User Banned ». La page qui l’affiche est celle de Cloudflare, ne mentionne ni vous ni nous, et rien dans votre DNS, votre site ou votre navigateur ne l’explique.

tenants.signalhost.io n’est pas proxifié, à dessein : il résout directement vers nos serveurs, si bien qu’un CNAME vers lui fonctionne tout simplement. La vérification DNS du tableau de bord reconnaît le cas de la cible proxifiée par son nom et dit quoi changer, mais il est plus rapide de ne jamais le produire.

Dès que l’enregistrement résout, nous demandons un certificat Let’s Encrypt pour votre nom d’hôte. La validation est HTTP-01 : Let’s Encrypt récupère un chemin précis en HTTP en clair sur le port 80 depuis le nom, et nous y répondons. HTTP en clair parce qu’il n’y a pas encore de certificat — c’est précisément ce qui est en train d’être obtenu — et c’est le seul chemin non chiffré auquel notre bordure répond. C’est une comparaison de nonce ; rien d’autre n’est joignable par cette voie.

Comptez quelques minutes. Le tableau de bord affiche trois étapes dans l’ordre : le CNAME résout, le certificat est émis, le nom d’hôte sert. Une étape bloquée sur le certificat avec le CNAME au vert signifie presque toujours un enregistrement proxifié de votre côté — Cloudflare répond à la requête de validation avec son propre certificat et sa propre page, et Let’s Encrypt voit la mauvaise chose.

La balise Google de votre conteneur web porte l’URL du conteneur serveur. Quand le nom d’hôte commence à servir, nous la réécrivons vers votre domaine personnalisé et republions le conteneur — et la réécrivons vers le nom d’hôte de locataire si vous retirez le domaine. À partir de ce moment, vos hits vont vers votre propre domaine.

Il vous reste une chose à faire : l’extrait de votre site charge toujours Tag Manager depuis votre adresse sur signalhost.io. Il continue de fonctionner, mais c’est la seule requête qu’une liste de filtres pourrait encore repérer : remplacez-le donc. La page du conteneur affiche le nouvel extrait dès que le domaine sert, et nous vous l’envoyons par e-mail au même moment. Remplacez-le plutôt que d’en ajouter un second : deux extraits chargent le conteneur deux fois.

Retirer un domaine, c’est la même chose à l’envers. Retirez-le dans le tableau de bord, remettez sur votre site l’extrait que la page du conteneur affiche alors — il se charge de nouveau depuis votre adresse sur signalhost.io — et supprimez l’enregistrement DNS en dernier. Supprimez l’enregistrement d’abord et, jusqu’à ce que le tableau de bord s’en aperçoive, votre site charge ses balises depuis un nom qui ne résout plus.

• Erreur 1014 dans le navigateur : le CNAME pointe vers un de nos noms proxifiés. Changez la cible en tenants.signalhost.io.
• CNAME au vert, certificat en attente depuis plus de quinze minutes : votre enregistrement est proxifié. Passez le nuage en gris chez votre fournisseur DNS.
• Le CNAME ne passe jamais au vert : cherchez un enregistrement A ou AAAA en conflit sur le même nom — un CNAME ne peut pas coexister avec eux — et laissez à la propagation jusqu’à une heure.
• Ça sert, mais la page du conteneur ne montre aucun trafic depuis le nouveau nom : le conteneur web n’a pas encore été republié. Cela se produit dans les minutes qui suivent la mise en service du nom d’hôte ; la page du conteneur indique vers quel nom d’hôte la balise pointe actuellement.
• Ça sert, mais votre site charge toujours Tag Manager depuis signalhost.io : l’ancien extrait est encore sur la page. Remplacez-le par celui de la page du conteneur.