Een wildcard-domein is een speciaal DNS-record dat fungeert als catch-all voor subdomeinen. Het gebruikt een asterisk (*) als het meest linkse label in een domeinnaam, bijvoorbeeld *.voorbeeld.nl. Wanneer iemand een subdomein bezoekt dat geen specifiek DNS-record heeft, vangt het wildcard-record deze aanvraag op en stuurt het verkeer naar een vooraf bepaald IP-adres.
De werking is eenvoudig. Als je een wildcard A-record aanmaakt voor *.voorbeeld.nl die wijst naar 192.0.2.1, dan zullen willekeurig.voorbeeld.nl, test.voorbeeld.nl, en elke andere niet-gedefinieerde subdomeincombinatie allemaal naar hetzelfde IP-adres verwijzen. Specifieke subdomeinen met hun eigen DNS-records hebben altijd voorrang op het wildcard-record. Als je apart www.voorbeeld.nl hebt geconfigureerd, blijft dat record actief.
Wildcard-domeinen zijn bijzonder populair bij multi-tenant SaaS-applicaties. Platforms zoals WordPress.com en Blogspot gebruiken wildcards om automatisch unieke subdomeinen voor elke gebruiker te creëren (gebruiker.wordpress.com). Ook ontwikkel- en testomgevingen profiteren hiervan. Je kunt onbeperkt staging-subdomeinen aanmaken zonder telkens handmatig DNS-records toe te voegen.
Er zijn wel aandachtspunten. Een wildcard-record geldt alleen voor één niveau. Het wildcard *.voorbeeld.nl vangt wel test.voorbeeld.nl op, maar niet sub.test.voorbeeld.nl. Voor diepere niveaus heb je *.*.voorbeeld.nl nodig. Daarnaast kunnen verkeerd geconfigureerde wildcard-records beveiligingsrisico's opleveren. Ze maken subdomain enumeration gemakkelijker voor aanvallers en kunnen gebruikt worden voor phishing of subdomain takeover aanvallen. Bij KeurigOnline helpen we onze klanten met het veilig configureren van wildcard DNS-records.
Geschiedenis
Wildcard DNS-records werden al in 1987 gespecificeerd in RFC 1034 als onderdeel van de originele DNS-specificatie door Paul Mockapetris. De regels voor wanneer wildcards matchen werden gedefinieerd in dit RFC, maar bleken in de praktijk niet altijd intuïtief voor implementaties.
Omdat de oorspronkelijke specificatie tot incompatibele implementaties leidde, publiceerde de IETF in juli 2006 RFC 4592: "The Role of Wildcards in the Domain Name System". Dit RFC verduidelijkte de bedoeling van wildcard-records en loste onduidelijkheden op in de originele RFC 1034-definitie.
In de vroege jaren van het internet (jaren 80 en 90) werd wildcard DNS relatief weinig gebruikt. Websites bestonden voornamelijk uit statische pagina's met minimale subdomeincomplexiteit. Pas met de opkomst van dynamische webapplicaties en multi-tenant platforms in de jaren 2000 werd het gebruik van wildcard-domeinen gemeengoed. Platforms zoals WordPress.com en Blogger gebruiken wildcards om miljoenen gebruikers hun eigen subdomein te geven.
Belangrijke mijlpalen:
- 1987: Wildcard DNS geïntroduceerd in RFC 1034
- 2006: Verduidelijking in RFC 4592
- 2010s: Wijdverspreide adoptie door SaaS-platforms en cloud providers
Bronnen
Online bronnen:
- IETF (1987) - RFC 1034: Domain Names - Concepts and Facilities
- IETF (2006) - RFC 4592: The Role of Wildcards in the Domain Name System
- Cloudflare - Wildcard DNS Records Documentation
- Wikipedia - Wildcard DNS Record
- Namecheap - How to Set Up a Catch-all (Wildcard) Subdomain
- RunCloud - How to Create Wildcard Subdomain for Unlimited Subsites
Boeken:
- Liu, C. & Albitz, P. (2006) - DNS and BIND, 5th Edition. O'Reilly Media. ISBN: 978-0596100575
- Stevens, W.R. (1994) - TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley. ISBN: 978-0201633467