Rekordy wildcard w DNS: jak działa *.example.com

Średniozaawansowany⏱ 4 min czytaniaZaktualizowano 13 października 2026

Rekord o nazwie *.example.com odpowiada za każdą subdomenę, której nigdy nie utworzyłeś: blog, test, cokolwiek. Dzięki temu subdomena dla każdego klienta czy środowiska podglądowe to jedna linijka. Ale dzięki temu działają też literówki, poczta trafia do hostów, które nie istnieją, a zapomnianą subdomenę może przejąć ktoś inny. Zasady tego, co dopasowuje gwiazdka, są ostrzejsze, niż większość osób zakłada.

Jak odpowiada wildcard

Resolwer pyta o nazwę. Jeśli w strefie takiej nazwy nie ma, serwer szuka rekordu * przy najbliższej nazwie, która istnieje, i odpowiada tak, jakby rekord był zapisany dla pytanej nazwy (RFC 4592). Weźmy taką strefę:

; zone example.com
example.com.        3600 IN A      203.0.113.10
www.example.com.    3600 IN CNAME  example.com.
shop.example.com.   3600 IN A      203.0.113.20
*.example.com.      3600 IN A      203.0.113.80

Z *.example.com w strefie: istniejąca nazwa zachowuje własny rekord, brakująca dostaje wildcard, a nazwa pod istniejącą nie dostaje nic.

Zapytanie	Odpowiedź	Dlaczego
`example.com` `A`	`203.0.113.10`	Apex nigdy nie jest dopasowywany przez `*.example.com`.
`shop.example.com` `A`	`203.0.113.20`	Nazwa istnieje, więc wildcard jest pomijany.
`blog.example.com` `A`	`203.0.113.80`	Takiej nazwy nie ma: odpowiedź powstaje z `*`.
`a.b.example.com` `A`	`203.0.113.80`	Nie istnieje ani `b`, ani `a.b`, więc dopasowanie działa — przez dowolną liczbę etykiet.
`shop.example.com` `MX`	Brak rekordów (NODATA)	Nazwa istnieje. Wildcard nigdy nie dodaje typów, których brakuje prawdziwej nazwie.
`x.shop.example.com` `A`	NXDOMAIN	Najbliższa istniejąca nazwa to `shop`, a `*.shop.example.com` nie ma.

Zasady, które zaskakują

Istniejących nazw wildcard nie dotyka. Jeśli www ma tylko CNAME, zapytanie o TXT dla www nie dostanie nic z * — nawet jeśli wildcard ma rekord TXT.
Nazwa „istnieje” także bez własnych rekordów, gdy coś jest pod nią. Utwórz api.dev.example.com, a dev.example.com zaczyna istnieć: test.dev.example.com nie trafia już do *.example.com.
Gwiazdka działa tylko jako cała skrajnie lewa etykieta. *.example.com to wildcard; www.*.example.com, *-dev.example.com i *abc.example.com to zwykłe, dosłowne nazwy.
Wildcard CNAME jest dozwolony, ale jak każdy CNAME nie może dzielić nazwy z innymi rekordami — *.example.com CNAME plus *.example.com MX to błąd.
Odpowiedź niesie pytaną nazwę, a nie *. Klient nie odróżni odpowiedzi z wildcarda od prawdziwego rekordu; zdradza go dopiero porównanie z losową nazwą.

Uwaga: Certyfikat TLS typu wildcard to inna rzecz z inną zasadą: certyfikat dla *.example.com obejmuje blog.example.com, ale nie a.b.example.com ani samo example.com. To, że wildcard DNS rozwiązuje głębsze nazwy, nie sprawia, że certyfikat je obejmuje.

Kiedy wildcard to dobre narzędzie

SaaS z subdomeną dla każdego klienta (acme.app.example): nowi klienci działają od razu, a aplikacja po nagłówku Host decyduje, którą instancję pokazać.
Środowiska podglądowe i gałęziowe tworzone i usuwane automatycznie, obsługiwane przez jeden load balancer.
Przekierowanie „łap wszystko”, które kieruje każdą błędnie wpisaną subdomenę na główną stronę — jeśli akceptujesz skutki uboczne opisane niżej.

Ryzyka

Literówki wyglądają na sukces. ww.example.com czy mial.example.com się rozwiązują i trafiają na serwer, który może pokazać mylącą stronę zamiast jasnego błędu.
Poczta. Wildcard MX robi z każdej wymyślonej subdomeny poprawny adres docelowy poczty, co spamerzy zauważają; wildcard A bez żadnego MX robi to samo przez awaryjne użycie rekordu A. Jeśli wildcard jest tylko dla WWW, opublikuj na nim null MX i ścisły SPF.
Przejęcie subdomeny. Wildcard CNAME do usługi chmurowej (*.example.com → example.azurewebsites.net) oddaje każdą nieużywaną subdomenę temu, kto zarejestruje ten cel po Twoim odejściu z usługi.
Ukryte błędy. Usunięty rekord dalej „działa” przez wildcard, więc nieudana migracja może przejść niezauważona — aż do usunięcia wildcarda.

; keep a web wildcard from inviting mail to every subdomain
*.example.com.  3600 IN MX   0 .              ; RFC 7505 "null MX"
*.example.com.  3600 IN TXT  "v=spf1 -all"

Ostrożnie: Zanim dodasz wildcard do domeny, która wysyła pocztę lub służy do logowania, zapisz, które subdomeny nie mogą się rozwiązywać, i sprawdź je po zmianie.

Jak sprawdzić, czy domena ma wildcard

Zapytaj o nazwę, której nikt by nie utworzył. Jeśli się rozwiązuje, jest wildcard (albo CDN lub dostawca DNS, który syntetyzuje odpowiedzi). Potem porównaj z prawdziwą subdomeną:

# a label that surely does not exist — answered by the wildcard?
dig +short pixdns-test-7f3a.example.com A
# compare with a name that does exist
dig +short shop.example.com A

Wskazówka: Wklej losową nazwę do wyszukiwarki DNS PixDNS, żeby zobaczyć typ rekordu i TTL, które zwraca wildcard. Narzędzia do enumeracji subdomen odfiltrowują odpowiedzi wildcard tak samo: najpierw rozwiązują losową etykietę i odrzucają wszystko, co do niej pasuje.

Sprawdź losową subdomenę →Dalej: rekordy CNAME →

Najczęstsze pytania

Czy *.example.com obejmuje example.com?

Nie. Wildcard dopasowuje nazwy pod domeną, nigdy samą domenę. Dla apexu trzymaj osobny rekord.

Czy *.example.com obejmuje a.b.example.com?

W DNS tak — o ile b.example.com nie istnieje. Certyfikat TLS typu wildcard obejmuje natomiast tylko jeden poziom.

Dlaczego wildcard nie działa dla jednej subdomeny?

Bo ta nazwa albo nazwa pod nią istnieje w strefie. Istniejąca nazwa nigdy nie dostaje odpowiedzi z wildcarda, nawet dla typów rekordów, których nie ma.

Czy mogę użyć wildcarda dla MX lub TXT?

Tak, wildcardem może być każdy typ rekordu. Wildcard MX rzadko jest dobrym pomysłem; wildcard null MX i v=spf1 -all to popularne zabezpieczenie.

Wypróbuj na swojej domenie

Zobacz teorię w praktyce — uruchom Sprawdzanie DNS dla własnej domeny.

Zaktualizowano 13 października 2026

Źródła