DNS-Zonen-Export hängt (Query refused auf autoritativem NS) - Bug im CCP?

    Hallo zusammen,

    ich habe ein neues Webhosting 1000 inkl. einer .com-Domain registriert. Die ICANN-Verifizierung ist durch, Whois steht auf "active", Nameserver sind offiziell auf root-dns.netcup.net etc. gesetzt.

    Das Problem: Das CCP exportiert die Zonen-Datei offensichtlich nicht auf die physischen Nameserver. Wenn ich das CloudDNS im CCP anpasse (z. B. MX-Records bereinige), wird die Änderung im Frontend als gespeichert angezeigt. Frage ich aber den autoritativen Nameserver direkt ab (nslookup -type=MX meinedomain.com root-dns.netcup.net), erhalte ich ein hartes Query refused.

    Offenbar hängt der Zonen-Export (Cronjob) vom CCP auf die produktiven Nameserver komplett. Es scheint so, als ist die Zone auf dem NS schlicht nicht vorhanden, weshalb die globale Propagation blockiert ist. Ein manuelles Triggern der SOA-Serial durch einen TXT-Eintrag brachte ebenfalls keinen Erfolg.

    Da das Mailsystem physisch getrennt läuft (mx4411), kommen durch diesen Hänger auch keinerlei Mails an.

    An die erfahrenen User hier bei netcup: Übersehe ich was?

    Ein Ticket ist bereits offen. Hat jemand aktuell ähnliche Hänger beim Provisioning oder kann ein Admin den Zonen-Reload für meinen Account kurzfristig manuell anstoßen?

    Ticketnummer: NCSUP-996321

    Danke euch

    Das sieht nach diesem Fehler aus. Da du die Domain in deinem CCP im "CloudDNS" siehst, sollte sie auf den neuen Nameservern (netcup.firstns.cc, netcup.secondns.at, netcup.thirdns.de, netcup.fourthns.systems und netcup.fifthns.com) liegen. Du kannst ja mal versuchen, sie darüber aufzulösen. Die werden aber natürlich nicht gefragt, wenn Netcup die Domain an die alten Nameserver delegiert.

    Lösungsvorschläge wie im anderen Thema: Zuständig ist der Support. Wenn der zu lange braucht, ist eine Möglichkeit zur Selbsthilfe, die Domain an externe Nameserver zu delegieren, z.B. deSEC.io, und dann entweder davon zurück zu Netcup zu holen, in der Hoffnung dass die Delegation dadurch korrigiert wird, oder sie bei deSEC zu lassen.

    2 Mal editiert, zuletzt von NaN (8. September 2026 um 11:03)

    Hallo NaN,

    tausend Dank für die extrem schnelle und aufschlussreiche Antwort! Du hast mir damit wirklich den Tag gerettet. Offenbar funktioniert hier jedenfalls die Community! :thumbup:

    Deine Erklärung scheint tatsächlich das gesamte Mysterium hier bei netcup aufzulösen. Es klingt für mich absolut möglich, dass das Bestellsystem die Domain noch auf die alten Nameserver delegiert hat, während das CCP alle Änderungen bereits in das neue CloudDNS-System schreibt. Das würde diesen Split-Brain-Effekt perfekt erklären und auch, warum die alten Root-DNS-Server die Anfragen einfach mit einem "Query refused" abblocken.

    Ich werde jetzt mal deinen Rat befolgen und im CCP testen, ob ich die Delegation über die Einstellung "Eigene Nameserver" manuell auf die neuen CloudDNS-Server (firstns.cc bis fifthns.com) umbiegen kann, um die Wartezeit beim Support zu umgehen. Falls das System da bockt, ist der Umweg über deSEC.io definitiv mein Plan B.

    Nochmals herzlichen Dank für die großartige und schnelle Hilfe aus der Community!

    Viele Grüße

    Zitat von NaN

    Im anderen Thema hat das nicht geklappt, aber Versuch macht klug.

    Yo da hattest du "leider" absolut den richtigen Riecher! Versuch macht zwar klug, aber das Netcup-System macht direkt die Tür zu ^^.

    Ich habe es gerade ausprobiert und die Fehlermeldung ist schon fast IT-Realsatire: "Der eingegebene Hostname verweist auf die Nameserver von netcup. Das ist nicht über die Eingabe von eigenen Nameservern möglich."

    Das System verbietet mir also de facto, den "Routing-Bug" manuell zu flicken, weil ich dafür die eigenen Server des Systems nutzen müsste. Ein astreiner Catch-22 ^^.

    Dein Tipp mit dem externen Bypass über deSEC.io rückt damit definitiv auf Platz 1 meiner Notfallpläne, falls der Support den Datenbank-Knoten heute nicht mehr von selbst löst. Ich lasse das Ticket jetzt erstmal arbeiten.

    Danke nochmal fürs Mitdenken, das bewahrt mich heute zumindest vor weiterem wilden und sinnlosen Herumklicken im CCP :thumbup:.

    Du kannst die Zone bei desec.io auch schon vorsichtshalber vorab anlegen, um dir ggf - falls die eigenständige Delegation auf die korrekten CloudDNS Nameserver nicht funktioniert, was ich für recht wahrscheinlich halte - die dafür notwendige Zeit bei der Umstellung auf deSEC zu sparen. Der Service ist ja kostenlos bis zu einer gewissen Anzahl Domains.

    Edit: Besser (zumindest für netcup) wäre es freilich, wenn sich der Support zügig darum kümmern würde. Insbesondere auch intern darum, dass dieser Bug bei der Domain-Registrierung zeitnah behoben wird. Sonst ist es eben Arbeitsbeschaffung für den Support, weil der ja sonst nichts zu tun hat ;);(:rolleyes:. Außerdem kann man mit so einem Bug natürlich auch prima neue Kunden vergraulen.

    Einmal editiert, zuletzt von tab (8. September 2026 um 12:52)

    Hallo tab,

    Was geht hier ab? :) Echt mal richtig goil, eine so hilfreiche und gechillte Community heutzutage überhaupt noch zu finden. Bin vglw "schnell" zu netcup "gestolpert", weil Trustpilot etc recht gut echot.

    Aber erstmal auch Dir -> herzlichen Dank für deinen supi Ratschlag! Auch Dein Vorschlag geht ja zur Vorab-Anlage bei deSEC > dürfte also "strategisch" iM das Beste sein. Ergo, versuche ich das als vorbereitetes Backup umzusetzen. Wenn ich Euch richtig verstanden habe, hätte ich damit eine "externe Zone" komplett fertig in der Schublade und müsste heute Nachmittag nur noch den Schalter im CCP umlegen, falls der Support den internen Knoten bis dahin nicht gelöst hat.

    Zu deinem Edit: Hmm, da triffst du den Nagel offenbar auf den Kopf - leider :( Ein Bug, der die eigenen Support-Ressourcen ohne Not bindet und den Kunden direkt beim Onboarding in eine Endlosschleife schickt, ist schon "blöd", vor allem wenn's vorher oder bisher recht "gut" gelaufen ist. Aber das geht offenbar nicht nur netcup so, "Support" kostet viel Geld und - oh Wunder - man bekommt kein oder zu wenig "Fachpersonal" < aber den "Schlund" will ich jetzt gar nicht aufmachen ;). Hoffen wir mal, dass das Ticket schnell die richtige Fachabteilung erreicht, bevor der Support in diesen manuellen Fixes ertrinkt.

    Hab ich mir schon "notiert": Eine aktive und leidenschaftliche Community kann überall und "Wurscht was" auch schwierige Phasen "unterstützen" > in jedem Fall > Danke, danke, der leidenschaftliche Forum-Support hier von euch, das hilft massiv weiter!!

    Hi NaN und tab,

    kurze Rückmeldung für Euch und alle anderen mit diesem DNS-NS-Problem:
    Euer Tipp mit dem (temporären) Bypass für die CloudDNS Nameserver via deSEC ist DIE Lösung!!
    - Innerhalb Minuten gereggt, eingetragen und schon nach max 10 Min war die Webseite "online".
    - E-Mail: nochmal ins WCP bei netcup > paar Einstellungen gemacht > abgespeichert > dann E-Mail-Services für die Domain deaktiviert > wieder aktiviert = Erfolgreich!
    Aktuell flufft alles geschmeidig - nur schade, dass netcup diese elementare Basisproblem nicht zeitnah gebacken kriegt. E-Mail vom Support noch nicht erhalten.
    Daher nochmals vielen Dank! an Euch beide - habt mir den Tag und den Abend gerettet:thumbup::!: