KeyHelp: DNS-Editor nutzen, Einträge und TTL pflegen oder DNS an einen externen Anbieter abgeben

KeyHelp bringt einen eigenen Nameserver mit: Für jede Domain schreibt das Panel automatisch eine DNS-Zone mit A-, MX-, SPF-, DMARC- und DKIM-Einträgen. Solange die Domain beim Registrar auf Ihre Nameserver zeigt, pflegen Sie alle Einträge im „DNS-Editor“. Liegt das DNS dagegen bei einem externen Anbieter, sollten Sie die Zone in KeyHelp abschalten und die nötigen Werte dort eintragen. Diese Anleitung zeigt beides: Einträge anlegen, TTL gezielt setzen, Fehler deuten und eine Domain sauber an externes DNS übergeben. Sie richtet sich an Administratoren eines Servers, der wie in KeyHelp installieren und absichern eingerichtet ist. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• Admin-Zugang zu KeyHelp. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12. Kunden sehen den DNS-Editor nur mit der passenden Berechtigung, siehe KeyHelp: Berechtigungen für Kunden gezielt freigeben.
• Eine angelegte Domain, im Beispiel kunde1.example.de.
• Wissen, wo das DNS der Domain liegt. Nur wenn beim Registrar die Nameserver Ihres KeyHelp-Servers eingetragen sind, wirken Änderungen im DNS-Editor. Prüfen können Sie das mit dig NS kunde1.example.de +short von einem beliebigen Rechner.
• Optional SSH als root und das Paket bind9-dnsutils für dig. Es war im Test nicht vorinstalliert, named-checkzone dagegen schon.

Schritt 1: Den DNS-Editor öffnen und die Standardzone lesen

Öffnen Sie im Admin-Bereich „Domains“, „DNS-Editor“. Die Seite „Domain-Auswahl“ listet alle Domains mit eigener Zone, im Test kunde1.example.de und die Systemdomain kunde1.server.example.de. Subdomains wie www haben keine eigene Zone, sie werden über den Platzhalter * der Hauptdomain aufgelöst. Ein Klick auf die Domain öffnet „DNS-Einstellungen bearbeiten“.

Oben steht der SOA-Block mit „Primärer Nameserver“, „E-Mail-Adresse der verantwortlichen Person (RNAME)“, „Aktualisieren“, „Erneut versuchen“, „Ablauf“ und „Minimum-TTL“. Darunter folgen die Standardeinträge, die KeyHelp für jede Domain anlegt:

• @ und * als A-Eintrag auf die IP des Servers,
• @ MX 10 mail, also mail.kunde1.example.de, das über den Platzhalter auf denselben Server zeigt,
• zwei NS-Einträge auf ns.server.example.de. und ns2.server.example.de.,
• SPF "v=spf1 a mx -all", DMARC "v=DMARC1; p=none" und der DKIM-Eintrag.

Der DKIM-Eintrag steht im Editor nur als Platzhalter <DKIM_RECORD_HOST> und <DKIM_RECORD_VALUE>. KeyHelp setzt beim Schreiben der Zone den Selektor und den aktuellen Schlüssel ein. Lassen Sie diese Platzhalter stehen: Laut Hinweis im Domainformular erzeugt jeder neue DKIM-Selektor einen neuen Schlüssel, und nur über die Platzhalter landet dieser automatisch in der Zone. Alle Einträge haben ab Werk eine TTL von 86400 Sekunden, also einem Tag.

Verifizieren: Auf dem Server liegt die Zone unter /etc/bind/keyhelp_domains/kunde1.example.de, mit dem Kopf „DO NOT CHANGE ANYTHING IN THIS FILE!“. Änderungen immer im Panel machen, nie in dieser Datei.

Schritt 2: Einträge hinzufügen

Klicken Sie unter der Tabelle auf „Record hinzufügen“. Eine leere Zeile erscheint mit den Feldern „Host“, „TTL“, „Eintragstyp“ und „Wert“. Zur Auswahl stehen A, AAAA, CAA, CNAME, HTTPS, MX, NS, PTR, SRV und TXT. Im Test haben wir vier typische Einträge angelegt:

Host	TTL	Typ	Wert	Zweck
shop	3600	CNAME	kunde1.example.de.	Alias auf die Hauptdomain
test	300	A	192.0.2.20	Subdomain auf anderen Server
@	3600	TXT	"google-site-verification=abc123"	Domain-Verifizierung
@	3600	CAA	0 issue "letsencrypt.org"	nur Let's Encrypt darf Zertifikate ausstellen

Beachten Sie den Punkt am Ende von kunde1.example.de.: Ohne ihn hängt BIND den Domainnamen an, aus dem Ziel würde kunde1.example.de.kunde1.example.de. Kurze Namen wie mail im MX-Eintrag funktionieren genau deshalb ohne Punkt. Klicken Sie danach auf „Speichern“. KeyHelp meldet „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ und markiert die Domain mit „Geändert“.

