So sieht die Meldung aus
dns_master_load: example.com.zone:12: example.com: CNAME and other dataHäufige Ursachen
- Ein Hoster oder SaaS-Anbieter verlangt „CNAME auf app.provider.net“, auch für die Hauptdomain.
- Zonen-Editor lehnt den Eintrag ab oder BIND verwirft beim Laden die Zone.
- Ein Anbieter akzeptiert den Eintrag trotzdem – dann fallen MX- oder TXT-Abfragen unvorhersehbar aus.
- Gleichzeitig CNAME und TXT für denselben Subdomain-Namen, z. B. für eine Verifizierung.
Prüfen
- Zonendatei auf Fehler prüfen (BIND)
named-checkzone example.com /etc/bind/db.example.com - Vorhandene Records an der Apex anzeigen
dig example.com CNAME +short; dig example.com SOA +short; dig example.com MX +short - Ziel-IP des Anbieters ermitteln
dig app.provider.net A +short
Lösung
- Für die Hauptdomain A- und AAAA-Records mit den IPs des Anbieters setzen.
- Wenn der DNS-Anbieter es kann: ALIAS-, ANAME- oder CNAME-Flattening statt CNAME verwenden.
- Hauptdomain per HTTP-Weiterleitung auf www umleiten und nur www als CNAME anlegen.
- Auf Subdomains CNAME nie mit anderen Records desselben Namens mischen.
- Nach Änderungen Zone prüfen und TTL bei Umstellungen vorher senken.
Häufige Fragen
Warum funktioniert CNAME bei www, aber nicht bei example.com?
www hat sonst keine Records, ein CNAME ist dort erlaubt. Die Apex braucht immer SOA und NS, und neben einem CNAME darf nichts anderes stehen.
Was macht CNAME-Flattening?
Der DNS-Anbieter löst das Ziel selbst auf und liefert an der Apex A- und AAAA-Records aus. Für Resolver sieht es wie ein normaler A-Record aus.