Beiträge von HostCheck88

Zitat von matthmu

Was genau soll ich tun? Ich verstehe nur Bahnhof, tut mir leid.
Geht vermutlich über meinen Kompetenzbereich weit hinaus, entschuldige.

Keine Ahnung, ob du das für dich im konkreten Fall nützlich ist:

Thema

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…

HostCheck88

8. September 2026 um 10:47

Ich habe ein kleines Webhosting-Paket + .com Domain genommen und zuerste die NS von netcup genutzt. Als nach 3 T. noch immer nix ging, Domain nicht gefunden wurde > Ticket an Support raus > nix. Mir wurde dann von Forenmitgliedern () super geholfen. Habe temp auf deSEC (ohne Wertung) umgestellt > ging in 5 min. > kurz darauf war die Dom zu finden. Am Mo., 14. Sept., kam dann eine Antwort vom Support: "... vielen Dank für Ihre Anfrage. Nach einer Prüfung möchte Ich Sie darüber informieren, dass Ihre Domain mittlerweile wie Gewohnt erreichbar sein sollte." > hab aber noch ext NS laufen, bin noch nicht dazu gekommen, wieder auf netcup NS umszustellten und zu probieren, ob es jetzt auch darüber geht.

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

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!!

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 .

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!

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

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