Markowy krótki link to w gruncie rzeczy dwie elementy infrastruktury złączone razem: rekord DNS, który mówi internetowi, że Twoja subdomena znajduje się tutaj, oraz certyfikat TLS, który potwierdza, że połączenie HTTPS jest legalne. Żaden z nich nie jest skomplikowany osobno. Ciekawą kwestią jest to, co działa na edge po rozwiązaniu przekierowania - jak platforma obsługująca tysiące niestandardowych domen najemców wystawia certyfikaty na żądanie, unika limitów szybkości Let's Encrypt, mieści się w 15ms p95 budżecie latencji i odzyskuje sprawność, gdy zespół DNS klienta zniszczy jego CNAME w trakcie kampanii.
O tym właśnie jest ten artykuł.
TL;DR#
- Weryfikacja DNS to wyzwanie CNAME lub TXT; wystawienie TLS odbywa się przez ACME on-demand, wyzwalane za pierwszym razem, gdy nowa nazwa hosta otrzymuje żądanie.
- Let's Encrypt ogranicza do 50 certyfikatów na zarejestrowaną domenę tygodniowo - co oznacza, że przy skali potrzebujesz osobnej zarejestrowanej domeny na najemcę, a nie subdomen pojedynczego
elido.me. - Certyfikaty ECDSA P-256 są znacznie szybsze niż RSA-2048 na poziomie TLS handshake; Elido wystawia P-256 dla każdej domeny niestandardowej.
- Trzy rzeczy rutynowo psują konfiguracje domen niestandardowych w produkcji: opóźnienie propagacji DNS, wygasłe rekordy CAA i klienci usuwający własny CNAME. Każda ma konkretną ścieżkę naprawy.
Dwie części skracacza z własną domeną#
Niestandardowe domeny dla krótkich linków wymagają dwóch rzeczy od Ciebie jako właściciela domeny i dwóch rzeczy od platformy.
Od Ciebie: zmiana DNS (rekord CNAME lub ALIAS wskazujący Twoją subdomenę na edge platformy) i dowód własności (zazwyczaj rekord DNS TXT lub wyzwanie CNAME, które pozwala platformie zweryfikować, że kontrolujesz domenę, zanim zgodzi się ją obsługiwać).
Od platformy: reguła routingu, która rozpoznaje Twoją nazwę hosta i wie, z którego workspace'u serwować linki, oraz certyfikat TLS wystawiony dla Twojej nazwy hosta, aby przeglądarki widziały zieloną kłódkę zamiast ostrzeżenia.
Elido obsługuje te dwie ostatnie przez usługę walidacji domen, która odpowiada za weryfikację DNS, wystawianie certyfikatów i aktualizowanie tabeli routingu. Steruje automatycznym TLS na żądanie i rozwiązuje mapowanie workspace. Usługa brzegowa - ta z budżetem latencji poniżej 10 ms w regionie - nic nie wie o wystawianiu certyfikatów; wszystko to dzieje się przed ścieżką żądania.
Przepływ weryfikacji jest prosty. Dodajesz CNAME z Twojej subdomeny do b.elido.me (tier Business), następnie dodajesz rekord TXT jak _elido-verify.acme.example.com = "ws_abc123", aby udowodnić, że jesteś właścicielem domeny. Usługa walidacji domen odpytuje rekord TXT, potwierdza go, oznacza domenę jako zweryfikowaną i rejestruje ją do TLS. Pierwsze żądanie HTTPS do acme.example.com wyzwala on-demand TLS issuance - o tym za chwilę.
DNS: CNAME vs ALIAS vs A#
Typ rekordu DNS, którego możesz użyć, zależy od tego, którą subdomenę delegujesz.
CNAME działa dla każdej subdomeny nienapexowej. links.example.com CNAME b.elido.me. to standardowa konfiguracja. RFC 1034 §3.6.2 zabrania rekordów CNAME w wierzchołku strefy (gołe example.com), ponieważ kolidują z rekordami SOA i NS, które muszą tam istnieć. Prawie każdy rejestrator i dostawca DNS to egzekwuje.
Rekordy ALIAS / ANAME to niestandardowe rozszerzenie, które implementuje kilku dostawców DNS (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS) właśnie w celu rozwiązania problemu apex. Zachowują się jak CNAME składniowo, ale resolwują się do rekordów A/AAAA za kulisami, więc serwery nazw dostawcy DNS spłaszczają wyszukiwanie przed jego opublikowaniem. Jeśli absolutnie potrzebujesz, żeby example.com (nie www.example.com) przekierowywało, ALIAS to Twoja jedyna opcja zgodna ze specyfikacją DNS. Sprawdź dokumentację dostawcy DNS - rekordy te nie są interoperacyjne, a nazwa funkcji jest różna.
Rekord A wskazujący bezpośrednio na IP Elido to ostateczność. Adresy IP mogą ulec zmianie, gdy dodamy POP lub ponownie zaadresujemy klaster edge, i nie uważamy IP edge za stabilną powierzchnię API. Jeśli dziś jesteś na rekordzie A, przejdź na CNAME lub ALIAS.
Jeszcze jedna rzecz, którą operatorzy przeoczają: przekierowania apex często kolidują z DNS poczty e-mail. Rekordy MX, _dmarc, _domainkey i SPF TXT wszystkie żyją w apex lub pod nim. ALIAS w apex nie koliduje z nimi - to różne typy rekordów - ale niektóre implementacje ALIAS dostawców DNS mają nieudokumentowane ograniczenia dotyczące współistnienia rekordów apex. Przetestuj to przed wystawieniem na kampanię.
TLS: ACME, limity szybkości i wzorzec wystawiania on-demand#
Każda domena niestandardowa dostaje własny certyfikat. Nie używamy certyfikatów wildcard dla domen najemców, ponieważ wymagają one wyzwania DNS-01 zgodnie z RFC 8555 §8.4, co oznacza, że musielibyśmy kontrolować strefę DNS domeny każdego najemcy - a tego nie robimy. Wyzwania HTTP-01 są prostsze (wymagają jedynie dostępności HTTP) i obejmują certyfikaty per-hostname. Używamy HTTP-01 dla każdej domeny niestandardowej.
Urząd certyfikacji to Let's Encrypt. Ich limity szybkości to główne ograniczenie operacyjne, które musisz zrozumieć: 50 certyfikatów na zarejestrowaną domenę tygodniowo, gdzie "zarejestrowana domena" to eTLD+1 (część tuż nad sufiksem publicznym - example.com dla links.example.com). Duplikaty odnowień certyfikatów nie wliczają się do tego limitu, ale każda nowa domena tak.
Ma to ważną implikację dla platform wielodostępnych. Jeśli pozwolisz wszystkim swoim użytkownikom tworzyć domeny niestandardowe pod *.yourbrand.com, Twój budżet 50 certyfikatów tygodniowo jest współdzielony przez wszystkie te subdomeny yourbrand.com. Przy jakiejkolwiek znaczącej skali trafiasz na ograniczenie. Właściwa architektura - i ta, której Elido używa dla własnych subdomen tierów - polega na tym, że każda zweryfikowana domena niestandardowa najemcy jest subdomeną jego własnej zarejestrowanej domeny (links.example.com), więc limit szybkości obowiązuje per najemca, nie per platforma.
Wystawianie TLS on-demand to sposób, w jaki brzeg obsługuje ten wolumen. Zamiast wcześniej wystawiać certyfikaty dla każdej zweryfikowanej domeny przed przybyciem jakiegokolwiek ruchu, certyfikat jest wystawiany przy pierwszym żądaniu do tej nazwy hosta. Automatyczny TLS na żądanie pyta upstream endpoint (w naszym przypadku usługę walidacji domen), czy nazwa hosta jest dozwolona, przed próbą wystawienia. Jeśli zwróci 200 (domena jest zweryfikowana), brzeg kontynuuje wyzwanie ACME HTTP-01, uzyskuje certyfikat, buforuje go i obsługuje żądanie. Jeśli nazwa hosta jest nieznana, brzeg zwraca alert TLS i połączenie kończy się niepowodzeniem, zanim certyfikat zostanie kiedykolwiek zażądany.
Przepływ ACME zgodnie z RFC 8555:
- Brzeg żąda nowego zamówienia od serwera ACME (Let's Encrypt).
- Let's Encrypt odpowiada wyzwaniem HTTP-01: "umieść token pod adresem
http://acme.example.com/.well-known/acme-challenge/<token>." - Brzeg umieszcza token w swoim wewnętrznym handlerze HTTP i powiadamia Let's Encrypt.
- Let's Encrypt pobiera token przez zwykłe HTTP (port 80), waliduje go i wystawia certyfikat.
- Brzeg przechowuje certyfikat w swojej warstwie storage i obsługuje oryginalne żądanie HTTPS.
Kroki 1–5 dodają latencję do pierwszego żądania z nowo zweryfikowanej domeny, zazwyczaj 1–3 sekund. Każde kolejne żądanie trafia na zbuforowany certyfikat bez żadnych obserwowalnych narzutów.
Wydajność: matematyka TLS handshake#
Gdy certyfikat jest już wystawiony, koszt per żądanie to TLS handshake plus logika przekierowania.
Pełny TLS 1.3 handshake to 1 RTT. Od europejskiego klienta do naszego POP w regionie UE to około 10–20ms w zależności od miasta. Wznowienie sesji TLS 1.3 (bilety lub identyfikatory sesji) sprowadza kolejne połączenia do 0-RTT lub 0.5-RTT dla danych - klient może wysłać dane aplikacji już w pierwszym locie. Dla krótkich linków, gdzie żądanie HTTP jest małe, a odpowiedź to 302 z nagłówkiem Location, wznowione sesje są z perspektywy klienta niemal natychmiastowe.
Algorytm certyfikatu ma znaczenie. Certyfikaty ECDSA P-256 mają podpis o długości około 70 bajtów; certyfikaty RSA-2048 przenoszą około 256 bajtów podpisu plus znacznie większy klucz publiczny. Na wolnym połączeniu mobilnym różnica w bajtach jest zaniedbywalną, ale koszt CPU weryfikacji podpisu RSA nie jest: weryfikacja podpisu RSA-2048 zajmuje około 30–50× więcej cykli CPU niż weryfikacja podpisu ECDSA P-256 przy równoważnym poziomie bezpieczeństwa. Dla edge obsługującego tysiące równoczesnych połączeń ta różnica CPU sumuje się. Elido wystawia P-256 dla wszystkich certyfikatów domen niestandardowych. Analiza Cloudflare dotycząca ECDSA vs RSA w produkcji dochodzi do tego samego wniosku i warto ją przeczytać, jeśli zarządzasz własnym terminowaniem TLS.
Po handshake samo przekierowanie trafia na gorącą ścieżkę: wyszukiwanie w LRU in-process (L1), przejście do pamięci podręcznej w pamięci (L2) jeśli nie znaleziono, przejście do origin przez gRPC w ostateczności. Na trafieniu w cache L1 - co stanowi zdecydowaną większość ruchu, gdy link jest już rozgrzany - przekierowanie resolwuje się poniżej 10 ms w regionie (p50), end-to-end na edge, bez uwzględnienia handshake. Budżet 15ms p95 uwzględnia trafienia L2 i niewielki ułamek zimnego ruchu. W głębokim zanurzeniu w smart linki znajdziesz pełną architekturę cache i mechanikę inwalidacji.
Co psuje się w produkcji#
Konfiguracje domen niestandardowych zawodzą w przewidywalny sposób. Oto trzy, z którymi spotykamy się najczęściej, i co z nimi zrobić.
Opóźnienie propagacji DNS. Dodajesz CNAME, weryfikujesz w panelu, a link wciąż nie resolwuje się dla niektórych użytkowników. Wartości TTL DNS dla wielu stref zarządzanych przez rejestratorów domyślnie wynoszą 3600 sekund - godzina potencjalnej nieaktualności. Status domeny w panelu odzwierciedla to, czy usługa walidacji domen widzi poprawną odpowiedź DNS z regionu UE. Jeśli wyświetla "zweryfikowana", ale użytkownicy gdzie indziej nadal trafiają na stary cel, trafiają na resolver, który zbuforował poprzednią odpowiedź. Nie ma skrótu; czekasz, aż TTL się wyczerpie. Rozwiązanie na następny raz: obniż TTL do 300–600 sekund przed wprowadzeniem zmiany, a następnie przywróć go potem.
Wygasłe lub niedopasowane rekordy CAA. Rekordy Certification Authority Authorization (CAA) informują CA, który z nich jest uprawniony do wystawiania certyfikatów dla domeny. Jeśli Twój administrator DNS poprzednio dodał example.com CAA 0 issue "digicert.com", Let's Encrypt odmówi wystawienia certyfikatu dla links.example.com, ponieważ links.example.com dziedziczy politykę CAA apex. Błąd to urn:ietf:params:acme:error:caa w odpowiedzi ACME; rozwiązanie to dodanie links.example.com CAA 0 issue "letsencrypt.org" (lub usunięcie ograniczenia CAA apex, jeśli jest to odpowiednie dla Twojej polityki bezpieczeństwa). Endpoint statusu usługi walidacji domen zwraca błędy CAA w treści błędu, dzięki czemu możesz diagnozować to bez grzebania w logach brzegu.
Klient usuwa CNAME w trakcie kampanii. To jest ta bolesna sytuacja. Administrator DNS po stronie klienta usuwa lub zmienia CNAME - może w ramach migracji domeny, może przez pomyłkę - i każde przekierowanie z tej domeny niestandardowej zaczyna zawodzić, ponieważ brzeg nie może jej już obsługiwać, lub co gorsza, odnowienie certyfikatu TLS cicho zawodzi w ciągu następnego 60-dniowego okna odnowienia i certyfikat wygasa. Usługa walidacji domen Elido uruchamia okresowe sprawdzenie kondycji DNS dla wszystkich zweryfikowanych domen i oznacza domenę jako degraded, gdy CNAME już nie resolwuje się do oczekiwanego celu. Właściciel workspace otrzymuje powiadomienie; jest 7-dniowy okres karencji przed przeniesieniem domeny do stanu suspended. W trakcie okresu karencji żądania są nadal obsługiwane z ostatniego ważnego certyfikatu. Naprawienie: przywróć CNAME, poczekaj na propagację, a status domeny powróci do aktywnego automatycznie przy następnym cyklu sprawdzenia kondycji (uruchamia się co 15 minut).
Krótkie omówienie krok po kroku#
Oto jak wygląda konfiguracja end-to-end, zaczynając od zera.
Krok 1: Dodaj rekordy DNS. W panelu sterowania dostawcy DNS:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
Wartość ws_01HXK4... to Twój token weryfikacyjny workspace, wyświetlany w panelu w sekcji Ustawienia → Domeny niestandardowe → Dodaj domenę.
Krok 2: Zarejestruj domenę przez API. Możesz to zrobić również w panelu, ale jeśli automatyzujesz konfigurację wielodostępną - na przykład agencja wdrażająca nowego klienta - API jest czystsze:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"hostname": "acme.example.com",
"tier": "business"
}'
Odpowiedź zawiera verification_token i status o wartości pending_verification. Odpytuj GET /v1/workspaces/{id}/domains/{domain_id} lub obserwuj panel, aż status przejdzie na verified.
Krok 3: Pierwsze żądanie wystawia certyfikat. Po zweryfikowaniu każde żądanie HTTPS do acme.example.com wyzwoli on-demand TLS, jeśli certyfikat nie jest jeszcze zbuforowany. To pierwsze żądanie może trwać 2–3 sekundy podczas zakończenia wymiany ACME. Każde kolejne żądanie jest poniżej 15ms w p95.
Krok 4: Twórz linki pod domeną niestandardową. Przekaż domain_id podczas tworzenia linków:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/links \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain_id": 17,
"slug": "spring-launch",
"destination_url": "https://example.com/landing/spring"
}'
Link jest natychmiast dostępny pod adresem https://acme.example.com/spring-launch. Jeśli zarządzasz tą konfiguracją jako infrastruktura-jako-kod, zapoznaj się z artykułem o dostawcy Terraform - elido_custom_domain to źródło danych, które możesz połączyć w łańcuchu z zasobami elido_link.
Kiedy nie używać domeny niestandardowej#
Nie każda sytuacja korzysta z domeny niestandardowej, a jej dodanie wiąże się z kosztami konfiguracji po obu stronach.
Narzędzia wewnętrzne i linki stagingowe. Jeśli krótki link jest klikany wyłącznie przez osoby wewnątrz Twojej firmy - dokumenty wewnętrzne, wskazówniki środowisk stagingowych, zasoby udostępniane przez Slack - domena niestandardowa dodaje narzut zarządzania DNS bez żadnych korzyści dla marki. Użyj workspace na f.elido.me lub s.elido.me i idź dalej.
Jednorazowe linki kampanijne z 48-godzinnym terminem ważności. Same okno propagacji DNS wynosi potencjalnie godzinę. Jeśli Twoja kampania startuje jutro i nie masz jeszcze rekordu DNS, domena niestandardowa to ryzyko. Użyj subdomeny platformy, wyślij kampanię i dodaj domenę niestandardową do roadmapy na następną.
Klienci enterprise z SSO, którzy nie zatwierdzili delegacji subdomeny. W firmach z dojrzałymi postawami bezpieczeństwa IT, delegacja subdomeny do zewnętrznego SaaS wymaga przeglądu bezpieczeństwa - czasem formalnej oceny ryzyka. Przegląd może trwać tygodnie. Jeśli Twój proces zakupowy jest już w długiej kolejce zatwierdzeń, nie blokuj umowy na konfiguracji domeny niestandardowej. Zacznij z domeną platformy; zaoferuj migrację do domeny niestandardowej jako część wdrożenia po sprzedaży. Elido obsługuje migrację domeny bez łamania istniejących linków, a strona rozwiązań dla agencji zawiera więcej informacji na temat konfiguracji white-label, która sprawia, że ta przejście jest płynne.
Domeny niestandardowe są dostępne w planach Business i Enterprise. Tiery Free i Pro używają subdomen dostarczanych przez platformę. Jeśli oceniasz tę funkcję, panel pozwala dodać jedną zweryfikowaną domenę w Pro jako ścieżkę próbną - sprawdź aktualne porównanie planów na stronie cennika pod kątem dokładnego limitu.
Pełny przewodnik konfiguracji, w tym rekomendacje rekordów CAA, dokumentacja API dla wszystkich endpointów domen i schemat odpowiedzi sprawdzenia kondycji domeny, jest dostępny pod adresem /docs/guides/custom-domains. Strona funkcji domen niestandardowych omawia integrację Apple App Site Association i przepływ Universal Link / App Link dla głębokiego linkowania mobilnego z własną domeną.
Marius Voß jest DevRel + edge infra w Elido. Jest właścicielem usług przekierowań brzegowych i walidacji domen.
Powiązane artykuły na blogu#
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie