DNS-Einträge von Netcup-DNS in CCP plötzlich ungültig.

  • Dass sich Dnssec manchmal deaktiviert, wenn man im CCP was ändert ist mir auch schon ein paar Mal passiert. Zum Glück war's aber nur dann und mit reaktivieren wieder behoben.

    Na dann hoffe ich mal, dass der Uptimerobot die Domain jedes Mal neu auflöst und auch Dnssec überprüft.

  • Ja ist leider auch bei mir der Fall für eine Domain die seit langem nicht mehr geändert wurde, d.h. plötzlich und unerwartet geht die Website nicht mehr. Die erste Antwort vom Support: Bitte setzen Sie einen A Record da dieser nicht gesetzt ist. Ich wusste erst nicht ob ich lachen oder weinen muss. Der Hinweis das dieser gesetzt ist und war brachte dann wohl einmal den Mitarbeiter zum nachdenken. Ist ja nicht so, dass ich die unterschiedlichen Meldungen der netcup DNS Server mit beigefügt hätte. Daran konnte man schön sehen das der „Root“ etwas anderes meldet als „Second“ und „Third“.

    Seit der Meldung hört man leider nichts mehr vom Support, echt ätzend!

  • Fordert ein Beschwerdestellenticket an, wenn Ihr denkt, dass Euer Anliegen nicht hinreichend beachtet wird.

    Um keine Missverständnisse in dem vom mir eröffneten Thema zu erzeugen, hier eine Antwort zum Kommentar oben.


    Ich kann mich nicht über den Support von Netcup beschweren. In der Vergangenheit hatte ich bei anderen Problemen schnelle Hilfe erhalten. Auch jetzt hat sich der Support bei mir nach zwei Tagen gemeldet. Da ich aber zu diesem Zeitpunkt bereits auf einen externen DNS als Notlösung umgestellt hatte, konnte das Problem bei mir nicht mehr analysiert werden.


    Bemängle tue ich das Produkt „Netcup-DNS“. Hier scheint der Wurm drin zu sein. Davon sind laut Meldungen im Forum einige aktuell und auch in der Vergangenheit betroffen.

  • Sorry, aber zwei Tage für so eine Analyse ist einfach zu lange. Hier scheint ein grundsätzliches Problem vorzuherrschen. Ich bin mal gespannt was als nächste Antwort vom Support kommt, so nach dem Motto: wir konnten keine Auffälligkeit finden.

  • Sorry, aber zwei Tage für so eine Analyse ist einfach zu lange. Hier scheint ein grundsätzliches Problem vorzuherrschen. Ich bin mal gespannt was als nächste Antwort vom Support kommt, so nach dem Motto: wir konnten keine Auffälligkeit finden.

    Notiz an die Küche: Keine Domain-Aktionen an einem Wochenende, wenn ohnehin schon bekannt ist, dass es Troubles mit DNS, DNSSEC, Whois und EPP gibt.

  • Mir ist gerade auch mal aufgefallen das mein MX Eintrag nun auch weg ist, also kann keine E-Mail vom Support kommen ? Aber getreu dem Motto „wir schaffen das“ vertraue ich mal das heute Abend noch was passiert. Für die Zukunft muss ich mir wohl über zuverlässigeres DNS Gedanken machen.

  • Mir ist gerade auch mal aufgefallen das mein MX Eintrag nun auch weg ist, also kann keine E-Mail vom Support kommen ? Aber getreu dem Motto „wir schaffen das“ vertraue ich mal das heute Abend noch was passiert. Für die Zukunft muss ich mir wohl über zuverlässigeres DNS Gedanken machen.

    Es ist keine gute Idee, eine E-Mailadresse eines im CCP verwalteten Produkts als Kontaktadresse für das CCP anzugeben.

  • Es ist keine gute Idee, eine E-Mailadresse eines im CCP verwalteten Produkts als Kontaktadresse für das CCP anzugeben.

    Ob man allerdings ein "x-beliebiges" E-Mail-Konto dafür verwenden will? Im CCP steht ja explizit "im Kleingedruckten":

    Quote

    […] Die hier angegebene E-Mailadresse wird auch für den Inhaber und Admin-C Ihrer Domainregistrierungen hinterlegt. […]

    Das Problem ließe sich aber auch schon dadurch relaxieren, wenn man denn mehrere Adressen angeben könnte… ich glaube, das wurde irgendwann auch einmal hier andiskutiert.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Mir ist gerade auch mal aufgefallen das mein MX Eintrag nun auch weg ist, also kann keine E-Mail vom Support kommen ?

    Solange ein oder mehrere @ A-/AAAA-Eintrag/-Einträge vorhanden ist/sind, darf der MX-Eintrag "notfalls" fehlen (vgl. RFC 5321). Blöd ist nur (wie in meinem Fall), wenn ein MX-Eintrag vorhanden ist, aber seinerseits auf ungültige A-/AAAA-Einträge verweist. Dann kann man nur noch hoffen, dass ersterer zumindest noch gelöscht werden kann.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • So jetzt erstmal selber geholfen, DNSSEC deaktiviert und schon funktioniert es wieder. Der Support hat noch Nichteinhaltung das geschafft. Ich warte morgen auf die Aussage wir konnten keine Einschränkungen feststellen weil sich das niemand genauer anschaut. ?

  • Hier für alle einmal die Antwort vom Support: „Wir haben einen Fehler identifiziert, der vereinzelt und unter bestimmten Bedingungen bei DNSSEC signierten Zonen mit SMIMEA-Records dazu führt, dass diese nicht mehr korrekt auflösen. Wir werden dies schnellstmöglich in unserer Entwicklung beheben. Um die akuten DNS-Auflösungsprobleme zu beheben, bitten wir Sie, alle SMIMEA-Records bei der betroffenen Domain temporär zu entfernen und diese dann zu speichern.“


    Und hier die Dauer des Problems von meiner Analyse bis das im Support mitgeteilt und behoben wurde (im Anhang).

  • Das Problem ließe sich aber auch schon dadurch relaxieren, wenn man denn mehrere Adressen angeben könnte… ich glaube, das wurde irgendwann auch einmal hier andiskutiert.

    Das Problem ließe sich auch dadurch mindern, wenn man Privaten zugestehen würde, Whois-Objekte wie wohl -laut Auskunft des Supports- bei den Reseller Leveln anlegen zu können. Da könnte dann auch ein Domain Admin mit mehreren Sub-Handles angelegt werden. Aber auch so etwas bekomme ich derzeit hier in Karlsruhe nicht, sondern muss dafür nach St. Ingbert pilgern.

  • Hier für alle einmal die Antwort vom Support: „Wir haben einen Fehler identifiziert, der vereinzelt und unter bestimmten Bedingungen bei DNSSEC signierten Zonen mit SMIMEA-Records dazu führt, dass diese nicht mehr korrekt auflösen.[...]“

    Da ich meinen DNS bereits auf einen externen Server umgezogen habe, war eine Analyse bei mir nicht mehr möglich. Aber ich habe aber vom Support heute die gleiche Bestätigung erhalten.

    Quote

    Unter bestimmten Umständen kann es bei Zonen, die einen SMIMEA Record beinhalten und mit DNSSEC signiert sind, derzeit vorkommen, dass eine Vielzahl an Records als ungültig markiert wird. Der SMIMEA selbst ist dabei im Regelfall nicht als ungültig markiert und muss dafür auch nicht verändert werden (das Verhalten tritt aber nur unter bestimmten Konditionen auf). Ich gehe davon aus, dass dies in Kürze gelöst sein wird.

    Jetzt ist nur noch offen, wann "in Kürze" sein wird?

  • So, bei mir hat es jetzt auch zugeschlagen - wieso auch immer, ist eine Subdomain, soviel hab ich bisher gefunden, DNSSec invalid.


    "second-dns.netcup.net serial (2020111568) differs from root-dns.netcup.net serial (2020121369)"

    Das zu Auswertung. Also zum einen scheint hier die Replikation nicht mehr zu funktionieren, bzw. Murks repliziert zu werden.

    In der Zone ist auch ein SMIMEA Record hinterlegt.


    Update: Nach deaktivieren von DNSSec werden die Records sofort wieder ausgeliefert.


    netcup: Das kann doch jetzt langsam echt kein Zustand mehr sein. Wieso steht auf der Statusseite hierzu nichts?

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

  • Weiteres Update second-dns.netcup.net & third-dns.netcup.net liefern für die Domain nun gar nichts mehr aus, das kann doch so nicht wahr sein!

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

  • Update: root-dns.netcup.net liefert jetzt für die Domain auch nichts mehr aus.


    Update 2: Testweise Records angelegt, bzw. wieder gelöscht um die Replikation zu triggern - ohne Erfolg. Als ich jedoch den SMIMEA Record gelöscht habe, haben 5 Minuten später alle Nameserver wieder ausgeliefert.


    [netcup] Felix P. das scheint ein generelles Problem eurer DNS Infrastruktur zu sein. Wieso wird hier nicht offiziell darüber informiert? Wieso steht dies nicht auf http://www.netcup-status.de ? Wieso deaktiviert ihr SMIMEA Records nicht generell, natürlich mit einer Info an alle betroffenen Kunden?



    Bin mal gespannt, was der Support auf das Ticket von vorhin antwortet.

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

    • Official Post

    Hallo zusammen,



    unter bestimmten Voraussetzungen und Umständen konnte es dazu kommen, dass mit DNSSEC gesicherte Domains nicht mehr korrekt auflösten, wenn SMIMEA-Records in einer Zone enthalten waren. Der Sachverhalt ist nun behoben und SMIMEA-Records können wieder in mit DNSSEC gesicherten Zonen ohne Probleme genutzt werden.


    Von dem Sachverhalt war nur ein minimaler Bruchteil an Domains betroffen (selbst von den Domains, welche DNSSEC und SMIMEA nutzen, was ebenfalls bereits ein sehr kleiner Anteil unserer Zonen ist). Eure Kritik bezüglich der Informationen auf netcup-status.de werden wir evaluieren und für die Zukunft berücksichtigen. Wir informieren auf netcup-status.de in der Regel über allgemeine Störungen, die einen gewissen Kreis an Kunden betreffen. Selbstverständlich sind wir in einem Fall wie diesem für unsere Kunden auch per Notfallsupport kostenfrei und 24 / 7 / 365 zu erreichen, so dass der Sachverhalt mit einem netcup Techniker erörtert und gelöst werden kann.


    Ich danke für eure Meldungen hier und wünsche noch einen schönen Tag.

  • Hi,


    ok, dann nehm ich das mal als Bestätigung, dass das bekannte Problem gefixt ist und hab den SMIMEA Record wieder gesetzt.

    Das Monitoring prüft die Records und wenns wieder kaputt ist, dann kann ich im Notfallticket auf diesen Thread verweisen?

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020