Wildcard-DNS: ein Eintrag für alle Subdomains

Ein Wildcard-Eintrag ist ein DNS-Eintrag, dessen Name mit einem Sternchen beginnt, etwa *.beispiel.de. Er dient als Ersatzantwort für Namen, die in der Zone sonst nicht vorkommen. Fragt jemand nach kunde17.beispiel.de und gibt es dafür keinen eigenen Eintrag, antwortet der Nameserver mit den Daten des Platzhalters. Die Regeln dafür stehen schon in RFC 1034 von 1987 ^[1]. RFC 4592 hat sie 2006 genauer gefasst, weil Nameserver sie unterschiedlich umgesetzt hatten ^[2].

So sieht ein Wildcard-Eintrag aus

Als Platzhalter gilt nur ein Name, dessen erstes Label genau ein einzelnes Sternchen ist. Ein Sternchen an anderer Stelle, etwa in sub.*.beispiel.de, ist ein gewöhnliches Zeichen und kein Platzhalter ^[2]. Eine kleine Zone mit Wildcard könnte so aussehen:

Eine Anfrage nach shop.beispiel.de oder test.beispiel.de bekommt hier die Adresse 192.0.2.20. Für www.beispiel.de und mail.beispiel.de gelten ihre eigenen Einträge. Der Nameserver erzeugt die Antwort für shop.beispiel.de so, als stünde dort ein eigener Eintrag mit dem abgefragten Namen. RFC 4592 nennt das Synthese ^[2].

Wann der Platzhalter greift und wann nicht

Die Grundregel lautet: Ein Wildcard antwortet nur für Namen, die in der Zone nicht existieren. RFC 1034 formuliert es umgekehrt. Der Platzhalter gilt nicht, wenn der gesuchte Name oder ein Name zwischen ihm und dem Wildcard bekannt ist ^[1]. Das hat zwei Folgen, die in der Praxis oft überraschen.

Ein eigener Eintrag schaltet den Wildcard für diesen Namen ab

Legst du für mail.beispiel.de einen A-Eintrag an, existiert der Name. Fragt dann jemand nach einem MX- oder TXT-Eintrag für mail.beispiel.de, bekommt er keine Antwort aus dem Wildcard, auch wenn dort ein MX steht. Der Name hat dann einfach keine Daten dieses Typs. RFC 4592 zeigt das an einem Beispiel: Für einen Namen, der im Wildcard nur einen MX und einen TXT findet, liefert eine Frage nach einer IPv4-Adresse eine leere Antwort ohne Fehler ^[2].

Auch ein Name ohne eigene Daten blockiert den Wildcard

Der zweite Fall ist tückischer. Ein Name gilt auch dann als vorhanden, wenn er selbst keine Einträge hat, aber unter ihm etwas steht. RFC 4592 nennt solche Knoten "empty non-terminals" ^[2]. Ein typisches Beispiel: Du hast nur den Wildcard *.beispiel.de und legst für ein Zertifikat den TXT-Eintrag _acme-challenge.shop.beispiel.de an. Ab diesem Moment existiert shop.beispiel.de als leerer Knoten. Der Wildcard greift für shop.beispiel.de nicht mehr, und der Shop ist über diesen Namen nicht mehr erreichbar, bis du ihm einen eigenen A-Eintrag gibst.

Welche Anfrage welche Antwort bekommt

Für die Beispielzone oben ergibt sich daraus folgendes Bild. Angenommen ist, dass zusätzlich ein TXT-Eintrag unter _acme-challenge.shop.beispiel.de steht:

Wie tief das Sternchen reicht

Im DNS reicht *.beispiel.de über mehrere Ebenen: Es beantwortet auch Anfragen nach a.b.beispiel.de, solange weder b.beispiel.de noch a.b.beispiel.de in der Zone existieren. RFC 4592 zeigt das an foo.bar.example, das aus dem Wildcard beantwortet wird, weil bar.example nicht existiert ^[2]. Cloudflare beschreibt dasselbe Verhalten für seine Nameserver: *.example.com deckt auch tiefere Namen wie 123.abc.example.com ab, solange kein genauerer Eintrag Vorrang hat ^[3].

Begrenzt wird der Wildcard durch vorhandene Zwischennamen. Ist ein solcher Name vorhanden, etwa weil b.beispiel.de einen eigenen Eintrag hat, dann gilt *.beispiel.de für alles darunter nicht mehr. Wer dort ebenfalls einen Platzhalter will, legt *.b.beispiel.de an ^[2]. Auch delegierte Subdomains, deren Zone auf anderen Nameservern liegt, sind vom Wildcard der übergeordneten Zone nicht erfasst ^[2].

Wofür sich ein Wildcard-Eintrag eignet

Sinnvoll ist ein Wildcard, wenn viele Subdomains auf denselben Server zeigen und der Server selbst entscheidet, was er unter welchem Namen ausliefert. Typische Fälle sind:

• Plattformen, bei denen jeder Kunde eine eigene Subdomain bekommt, etwa kunde1.app.beispiel.de und kunde2.app.beispiel.de.
• Vorschau- und Testumgebungen, die automatisch Namen wie pr-123.dev.beispiel.de erzeugen.
• Websites mit vielen Themen-Subdomains, bei denen neue Bereiche ohne Änderung am DNS online gehen sollen.

