Web Hosting

All-Inkl DNS-Verwaltung – Tipps für optimale Konfiguration

All-Inkl DNS steuert, wohin deine Domain zeigt, wie schnell Inhalte laden und ob E-Mails zuverlässig ankommen. Ich zeige dir, wie du im KAS die richtigen Records setzt, Konflikte vermeidest und deine Domain mit Sicherheit und Tempo betreibst.

Zentrale Punkte

KAS-Zugang zügig nutzen und Einträge sauber pflegen
TTL strategisch setzen für schnelle Updates
MX/SPF/DKIM korrekt konfigurieren für Mail-Trust
Wildcard und Subdomains sinnvoll einsetzen
Monitoring und Dokumentation konsequent führen

All-Inkl DNS im KAS: schneller Einstieg

Ich melde mich im Membersbereich an, öffne die technische Verwaltung und gehe per KAS-Login zur gewünschten Domain, dann zu DNS-Einstellungen [1]. In der Übersicht prüfe ich vorhandene A-, AAAA-, CNAME-, MX- und TXT-Records und räume Doppelungen auf. Für einen Serverwechsel passe ich A (IPv4) und gegebenenfalls AAAA (IPv6) an und speichere die neue IP. Änderungen greifen oft in Minuten, weltweit kann es länger dauern. Nach jedem Speichern kontrolliere ich die Einträge erneut, damit kein Tippfehler den Go-Live stoppt.

TTL, Propagation und saubere Deployments

Ich behandle die TTL als Steuerhebel für Rollouts. Vor einem Umzug senke ich die TTL temporär (z. B. auf 300 Sekunden), damit Clients neue Werte rasch übernehmen. Nach dem Wechsel hebe ich die TTL wieder an, um DNS-Last zu reduzieren. Für kritische Launches plane ich das Zeitfenster, lösche veraltete Records und teste die Auflösung mehrerer Resolver. Einen tieferen Vergleich zu sinnvollen Werten findest du hier: optimale TTL Werte.

Nameserver, NS und SOA im Blick

Ich prüfe zuerst, wer die autoritativen Nameserver stellt. Sind die NS bei All-Inkl delegiert, wirken meine KAS-Einträge sofort. Sind externe Nameserver hinterlegt (z. B. eines CDN oder eines SaaS-Anbieters), greifen die KAS-Records nicht. Dann pflege ich die Zone dort, wo die NS zeigen. Beim Wechsel der Nameserver plane ich mehr Zeit ein als bei einzelnen Record-Updates, weil TLD-Registrar und Caches den Delegationswechsel verzögert übernehmen können.

Im SOA-Record beachte ich die Parameter: Serial (Versionsnummer der Zone), Refresh/Retry/Expire (Steuerung für Secondary-Server) und die Negative TTL für nicht vorhandene Namen. Diese negative Cache-Dauer erklärt, warum gelöschte/neu angelegte Namen manchmal erst nach Ablauf der NXDOMAIN-TTL sichtbar werden. Die meisten Werte verwaltet All-Inkl automatisch – ich kalkuliere sie aber in die Rollout-Zeit mit ein.

A-, AAAA- und CNAME korrekt setzen

Für die Website trage ich die neue IPv4 unter A und die IPv6 unter AAAA ein, damit alle Clients einen Zugriff bekommen. Weist ein Dienst mir nur einen Hostnamen zu, nutze ich CNAME als Alias auf diesen Ziel-Host [2]. Ich vermeide CNAME auf der Root-Domain, außer der Anbieter unterstützt spezielle Lösungen; stattdessen arbeite ich dort meist mit A/AAAA. Für www lege ich einen CNAME auf die Root an, wenn ich zentrale IPs vermeiden will. Nach Updates prüfe ich Auflösung und Zertifikat, damit HTTPS ohne Warnungen läuft.

Weiterleitungen, WWW-Kanonisierung und CNAME-Fallen

Ich unterscheide strikt zwischen DNS und HTTP: Weiterleitungen (z. B. non-www ⇒ www) löse ich serverseitig mit 301/308, nicht mit DNS. Im DNS verweise ich www typischerweise per CNAME auf die Root (oder direkt auf das Ziel beim CDN). Ich lege keinen CNAME dort an, wo es schon andere Records gleichen Namens gibt (z. B. MX/TXT auf Root), da CNAME und andere Typen sich aus schließen. Für saubere Zertifikate sichere ich ab, dass alle genutzten Hostnamen (Root, www, applikationsspezifisch) aufgelöst und im Zertifikat enthalten sind.

Subdomains und Wildcards sinnvoll nutzen

Ich lege Subdomains wie shop, blog oder api an und trenne so Dienste sauber, ohne die Hauptdomain zu gefährden. Für häufig wechselnde Projekte nutzt mir ein Wildcard-A-Record (*) Zeit, weil jede neue Subdomain automatisch erreichbar ist. Kritische Subdomains definiere ich trotzdem explizit, damit sie eigene Ziele, TTLs oder Sicherheitswerte bekommen. Für externe Plattformen setze ich CNAME-Einträge, damit sich IP-Änderungen des Anbieters nicht auf mich auswirken. Vor Live-Stellung teste ich die Subdomain per Hosts-Datei oder separatem Resolver.

CDN, Multi-Region und Failover

Ich binde ein CDN über CNAME ein und halte die TTL moderat, damit Routing-Änderungen zügig greifen. Für statische Inhalte lohnt eine Subdomain (z. B. static), damit ich Caching-Policies und Zertifikate getrennt verwalte. Bei einfachem Lastenausgleich arbeite ich mit mehreren A/AAAA-Einträgen (Round-Robin). Mir ist bewusst, dass das keine aktiven Healthchecks ersetzt – fällt ein Ziel aus, müssen Nutzer warten, bis der Client ein anderes Ziel versucht. Für geplante Wartungen nutze ich kurze TTLs und wechsle auf eine Maintenance-Instanz oder lenke Traffic via CNAME-Switch um.

MX, SPF, DKIM, DMARC: E-Mail zuverlässig absichern

Ich setze korrekte MX-Records, damit Mails den vorgesehenen Server erreichen und Kommunikationspartner Vertrauen aufbauen. Für Absenderauthentifizierung lege ich per TXT einen SPF-Record an, der alle legitimen Versandpfade umfasst [3]. Zusätzlich aktiviere ich DKIM, damit Empfänger Signaturen prüfen können; den Public Key hinterlege ich als TXT. Mit DMARC definiere ich die Auswertung von SPF/DKIM und eine Policy (none/quarantine/reject) samt Reporting. Danach teste ich Zustellung, Spam-Bewertung und Alignment, bis die Werte stimmen.

SPF-Details aus der Praxis

Ich halte den SPF auf eine einzige TXT-Zeile je Name und beachte das Lookup-Limit (max. ~10 Mechanismen mit DNS-Abfragen). Zu viele include-Ketten kürze ich oder konsolidiere sie.
Ich nutze ip4/ip6 für eigene Absender, include für Anbieter und vermeide teure Mechanismen wie ptr. Am Ende setze ich meist ~all (softfail) zum Start und später -all.
Bei langen Werten achte ich auf korrektes Quoting. TXT darf in Segmente gebrochen werden, die Resolver wieder zusammenführen.

DKIM sauber betreiben

Ich verwalte Selectoren (z. B. s2025) pro Versandpfad, damit ich Schlüssel rotieren kann, ohne den Versand zu stoppen.
Ich bevorzuge 2048-Bit-Schlüssel und lösche alte Selector-TXT-Records nach der Umstellung.
Pro Absender-Plattform nutze ich eigene Selector, damit Test und Rollback getrennt bleiben.

DMARC-Policies entwickeln

Ich starte mit p=none und Auswertung der Berichte (rua). Stimmen SPF/DKIM-Aligmentwerte, gehe ich über quarantine zu reject und erhöhe ggf. pct stufenweise.
Ich setze bei Bedarf eine sp=-Policy für Subdomains und wähle adkim/aspf (relaxed/strict) passend zum Setup.

Weitere Mail-Aspekte

