Gdy Twój domena staje się placem zabaw dla nieznajomych: wildcard DNS i GitHub Pages

Podróżujesz po Afryce, internet ledwo działa. Nagle przychodzi mail z Google Search Console. Ktoś inny właśnie „przejął” subdomenę na Twojej domenie.

Panika.

To nie jest teoretyczna historia. Dokładnie tak stało się z jednym deweloperem, który trzymał na GitHub Pages statyczną stronę do wizualizacji chmur punktów 3D. Gdy był offline, ktoś cicho przejął kontrolę nad subdomeną kafka.immersivepoints.com i zaczął hostować na niej swoje treści. O sprawie dowiedział się dopiero po kilku tygodniach.

Jak to się zaczęło: wygoda ponad wszystko

GitHub Pages to świetne rozwiązanie. Zero konfiguracji serwera, prosta konfiguracja DNS i strona działa. Wielu deweloperów właśnie tak robi – tworzy wildcard DNS (*.immersivepoints.com), kieruje go na IP GitHuba i zapomina o sprawie.

Założenie było proste: „Skoro ja jestem właścicielem domeny, to tylko ja mogę tworzyć subdomeny”. Niestety, GitHub Pages nie działa w ten sposób.

Dlaczego to zadziałało: brak weryfikacji

Największy problem polega na tym, że GitHub nie sprawdza, czy osoba dodająca plik CNAME naprawdę ma prawa do danej domeny. Wystarczy, że rekord DNS wskazuje na serwery GitHuba – i gotowe.

W tym przypadku ktoś inny stworzył repozytorium, dodał plik CNAME wskazujący na kafka.immersivepoints.com, i GitHub zaczął serwować jego treści z tej subdomeny. Co więcej – repozytorium było prywatne, więc trudno było nawet wykryć problem.

Wildcard DNS bez zabezpieczeń

Wildcard DNS sam w sobie nie jest problemem. Tylko gdy połączysz go z tak leniwą polityką GitHuba, powstaje niebezpieczna kombinacja. Każdy użytkownik GitHuba – nawet bez weryfikacji domeny – mógł w teorii „przejąć” subdomenę z Twojej domeny.

Innymi językiem, wildcard DNS działa jak master key dla wszystkich subdomen. Gdy ktoś misternie użył tej luki, na kafka.immersivepoints.com pojawiły się strony z slotami – dokładnie tego, co Google nie lubi.

Tylko dzięki monitorowaniu się dowiedział

Dezaktywowałby się tylko dzięki Google Search Console. Bez tego, scam mógłby działać tygodniami lub months – Google nadal indeksowałby treści na Twojej domenie.

Tłumaczy to jeden ważny fakt: monitorowanie to nie tylko narzędzie do optymalizacji, ale przede wszystkim do bezpieczeństwa.

Co GitHub mógłby zrobić lepiej

GitHub oferuje weryfikację domeny, ale znajduje się ona w ustawieniach konta, co nie jest widoczne dla większości użytkowników. Gdy бы developer znalazł ją wcześniej, mógłby zapobiec hijackingowi.

GitHub powinien:

1. Dawać wyraźne ostrzeżenia w ustawieniach repozytorium, gdy domena nie została weryfikowana
2. Wymagać weryfikacji przed wbudowaniem CNAME
3. Wprowadzić mechanizm DNS TXT jako potwierdzenie własności

Jak się chronić

Jeśli użyłeś GitHub Pages na custom domain, warto:

• Unikać wildcard DNS – lepiej dodawać konkretne rekordy A lub CNAME dla każdej subdomeny, zamiast całego gniazda
• Weryfikować domenę w ustawieniach konta GitHuba
• Używać DNS TXT jako dodatkowego zabezpieczenia
• Monitorować z Google Search Console lub Bing Webmaster Tools – ustaw alerty dla nowych indeksowanych stron
• Regularnie przeglądać konfigurację GitHub Pages – sprawdować, które repozytorium odnajdują CNAME
• Rozważyć nie używanie GitHub Pages dla krytycznych projektów – wtedy samostanowienie lub специализированный hosting może być lepszy

Podsumowanie

Wildcard DNS to wygodna konfiguracja, ale bez weryfikacji własności staje sich zu einer potężną luką. W przypadku GitHub Pages, to nie tylko techniczny błąd – to także UX problem. Weryfikacja powinna być widoczna i łatwa,而不是 ukryta.

Z ochroną możesz zapobiec hijackingowi.