Verifizieren: Nach etwa einer Minute antwortet der Nameserver mit den neuen Werten:

dig +noall +answer @127.0.0.1 shop.kunde1.example.de CNAME
shop.kunde1.example.de.	3600	IN	CNAME	kunde1.example.de.
dig +noall +answer @127.0.0.1 kunde1.example.de SOA
kunde1.example.de.	86400	IN	SOA	ns.server.example.de. root.server.example.de. 2026100102 14400 1800 604800 3600

Die Seriennummer im SOA ist von 2026100101 auf 2026100102 gestiegen. KeyHelp zählt sie bei jeder gespeicherten Änderung hoch, damit sekundäre Nameserver die neue Version erkennen.

Schritt 3: TTL vor einer Änderung planen

Die TTL legt fest, wie lange andere Nameserver eine Antwort zwischenspeichern. Mit 86400 Sekunden kann es nach einem Serverumzug bis zu einem Tag dauern, bis alle Besucher die neue IP sehen. Planen Sie größere Änderungen deshalb in zwei Etappen:

1. Mindestens einen Tag vorher die TTL senken, etwa auf 300 Sekunden.
2. Am Stichtag die eigentliche Änderung durchführen. Sie ist dann nach wenigen Minuten überall sichtbar.
3. Danach die TTL wieder auf einen höheren Wert setzen.

Dafür gibt es neben dem SOA-Feld „TTL“ die Schaltfläche „Übernehmen“. Im Test haben wir 300 eingetragen und „Übernehmen“ geklickt, sofort standen alle zwölf Zeilen der Tabelle auf 300. Gespeichert wird erst mit „Speichern“. Wollen Sie nur einzelne Einträge kurzlebig machen, ändern Sie stattdessen die TTL in der jeweiligen Zeile. Für viele Domains auf einmal gibt es eine eigene Funktion, beschrieben in KeyHelp: Massenoperationen für PHP-Version und DNS-TTL.

Verifizieren: dig +noall +answer @127.0.0.1 kunde1.example.de A zeigt in der zweiten Spalte die neue TTL, im Test 300.

Schritt 4: Fehlermeldungen beim Speichern verstehen

KeyHelp prüft die Zone vor dem Schreiben. Wir haben zwei typische Fehler bewusst ausprobiert.

Eine ungültige IP-Adresse (192.0.2.300) in einem A-Eintrag wies das Formular direkt zurück: „Eintrag #13 | Die Eingabefelder enthalten ungültige Daten für einen A-Eintrag.“ Die Nummer bezieht sich auf die Zeile in der Tabelle.

Ein zusätzlicher A-Eintrag für shop, obwohl shop schon ein CNAME ist, passierte die Feldprüfung, scheiterte dann aber an der Zonenprüfung von BIND:

Die Regel dahinter: Ein Name mit CNAME darf keine weiteren Einträge haben. Deshalb können Sie auch für die Domain selbst (@) keinen CNAME setzen, dort stehen immer SOA, NS und MX. Wichtig: Bei abgelehnten Zonen bleibt die alte Zone aktiv, es geht nichts kaputt. Ihre Eingaben müssen Sie aber neu machen.

Verifizieren: Nach einer Fehlermeldung zeigt dig unverändert die alten Werte, und die Seriennummer im SOA ist nicht gestiegen.

Schritt 5: Zone zurücksetzen

Haben Sie sich verkonfiguriert, hilft „Einstellungen zurücksetzen“ unter der Tabelle. Nach der Rückfrage „Sind Sie sicher, dass Sie die Einstellungen zurücksetzen möchten?“ und „Ja“ stellte KeyHelp im Test die acht Standardeinträge mit der aktuellen Server-IP wieder her. Alle eigenen Einträge, auch Verifizierungs-TXT und CAA, waren weg. Notieren Sie eigene Einträge also vorher.

Ein zweiter Grund für das Zurücksetzen: Der Hinweis unter „Konfiguration“, „IP-Adressen“ lautet „Domains mit benutzerdefinierten DNS-Einstellungen werden nicht geändert.“ Sobald Sie eine Zone im Editor gespeichert haben, gilt sie als benutzerdefiniert. Bei einem IP-Wechsel des Servers müssen Sie diese Zonen selbst anpassen oder zurücksetzen.

