Kierowanie własnej domeny na serwer tagowania: CNAME, certyfikat i błąd 1014 Cloudflare

Dwa powody, i są różne. Dla blokera reklam żądanie jest zewnętrzne, jeśli jego nazwa hosta jest na liście — signalhost.io dziś na żadnej nie jest, ale jutro może być; twojastrona.pl nie będzie nigdy. Dla przeglądarki ciasteczko ustawione przez odpowiedź z metrics.twojastrona.pl jest ciasteczkiem własnym dla twojastrona.pl, z dłuższym czasem życia, jaki z tego wynika, podczas gdy ciasteczko z innej domeny jest ograniczane lub odrzucane. Serwer tagowania jest w obu przypadkach ten sam. To nazwa hosta zmienia sposób, w jaki jest traktowany.

Jeden CNAME u Twojego dostawcy DNS, kierujący wybraną subdomenę na nasz punkt wejścia tylko-DNS:

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

Nie na Twoją losową nazwę hosta najemcy i nie na wildcard. tenants.signalhost.io to nazwa, którą publikujemy specjalnie w tym celu, a powód, dla którego musi to być właśnie ta nazwa, jest w następnej sekcji.

Jeśli Twoja własna domena jest w Cloudflare, utwórz rekord z WYŁĄCZONYM proxy — szara chmurka, „DNS only”. Rekord z proxy kierowałby żądania Twoich odwiedzających przez Twoje konto Cloudflare do nas, a krok z certyfikatem poniżej nie może się przez nie zakończyć.

Nasze własne nazwy hostów stoją za Cloudflare. Jeśli klient skieruje swój CNAME na jedną z naszych nazw z proxy — wildcard albo nazwę hosta najemcy — jego ruch trafia do Cloudflare dla nazwy hosta należącej do innego konta Cloudflare niż nasze. Cloudflare odrzuca to błędem 1014, „CNAME Cross-User Banned”. Strona, która go pokazuje, należy do Cloudflare, nie wspomina o żadnym z nas, a nic w Twoim DNS, Twojej stronie ani przeglądarce go nie wyjaśnia.

tenants.signalhost.io celowo nie ma proxy: rozwiązuje się bezpośrednio na nasze serwery, więc CNAME na niego po prostu działa. Sprawdzenie DNS w panelu rozpoznaje po nazwie przypadek celu z proxy i mówi, co zmienić, ale szybciej jest w ogóle do tego nie dopuścić.

Gdy tylko rekord się rozwiązuje, wnioskujemy o certyfikat Let's Encrypt dla Twojej nazwy hosta. Walidacja to HTTP-01: Let's Encrypt pobiera z tej nazwy konkretną ścieżkę zwykłym HTTP na porcie 80, a my na nią odpowiadamy. Zwykłym HTTP, bo certyfikatu jeszcze nie ma — to właśnie on jest uzyskiwany — i to jedyna nieszyfrowana ścieżka, na jaką nasz edge w ogóle odpowiada. To porównanie nonce; nic więcej nie jest tą drogą osiągalne.

Licz na kilka minut. Panel pokazuje trzy kroki po kolei: CNAME się rozwiązuje, certyfikat zostaje wydany, nazwa hosta serwuje. Krok zatrzymany na certyfikacie przy zielonym CNAME niemal zawsze oznacza rekord z proxy po Twojej stronie — Cloudflare odpowiada na żądanie walidacyjne własnym certyfikatem i własną stroną, a Let's Encrypt widzi nie to, co trzeba.

Tag Google w Twoim kontenerze internetowym zawiera adres URL kontenera serwerowego, a my przepisujemy go na domenę własną i ponownie publikujemy kontener, gdy nazwa hosta zaczyna serwować — i przepisujemy z powrotem na nazwę hosta najemcy, jeśli usuniesz domenę. Fragment kodu na Twojej stronie się nie zmienia; ładuje kontener, a kontener wie, dokąd wysyłać.

Dlatego kolejność usuwania ma znaczenie. Najpierw usuń domenę w panelu, potem usuń rekord DNS. Usuń najpierw rekord, a do czasu, aż panel to zauważy, kontener wciąż kieruje Twoich odwiedzających na nazwę, która już się nie rozwiązuje.

• Błąd 1014 w przeglądarce: CNAME wskazuje naszą nazwę z proxy. Zmień cel na tenants.signalhost.io.
• CNAME zielony, certyfikat w toku dłużej niż piętnaście minut: Twój rekord ma proxy. Przełącz chmurkę na szarą u dostawcy DNS.
• CNAME nigdy nie robi się zielony: poszukaj konfliktowego rekordu A lub AAAA pod tą samą nazwą — CNAME nie może z nimi współistnieć — i daj propagacji do godziny.
• Serwuje, ale strona kontenera nie pokazuje ruchu z nowej nazwy: kontener internetowy nie został jeszcze ponownie opublikowany. Dzieje się to w ciągu paru minut od uruchomienia nazwy hosta; strona kontenera pokazuje, na którą nazwę hosta tag obecnie wskazuje.