Retour au blog

Blog

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

Publié · 4 min de lecture

Le premier nom d’hôte que vous recevez de nous est une étiquette aléatoire sous signalhost.io. Il fonctionne, et pour beaucoup de sites il suffit — ce n’est déjà pas googletagmanager.com. Mais un sous-domaine de votre propre domaine est la version qui survit à chaque liste de filtres et à chaque règle de navigateur, parce que pour le navigateur c’est tout simplement votre site. Y parvenir prend un enregistrement DNS et quelques minutes. Le faire légèrement mal produit un message d’erreur que rien de votre côté ne peut expliquer, alors voici toute la procédure, y compris la panne.

Pourquoi un sous-domaine de votre propre site

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, avec la durée de vie plus longue que cela implique, tandis qu’un cookie d’un autre domaine est plafonné ou refusé. 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é.

L’enregistrement

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.

L’erreur 1014 de Cloudflare, et pourquoi la cible doit être DNS seul

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.

Le certificat

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.

Une fois que ça sert

La balise Google de votre conteneur web porte l’URL du conteneur serveur, et nous la réécrivons vers le domaine personnalisé et republions le conteneur quand le nom d’hôte commence à servir — et la réécrivons vers le nom d’hôte de locataire si vous retirez le domaine. L’extrait de votre site ne change pas ; il charge le conteneur, et le conteneur sait où envoyer.

C’est pourquoi l’ordre du retrait compte. Retirez d’abord le domaine dans le tableau de bord, puis supprimez l’enregistrement DNS. Supprimez l’enregistrement d’abord et, jusqu’à ce que le tableau de bord s’en aperçoive, le conteneur envoie encore vos visiteurs vers un nom qui ne résout plus.

Si ça ne fonctionne pas

  • 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.

Cessez de perdre vos données

Dix mille requêtes par mois, gratuitement, aussi longtemps que vous voulez. Quatre minutes pour savoir si ça aide.