Verifizieren: Das Ereignisprotokoll enthält „DNS settings of domain kunde1.example.de (#2) reset.“, und dig liefert nur noch die Standardeinträge.

Schritt 6: DNS an einen externen Anbieter abgeben

Verwaltet ein anderer Anbieter das DNS, etwa der Registrar oder ein DNS-Dienst, sollte KeyHelp keine eigene Zone mehr ausliefern. Sonst gibt es zwei Wahrheiten, und wer später auf die KeyHelp-Nameserver umstellt, bekommt veraltete Daten. Dafür gibt es zwei gleichwertige Schalter: im DNS-Editor „DNS für diese Domain deaktivieren“ und beim Bearbeiten der Domain im Reiter „Allgemein“ die Option „DNS deaktivieren“. Beide setzten im Test denselben Wert.

Übernehmen Sie vor dem Abschalten diese Werte beim externen Anbieter:

• A-Eintrag für @ und www auf die IP des KeyHelp-Servers,
• MX auf den Mailserver, wenn KeyHelp die Postfächer hostet,
• SPF und DMARC aus der Zone,
• den DKIM-Eintrag. Der Hinweis im Editor sagt: „Wenn Sie eine externe DNS-Verwaltung verwenden, sollten Sie dort den entsprechenden DKIM-DNS-Eintrag ( Anzeigen ) hinzufügen.“ Ein Klick auf „Anzeigen“ öffnet den Dialog „DKIM DNS-Eintrag“ mit Host und Wert zum Kopieren.

Welche Variante Sie kopieren, hängt vom Anbieter ab. Die meisten Weboberflächen erwarten „DKIM-Wert ohne Anführungszeichen“. Der Wert mit Anführungszeichen ist in Blöcke zu 255 Zeichen aufgeteilt, so wie ihn Zonendateien brauchen.

Nach dem Speichern mit aktiviertem Schalter löschte KeyHelp im Test die Zonendatei /etc/bind/keyhelp_domains/kunde1.example.de, die Abfrage beim lokalen BIND ergab status: SERVFAIL statt einer Antwort. Die Website lieferte weiter 200, an der Domain selbst änderte sich nichts. Nach dem Abschalten des Schalters war die Zone eine Minute später wieder da, mit den zuletzt gespeicherten Einträgen.

Verifizieren: ls /etc/bind/keyhelp_domains/ listet die Domain nicht mehr, und von außen zeigt dig NS kunde1.example.de +short die Nameserver des externen Anbieters.

Typische Fehler

• „Syntaxprüfung fehlgeschlagen, bitte überprüfen Sie Ihre Eingaben!“ mit „CNAME and other data“: Für denselben Namen existiert neben dem CNAME ein weiterer Eintrag. Einen davon entfernen.
• „Die Eingabefelder enthalten ungültige Daten für einen A-Eintrag.“: Wert ist keine gültige IPv4-Adresse, etwa ein Tippfehler oder eine IPv6-Adresse im A-Eintrag (dafür AAAA verwenden).
• Ziel landet unter einem doppelten Namen: Der abschließende Punkt bei vollständigen Namen fehlt.
• Änderung im Editor wirkt nicht: Die Domain nutzt beim Registrar fremde Nameserver. Mit dig NS prüfen.
• Nach IP-Wechsel zeigen einzelne Domains auf die alte IP: Diese Zonen sind benutzerdefiniert und wurden nicht angepasst, siehe Schritt 5.

Häufige Fragen

Gibt es einen sekundären Nameserver?

KeyHelp trägt ns und ns2 unter dem Server-Hostnamen ein. In der getesteten Grundkonfiguration stand in /etc/bind/named.conf.options allow-transfer { none; };, Zonentransfers zu einem Zweitserver sind also nicht vorbereitet. Wer echte Redundanz braucht, plant dafür einen externen DNS-Anbieter ein.

Wie schnell wirkt eine Änderung?

Auf dem eigenen Server nach etwa einer Minute, beim nächsten Wartungslauf. Bei Besuchern erst, wenn die alte TTL abgelaufen ist.

Kann ich Einträge per Datei importieren?

Im getesteten Editor gibt es keinen Import. Einträge werden zeilenweise angelegt. Für viele Domains ist die REST-API die bessere Wahl, siehe KeyHelp-REST-API nutzen.

Testumfang

Wir haben auf KeyHelp 26.1.1 CNAME-, A-, TXT- und CAA-Einträge angelegt, die TTL übertragen, zwei Fehleingaben provoziert, die Zone zurückgesetzt und DNS ab- und wieder eingeschaltet, jeweils mit dig gegen den lokalen BIND geprüft. Auffällig: Zurücksetzen löscht alle eigenen Einträge ohne Liste. Die Auflösung aus dem Internet und echte externe Anbieter haben wir nicht geprüft. Testen Sie nach jeder Umstellung von außen mit dig.

Fazit

Der DNS-Editor von KeyHelp ist schlicht, aber sicher: Er prüft jede Zone vor dem Schreiben und lässt kaputte Zonen gar nicht erst live gehen. Wer die TTL vor Umzügen rechtzeitig senkt, eigene Einträge dokumentiert und bei externem DNS die Zone in KeyHelp konsequent abschaltet, vermeidet die typischen Probleme mit doppelter Pflege und veralteten Antworten.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: Berechtigungen für Kunden gezielt freigeben
• KeyHelp: Massenoperationen für PHP-Version und DNS-TTL
• KeyHelp Knowledge Base: DNS-Zone bearbeiten
• Keyweb: KeyHelp, alle Funktionen im Überblick