Hi,
danke, wir haben diese erhalten und sie liegt der zuständigen Abteilung vor. Diese antwortet dir schnellstmöglich.
Hi,
danke, wir haben diese erhalten und sie liegt der zuständigen Abteilung vor. Diese antwortet dir schnellstmöglich.
Da das Problem nun doch schon eine ganze Weile besteht und immer noch aktuell ist, stellt sich mir die Frage, ob man da in irgendeiner Form zur Ursachenfindung beitragen kann. Sollen wir alle gefundenen Domains mit "kaputtem" DNSSEC an den Support melden, damit ihr euch die Details anschauen könnt?
Hallo tab,
danke für deine Frage.
Gerne unterstützt unser Support bei Problemen mit DNSSEC über die gewohnten Kontaktwege (am besten per E-Mail an mail@netcup.de).
Zur Untersuchung des Sachverhalts hilft es uns, wenn zuvor (während das Problem besteht) eine Analyse mit dnsviz.net durchgeführt wird und diese in der E-Mail verlinkt wird. Dies erlaubt es uns, auch nach behobenem Sachverhalt den Zustand der Domain zu untersuchen und so etwaige Probleme auf unserer Seite finden und lösen zu können.
[netcup] Lars S. *ping*
Vielleicht wären da neuere Hostkeys angebracht?
OpenSSH 8.2 unter Ubuntu 20.04 unterstützt definitiv mehr.
Hi KB19,
ich habe gerade die Rückmeldung aus der Fachabteilung erhalten, dass das nun behoben sein sollte.
Alles anzeigenModeratoren
es scheint ein seltsames Routing-Problem zu geben
2 vServer, einer hier in Nürnberg [shinkansen.host] und einer in bei jemand anders in Wien [6in4gate.tunnel]
einmal IPv4/IPv6 von Wien [6in4gate.tunnel] nach Nürnberg [shinkansen.host] - das passt
CodeAlles anzeigen[root@6in4gate ~]# traceroute -I shinkansen.host traceroute to shinkansen.host (194.55.15.x), 30 hops max, 60 byte packets 1 gw101.core1.vie.alwyzon.net (46.102.157.65) 5.980 ms 5.983 ms 5.979 ms 2 ae0.edge1.vie.alwyzon.net (46.102.157.10) 0.557 ms 0.567 ms 0.608 ms 3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (193.203.0.19) 0.446 ms 0.451 ms 0.503 ms 4 ae0-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.132) 9.388 ms 9.389 ms 9.411 ms 5 ae1-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.137) 9.065 ms 9.064 ms 9.061 ms 6 netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11) 9.015 ms 10.005 ms 9.997 ms 7 shinkansen.host (194.55.15.x) 10.041 ms 10.368 ms 10.576 ms [root@6in4gate ~]# traceroute6 -I shinkansen.host traceroute to shinkansen.host (2a03:4000:31:x::1), 30 hops max, 80 byte packets 1 gw101.core1.vie.alwyzon.net (2a0d:f302:101::1) 15.824 ms 15.837 ms 15.778 ms 2 ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1) 0.271 ms 0.299 ms 0.300 ms 3 et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147) 0.588 ms 0.591 ms 0.590 ms 4 2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132) 0.540 ms 0.579 ms 0.577 ms 5 2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137) 9.023 ms 9.034 ms 9.030 ms 6 2a00:11c0:47:3::33 (2a00:11c0:47:3::33) 11.941 ms 11.855 ms 11.843 ms 7 shinkansen.host (2a03:4000:31:x::1) 9.262 ms 9.087 ms 9.093 ms [root@6in4gate ~]#
aber hier die andere Richtung von Nürnberg [shinkansen.host] nach Wien [6in4gate.tunnel], ebenfalls IPv4/IPv6
CodeAlles anzeigen[root@shinkansen ~]# traceroute -I 6in4gate.tunnel traceroute to 6in4gate.tunnel (46.102.157.x), 30 hops max, 60 byte packets 1 194.55.12.2 (194.55.12.2) 0.506 ms 1.153 ms 1.506 ms 2 ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10) 1.677 ms 1.847 ms 2.007 ms 3 ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136) 10.684 ms 11.087 ms 11.258 ms 4 ae0-0.bbr01.anx03.vie.at.anexia-it.net (144.208.208.133) 10.147 ms 10.318 ms 10.858 ms 5 vix.alwyzon.net (193.203.0.75) 9.299 ms 9.847 ms 10.479 ms 6 ae19.core1.vie.alwyzon.net (46.102.157.11) 31.178 ms 28.883 ms 29.173 ms 7 6in4gate.tunnel (46.102.157.x) 9.347 ms 9.010 ms 9.166 ms [root@shinkansen ~]# traceroute6 -I 6in4gate.tunnel traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets 1 2a03:4000:31::2 (2a03:4000:31::2) 5.321 ms 5.298 ms 5.281 ms 2 2a03:4000:ff00:4::4 (2a03:4000:ff00:4::4) 0.375 ms 0.386 ms 0.379 ms 3 2a00:11c0:47:3::fa (2a00:11c0:47:3::fa) 66.031 ms 66.014 ms 65.994 ms 4 2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138) 0.373 ms 0.355 ms 0.310 ms 5 2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136) 9.150 ms 9.164 ms 9.160 ms 6 2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133) 9.155 ms 9.419 ms 9.401 ms 7 vix.alwyzon.net (2001:7f8:30:0:2:1:4:994) 9.198 ms 9.181 ms 9.182 ms 8 2a0d:f302:8:11:: (2a0d:f302:8:11::) 11.784 ms 58.969 ms 58.911 ms 9 6in4gate.tunnel (2a0d:f302:101:x::1) 9.129 ms 9.058 ms 9.033 ms [root@shinkansen ~]#
hier passt das bei IPv6 nicht;
falls dies die selbe Ursache hat, iperf3 in Wien [6in4gate.tunnel] als Server gestartet
und iperf3 unterscheidet sich hier ebenfalls aber genau anders herum: bei IPv6 passt und bei IPv4 hackt es;
CodeAlles anzeigen[root@shinkansen ~]# iperf3 -4 -c 6in4gate.tunnel -R Connecting to host 6in4gate.tunnel, port 5201 Reverse mode, remote host 6in4gate.tunnel is sending [ 4] local 194.55.15.x port 36128 connected to 46.102.157.x port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 24.1 MBytes 202 Mbits/sec [ 4] 1.00-2.00 sec 24.3 MBytes 204 Mbits/sec [ 4] 2.00-3.00 sec 24.8 MBytes 208 Mbits/sec [ 4] 3.00-4.01 sec 25.4 MBytes 212 Mbits/sec [ 4] 4.01-5.01 sec 25.3 MBytes 213 Mbits/sec [ 4] 5.01-6.01 sec 21.6 MBytes 180 Mbits/sec [ 4] 6.01-7.00 sec 24.3 MBytes 206 Mbits/sec [ 4] 7.00-8.00 sec 29.3 MBytes 245 Mbits/sec [ 4] 8.00-9.01 sec 22.3 MBytes 186 Mbits/sec [ 4] 9.01-10.00 sec 23.6 MBytes 200 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 247 MBytes 207 Mbits/sec 42 sender [ 4] 0.00-10.00 sec 245 MBytes 206 Mbits/sec receiver iperf Done. [root@shinkansen ~]# iperf3 -6 -c 6in4gate.tunnel -R Connecting to host 6in4gate.tunnel, port 5201 Reverse mode, remote host 6in4gate.tunnel is sending [ 4] local 2a03:4000:31:x::1 port 49364 connected to 2a0d:f302:101:x::1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 85.0 MBytes 713 Mbits/sec [ 4] 1.00-2.00 sec 105 MBytes 885 Mbits/sec [ 4] 2.00-3.00 sec 102 MBytes 857 Mbits/sec [ 4] 3.00-4.00 sec 83.0 MBytes 696 Mbits/sec [ 4] 4.00-5.00 sec 87.5 MBytes 734 Mbits/sec [ 4] 5.00-6.00 sec 91.3 MBytes 766 Mbits/sec [ 4] 6.00-7.00 sec 93.1 MBytes 781 Mbits/sec [ 4] 7.00-8.00 sec 95.2 MBytes 799 Mbits/sec [ 4] 8.00-9.00 sec 78.3 MBytes 657 Mbits/sec [ 4] 9.00-10.00 sec 72.7 MBytes 610 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 897 MBytes 753 Mbits/sec 367 sender [ 4] 0.00-10.00 sec 895 MBytes 750 Mbits/sec receiver iperf Done. [root@shinkansen ~]#
Hallo mainziman,
vielen Dank für deinen Hinweis.
Bitte wende dich damit an unseren Support unter mail@netcup.de. Dieser kann das beschriebene Anliegen prüfen und an die richtige Stelle weitergeben. Danke.
Hallo KB19,
danke für deinen Hinweis.
Ich habe das Thema an die zuständige Abteilung weitergeleitet, damit es dort geprüft und gelöst werden kann.
Alles anzeigenHey Lars, danke für deine Antwort.
Sollte in dem Fall der Kunde nicht darüber informiert werden, dass es diese Möglichkeit bestünde? Insbesondere wenn er Firmenkunde ist und seine Rechnungen möglicherweise unter diesem System so archiviert?
Habt ihr keine Prüfziffern in den Rechnungsnummern?
Naja, ich sehe gerade die Rechnungsnummer könnte aus Juni 2022 stammen.
Hi H6G,
unsere Rechnungsnummern sind fortlaufend, wie vom Gesetzgeber gefordert, daher gibt es darin keine Prüfzimmer. Deine Anregung gebe ich an die zuständige Abteilung zur Prüfung weiter.
Edit: Moderatoren ist nc-2496474 eine gültige Rechnungsnummer?
Evtl. wurde dem Kunden ja das Mailkonto leergeräumt, habe da so einen Verdacht.
Wenn die schon den Betreff nicht ändern...
Hi H6G,
selbst wenn es sich dabei um eine echte Rechnungsnummer handelt, kann es sein, dass diese von der ursprünglichen E-Mail geändert wurde und zufällig erstellt wurde oder Ähnliches. Das Ganze muss also keinen Zusammenhang zu dem zugehörigen Kundenkonto haben, auch wenn das natürlich möglich ist. Auch in diesem Fall gibt es jedoch diverse Möglichkeiten, an welcher Stelle der Inhalt der E-Mail erlangt wurde (z.B. mit Schadsoftware, durch ein gehacktes E-Mail-Konto, usw.).
[netcup] Lars S. da du gerade online bist, magst du vielleicht das Bild von iKameo entfernen? Ich würd mich darüber freuen, wenn mir dieser "Fehler" passiert... Wer weiß wann iKameo es sieht...
Danke für deinen Hinweis, ich habe es erledigt.
Alles anzeigenMoin Leute, heute kommen mal wieder relativ viele Phsing Mails rein.
Moderatoren Ich habe die Mail schon mit Header an abuse@netcup.de weitergeleitet.
Der klickbare link führt zu einer .pt Domain mit referrer von meiner "betroffenen" Domain
Hallo iKameo,
danke für den zeitnahen Hinweis.
Wir leiten entsprechende Maßnahmen ein, um unsere Kunden zu warnen und bitten euch alle darum, wie gewohnt Acht zu geben bei zweifelhaften Nachrichten per E-Mail.
Sollte im rescue system (grml) eigentlich ipv6 out of the box funktionieren? Ich versuche gerade ein Problem für den Support nachzustellen und bräuchte dafür ipv6 im rescue system...
Hi Lukay,
standardmäßig wird im Rettungssystem keine IPv6-Adresse aktiviert, aber es sollte so funktionieren:
Mit einer Handvoll Webhostings und VPS sowie rund 50 Domains zähle ich mit Sicherheit zu den eher kleineren Kunden von netcup. Aber wieso wird trotzdem jede Bestellung manuell überprüft? Das muss für netcup doch ein maximaler Aufwand sein, jede einzelne Domain händisch freizuschalten?
Hallo Bud,
der Großteil der Bestandskunden-Bestellungen bei uns wird automatisch und ohne weitere manuelle Bearbeitung eingerichtet. In manchen Fällen ist das jedoch nötig (z.B. aus gewissen technischen Gründen, oder aus Gründen der Betrugsprävention). In diesem Fall erfolgt die Bearbeitung aber zu den meisten Tageszeiten innerhalb von wenigen Minuten.
Hi aRaphael,
danke für die Info.
Unsere Entwickler haben die Möglichkeit, diverse Protokolle zu prüfen, so dass ich davon ausgehe, dass diese es darüber nachvollziehen können.
Deinen Hinweis bezüglich der Entfernung aus dem Webhosting habe ich soeben weitergegeben, danke auch nochmals dafür
Alles anzeigenApropos domain...
Ich wollte gerade die DNS einer meiner domais auf einen neuen Server ändern und die ist komplett leer (bis auf den www cname)
Seltsamerweise liefert ein DNS-lockup die Records (soweit ich die in Erinnerung habe ) korrekt zurück und der Server ist auch über die domain erreichbar.
Die Einträge sind also noch aktiv, nur werden sie nicht mehr in der DNS-Verwaltung des CCP angezeigt
Hallo aRaphael,
danke für deine Meldung zu diesem Sachverhalt.
Ich konnte dein Ticket finden (auch wenn es einer anderen Kundennummer, als der in deinem Account hier zugeordnet war). Wir haben dazu auch ein Ticket bei unseren Entwicklern eröffnet, damit diese prüfen können, warum es dazu gekommen ist und den Fehler nachhaltig lösen können.
Bitte entschuldige die Umstände.
Hallo zusammen,
Debian 12 steht jetzt wie angekündigt auch als Image für eure Server im SCP bereit.
Bevor die Frage aufkommt:
Wir werden in absehbarer Zeit neue Server standardmäßig mit Debian 12 installieren, werden aber zuvor noch etwas abwarten, so dass diese aktuell noch mit Debian 11 eingerichtet werden.
Hallo zusammen,
Debian 12 steht seit heute Mittag als DVD im Servercontrolpanel zur Verfügung. Am Image wird aktuell gearbeitet und dieses wird zeitnah veröffentlicht.
KB19 Danke für deine Frage. Aktuell kann ich hierzu keine Neuigkeiten verkünden, da andere Features und Fehlerbehebungen bisher höher priorisiert wurden.
Hallo jay,
nein, selbstverständlich wollen wir den Sachverhalt nicht totschweigen, zumal das in Anbetracht der Tatsache, dass du hier öffentlich darüber berichtest, ohnehin nicht möglich wäre Wir behandeln aber selbstverständlich jede Anfrage zum Thema Datenschutz schnellstmöglich und mit entsprechender Sorgfalt, egal ob Kunden darüber öffentlich berichten oder nicht.
Ich habe soeben mit der zuständigen Abteilung gesprochen. Diese teilte mir mit, am 31.05. auf die Anfrage per E-Mail geantwortet zu haben.
Kannst du bitte nochmal prüfen, ob diese Antwort wirklich nicht bei dir eingegangen ist, auch nicht im Spam-Ordner o.ä.? Falls du sie nicht erhalten haben solltest, gib mir hier bitte nochmal eine kurze Rückmeldung. Wir lassen dann prüfen, ob wir diesbezüglich einen Fehler auf unserer Seite erkennen können und werden dir die Antwort erneut zukommen lassen. Vielen Dank.
Hallo Batmin,
vielen Dank für deinen Hinweis.
Der Sachverhalt ist uns bereits bekannt und es existiert ein internes Ticket dazu. Wir werden dieses entsprechend priorisieren und bearbeiten. Aktuell können diese Warnungen ignoriert werden.
Hallo jay,
vielen Dank für deine Nachricht.
Unter der Annahme, dass sich der Sachverhalt tatsächlich so dargestellt hat, wie von der Firma dir gegenüber beschrieben, kann ich dazu sagen, dass in diesem Fall selbstverständlich keinerlei Daten zu Kunden an Dritte weitergegeben werden dürfen. Dies ist nicht akzeptabel und verstößt auch gegen interne Richtlinien, die es für Anfragen dieser Art gibt und die eine Weitergabe von Daten an Dritte ausdrücklich untersagen.
Wir nehmen deine Schilderung sehr ernst und bitten dich daher darum, dich an unseren Datenschutzbeauftragten zu wenden. Diesen erreichst du per E-Mail unter data-protection@anexia-it.com.
Dies ermöglicht es uns, zu prüfen, ob der Sachverhalt sich so wie von dem Unternehmen dir gegenüber beschrieben abgespielt hat und weitergehende, interne Nachforschungen anzustellen. Sollte dies der Fall sein, können wir umgehend Gegenmaßnahmen ergreifen. Idealerweise nennst du uns bitte direkt bei deiner Kontaktaufnahme die Firma, die dich kontaktiert hat inkl. deren Kontaktdaten, insofern dir diese (z.B. aus der E-Mail an dich) vorliegen, damit wir intern bestmöglich den genauen Ablauf des Sachverhalts recherchieren können.
Vorbehaltlich der ausstehenden Klärung bitte ich für die entstandenen Unannehmlichkeiten um Entschuldigung und bin zuversichtlich, dass sich der Fall in Zusammenarbeit mit unserem Datenschutzbeauftragten aufklären lässt.