Eine praktische Erfindung sind DNS-Wildcard-Einträge, um z.B. bei einer Domain nicht alle Subdomains manuell konfigurieren zu müssen. Aber es gibt dabei Stolperfallen, in die auch erfahrene Sysadmins manchmal tappen.
Kurz zu den Grundlagen: Eine Zeile des Zonefiles besteht aus folgenden Teilen:
- name, z.B. www
- ttl, z.B. 300
- class, z.B. IN
- rr, z.B. A
- type-specific-data, z.B. 192.0.2.1
Nun kann man für name auch Wildcards benutzen, also z.B. solche Einträge machen, ein Beispiel-Zonefile wäre:
example.com IN MX 10 mail.example.com. *.example.com IN MX 10 mail.example.com. mail.example.com IN A 192.0.2.1 *.example.com IN A 192.0.2.2 *.demo.example.com IN A 192.0.2.3
Soweit ist alles klar. Ruft jemand im Browser kunde1.example.com auf, landet er auf 192.0.2.2, bei kunde1.demo.example.com auf 192.0.2.3, und alle E-Mails an info@kunde1.example.com werden über mail.example.com zugestellt. Aber was ist mit Mails an info@kunde1.demo.example.com?
Jetzt kommt das überraschende: Der MX-Eintrag *.example.com greift hier nicht. Warum? Nun, es wird der spezifischere Eintrag *.demo.example.com gefunden, für den es nur einen A-Record gibt. Sollen auch Mails an *.demo.example.com zugestellt werden, muß auch hierfür ein MX-Eintrag angelegt werden.
Und noch eine Stolperfalle: Gibt es eine zweite Sammel-Subdomain prod.example.com funktioniert dies mit der oben genannten Konfiguration, und kunde1.prod.example.com zeigt auf 192.0.2.2 – solange, bis jemand auf die Idee kommt für kunde2.prod.example.com ein SSL-Zertifikat zu benötigen und dieses auf 192.0.2.4 zu installieren.
Jetzt funktioniert plötzlich kunde1.prod.example.com nicht mehr – denn es gibt ja jetzt explizit prod.example.com, mit einem einzigen Eintrag: kunde2. Und kunde1 guckt in die Röhre. Also muß das Zonefile um die folgenden Einträge erweitert werden:
*.prod.example.com IN A 192.0.2.2 kunde2.prod.example.com IN A 192.0.2.3 *.prod.example.com IN MX 10 mail.example.com. *.demo.example.com IN MX 10 mail.example.com.
Details finden sich in rfc1034 Abschnitt 4.3.3.