In allen drei Fällen spart der Wildcard die Pflege einzelner Einträge. Der Webserver muss dafür aber mit beliebigen Hostnamen umgehen können. Grundlagen zu Subdomains erklärt Was ist eine Subdomain?, die Einrichtung mit Webserver und Zertifikat Subdomain einrichten.

Weniger geeignet ist ein Wildcard, wenn du nur eine Handvoll Subdomains hast. Dann sind einzelne Einträge übersichtlicher, und Tippfehler in Adressen führen nicht still auf deinen Server.

Wildcard-DNS und Zertifikat

Damit Besucher die Subdomains über HTTPS erreichen, braucht jeder Name ein passendes Zertifikat. Ein Wildcard-Zertifikat für *.beispiel.de folgt strengeren Regeln als der DNS-Eintrag: Das Sternchen darf nur das ganze erste Label bilden und passt auf genau ein Label ^[4]. *.beispiel.de deckt also shop.beispiel.de ab, nicht aber a.b.beispiel.de und auch nicht beispiel.de selbst. Für die Hauptdomain trägst du deshalb einen zweiten Namen ins Zertifikat ein.

Let's Encrypt stellt Wildcard-Zertifikate kostenlos aus, aber nur über die Prüfung per DNS (DNS-01). Die Prüfung per HTTP (HTTP-01) ist dafür ausgeschlossen ^[5]. Bei DNS-01 legt dein ACME-Programm einen TXT-Eintrag unter _acme-challenge.beispiel.de an ^[5]. Let's Encrypt rät, diese Methode nur zu nutzen, wenn dein DNS-Anbieter eine Schnittstelle zum automatischen Ändern der Einträge hat. Gleichzeitig weist Let's Encrypt darauf hin, dass Zugangsdaten für diese Schnittstelle auf dem Webserver ein Risiko sind ^[5]. Ob ein Wildcard-Zertifikat oder mehrere einzelne Zertifikate besser passen, vergleicht SSL für Subdomains: Wildcard oder einzelne Zertifikate.

Risiken und Sonderfälle

Mit einem Wildcard löst jeder erfundene Name unter deiner Domain auf. Wer sich bei einer Subdomain vertippt, landet trotzdem auf deinem Server statt auf einer Fehlermeldung. Der Webserver sollte deshalb nur Hostnamen bedienen, die er kennt, und alle anderen abweisen oder auf eine Standardseite leiten.

Für einige Eintragstypen gelten besondere Regeln:

• CNAME als Wildcard ist erlaubt. Der Nameserver gibt den Alias mit dem abgefragten Namen zurück, danach folgt die Suche dem Ziel wie bei jedem CNAME ^[2]. Was ein CNAME sonst ausschließt, steht unter CNAME-Eintrag: wann er passt und wann nicht.
• MX als Wildcard funktioniert ebenfalls und leitet Mail an beliebige Subdomains an denselben Server ^[2]. Das ist selten gewollt, weil dann auch Mail an erfundene Subdomains angenommen werden muss oder abgewiesen wird.
• NS-Einträge als Wildcard rät RFC 4592 ab, verbietet sie aber nicht ^[2].

Wer seine Zone über ein CDN wie Cloudflare führt, kann Wildcard-Einträge dort in allen Tarifen anlegen und auch über den Proxy leiten. Bei einer Einrichtung nur per CNAME, ohne die Nameserver zu wechseln, stellt Cloudflare für Wildcard-Einträge aber nicht automatisch Zertifikate aus ^[3]. Mehr zum Anbieter steht unter Cloudflare: Funktionen, Tarife und Datenschutz.

Wildcard einrichten und prüfen

In den meisten DNS-Oberflächen trägst du als Namen nur das Sternchen ein, die Domain ergänzt die Oberfläche selbst. So gehst du vor:

1. Lege einen A-Eintrag mit dem Namen * und der IPv4-Adresse deines Servers an, bei IPv6 zusätzlich einen AAAA-Eintrag.
2. Prüfe, welche Subdomains schon eigene Einträge haben. Für sie gilt der Wildcard nicht.
3. Richte den Webserver so ein, dass er Anfragen für beliebige Subdomains annimmt und unbekannte Namen abweist.
4. Beantrage ein Wildcard-Zertifikat für *.beispiel.de und beispiel.de über DNS-01.
5. Frag mit dem DNS-Check eine erfundene Subdomain ab, etwa test123.beispiel.de. Kommt die Adresse des Servers zurück, funktioniert der Wildcard.

Welche Subdomains deiner Domain öffentlich bekannt sind, etwa aus ausgestellten Zertifikaten, zeigt der Subdomain-Finder. Damit siehst du auch, ob alte Namen noch auf Dienste zeigen, die es nicht mehr gibt.

Bis ein neuer Eintrag überall ankommt, kann es je nach TTL eine Weile dauern. Warum, erklärt DNS-Änderung: wie lange dauert es, bis sie überall gilt?.

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities, Abschnitt 4.3.3. IETF, P. Mockapetris. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 4592: The Role of Wildcards in the Domain Name System. IETF, E. Lewis. Stand Juli 2006. abgerufen am 29.10.2026
3. Organisation Wildcard DNS records. Cloudflare. Stand 16.04.2026. abgerufen am 29.10.2026
4. Gesetz RFC 9525: Service Identity in TLS, Abschnitt 6.3. IETF. Stand November 2023. abgerufen am 29.10.2026
5. Organisation Challenge Types. Let's Encrypt. Stand 12.02.2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.