Reverse DNS (PTR): Sende ich Mails von einer eigenen IP, stelle ich beim Anbieter einen PTR auf den HELO-/SMTP-Namen ein. Ohne PTR sinkt die Zustellqualität.
MTA-STS/TLS-RPT: Ich sichere Transportverschlüsselung zusätzlich per MTA-STS (Policy per TXT/HTTPS) und lasse Zustellprobleme via TLS-RPT melden.

Fehlerquellen vermeiden und schnell beheben

Ich sehe oft banale Ursachen: vertauschte Zahlen in IPs, doppelte Records, falsch gesetzte CNAME-Ziele oder TXT-Zeilenumbrüche. Deshalb kontrolliere ich jeden neuen Eintrag direkt im KAS und validiere anschließend mit mehreren Resolvern. Bei Störungen starte ich mit A/AAAA und MX, prüfe dann CNAME/TXT und schaue mir die TTL an. Für strukturierte Analysen nutze ich Checklisten und Tools; ein guter Einstieg ist diese kompakte DNS-Fehleranalyse. Wenn es trotzdem hakt, öffne ich ein Ticket mit Zeitpunkten, betroffenen Hosts und Samples.

DNS-Records im Überblick: Praxis-Tabelle

Ich behalte die wichtigsten Record-Typen in einer kompakten Übersicht, damit ich Änderungen schnell und sicher plane. Für Webzugriffe nutze ich A/AAAA, für Aliase CNAME, für Mails MX und für Authentifizierung TXT. SRV hilft bei Diensten wie VoIP oder Chat. Bei jedem Eintrag beachte ich Format, Name, Ziel und TTL. Die folgende Tabelle unterstützt dich bei der Planung deiner Einträge.

Record	Zweck	Beispiel-Eintrag	Hinweise
A	IPv4-Adresse der Domain	192.0.2.123	Für Website und Subdomains wichtig
AAAA	IPv6-Adresse der Domain	2001:0db8:85a3:0000:0000:8a2e:0370:7334	Immer zusätzlich pflegen, wenn möglich
CNAME	Alias auf andere Domain	www ⇒ meinedomain.de	Kein CNAME auf Root einsetzen
MX	Mailserver-Zuweisung	mailserver.webhoster.de	Mehrere Einträge mit Priorität
TXT	Verifizierung/Policies	v=spf1 include:…	SPF, DKIM, DMARC hinterlegen
SRV	Dienste-Zuweisung (z. B. VoIP)	_sip._tcp.meinedomain.de	Nur bei Bedarf verwenden

SRV, CAA, TLSA und Sonderfälle

Ich nutze SRV-Einträge für Dienste, die Port, Gewichtung und Priorität benötigen (z. B. _sip._tcp, _xmpp, _autodiscover). Dabei setze ich Service, Protokoll, Zielhost, Port, Priorität und Gewicht korrekt und dokumentiere Abhängigkeiten.

Für Zertifikate schränke ich mit CAA ein, welche CAs Zertifikate ausstellen dürfen. Ich setze Einträge vom Typ issue (normale Zertifikate), issuewild (Wildcard) und optional iodef für Benachrichtigungen. So verhindere ich ungewollte Ausstellungen. Nutze ich DNSSEC, kann ich für TLS-Dienste TLSA (DANE) in Erwägung ziehen – das ist fortgeschritten, erhöht aber die Kettensicherheit zwischen DNS und Transportverschlüsselung.

ACME/Let’s Encrypt per DNS-01

Ich löse knifflige Zertifikatsszenarien (z. B. Wildcards) über die ACME-Challenge DNS-01. Dafür lege ich einen TXT-Record unter _acme-challenge.deinedomain.tld an. Während der Ausstellung setze ich die TTL kurz, damit die CA die Werte schnell sieht. Nach erfolgreicher Validierung stelle ich die TTL wieder hoch und entferne alte Challenge-Einträge, um die Zone sauber zu halten.

Caching verstehen und Tests gezielt durchführen

Ich unterscheide Caches auf mehreren Ebenen: lokales OS, Browser, Resolver des Providers und nachgelagerte Forwarder. Bei Unklarheiten leere ich lokale Caches (z. B. via Systemtools) und teste gezielt gegen autoritative Nameserver. Mit dig schaue ich mir TTL, Authority und die Kette via +trace an. Bei unerwarteten NXDOMAIN-Antworten beachte ich die negative TTL aus dem SOA, bevor ich weitere Änderungen plane.

Delegation von Subdomains

Ich delegiere bei Bedarf einzelne Subdomains an andere Nameserver, indem ich NS-Records innerhalb der Zone für diese Subdomain setze. So kann ein SaaS-Team z. B. app.deinedomain.tld selbst verwalten, ohne dass ich die Hauptzone aus der Hand gebe. Ich denke an die passenden Glue-Records, wenn ich eigene Nameserver unterhalb der Domain betreibe.

Internationalisierte Domains (IDN)

Ich berücksichtige Umlaute/IDN: Im DNS arbeite ich mit Punycode (xn--…). Das UI nimmt mir oft die Umwandlung ab, in Protokollen oder bei manuellen Tools prüfe ich jedoch, ob Name und Zertifikat exakt zusammenpassen.

DNSSEC, IPv6 und Automatisierung

Ich aktiviere DNSSEC, wenn der Registrar es anbietet, damit Resolver Antworten kryptografisch prüfen können. Parallel pflege ich IPv6-Records, weil viele Netze heute v6 bevorzugen. Für wiederkehrende Setups nutze ich Vorlagen oder eine API, damit ich konsistente Records schneller ausrolle. Betreibe ich eigene Resolver oder Nameserver, achte ich auf saubere Glue-Records und serielles Versionsmanagement; ein Einstieg dazu: eigene Nameserver einrichten. So halte ich Änderungen nachvollziehbar, testbar und flott ausspielbar.

Arbeiten mit mehreren Umgebungen und Staging

Ich trenne Produktion, Staging und Test über Subdomains oder getrennte Zonen, damit ich Änderungen gefahrlos prüfen kann. Für Staging senke ich die TTL, damit neue Builds sofort sichtbar sind. Ich reserviere eindeutige Hostnamen wie staging, dev oder preview und dokumentiere die Ziele. Beim Umschalten nutze ich CNAME-Switches oder tausche A/AAAA-IPs mit niedriger TTL, damit Nutzer kaum Unterbrechungen spüren. Danach ziehe ich die TTL wieder hoch und archiviere die alten Werte.

Gründliche Pflege: Limits, Formatierung und Sauberkeit

TXT-Längen: Ich beachte 255-Zeichen-Segmente und breche lange Keys (DKIM) in korrekt quotierte Teile.
Namen & Punkte: Ich setze endständige Punkte nur, wenn das UI sie erwartet. Sonst erzeugen relative Namen unerwünschte Anhänge.
Keine Mischformen: Ich lege für einen Host entweder CNAME oder andere Typen an – nie beides.
Konflikte vermeiden: Wildcards greifen nicht, wenn ein Name explizit existiert. Kritische Hosts definiere ich daher bewusst.

Dokumentation, Backups und Change-Management

Ich sichere die aktuelle Zonendatei, bevor ich Änderungen starte, und notiere Datum, Zweck und Ticket-ID. Jede Anpassung erhält einen kurzen Kommentar, damit ich später Ursachen finde. Für größere Projekte führe ich ein Changelog im Repo, exportiere die Zone und sammele Testprotokolle. Vor Feiertagen oder Kampagnen plane ich Wartungsfenster und halte eine Rollback-Strategie bereit. Ein regelmäßiger Check der wichtigsten Hosts verhindert Überraschungen.

Abschluss und klare To-dos

Ich fokussiere mich auf wenige, saubere Records, eine passende TTL-Strategie und konsequente E-Mail-Authentifizierung. Danach prüfe ich Auflösung, Zertifikate und Zustellung, bis alle Tests grün sind. Für Wachstum rüste ich mit DNSSEC, IPv6 und Automatisierung nach. Änderungen dokumentiere ich sofort, damit ich später eindeutig weiß, was wann passiert ist. So bleibt dein All-Inkl Setup schnell, zuverlässig und für kommende Projekte gerüstet.