Beiträge von [netcup] Lars S.

Hallo epi,

bei einem Upgrade deines Reseller-Webhosting-Tarifs über unser CCP ändert sich der Server nicht, wir weisen dem Produkt darauf lediglich mehr Ressourcen zu. Demzufolge müssen deine Kunden nichts neu konfigurieren.

Zitat von tsc23

Moderatoren

Falls ihr das DynDNS Script für die Mikrotik Router in eurem Wiki verlinken möchtet, könnt ihr das gerne tun

Hier noch mal der Link:

https://github.com/toscdesign/netcup-ddns-for-mikrotik

Hallo tsc23,

danke, gerne fügen wir deinen API-Client zeitnah unserem Help Center hinzu.

Hallo Real-DD-2,

wir haben mit Autodiscover in der Vergangenheit wechselhafte Erfahrungen gemacht, das gezeigte Verhalten der Clients unterschied sich zum Teil je nach Version deutlich. So gab es z.B. auch Fälle, bei denen die Clients durch das Vorhandensein von Autodiscover-Daten ein Verhalten gezeigt haben, welches die Einrichtung im Vergleich zum Nichtvorhandensein erschwert hat. Daher unterstützen wir aktuell Autodiscover offiziell nicht (jedoch Autoconfig, was z.B. von Thunderbird und anderen E-Mail-Clients genutzt wird). Wir werden deinen Beitrag aber zum Anlass nehmen, dies nochmals zeitnah zu evaluieren.

In der Zwischenzeit empfehlen wir die manuelle Konfiguration des E-Mail-Clients gemäß der Anzeige im Webhostingpanel. Sollten diesbezüglich Rückfragen bestehen, hilft dir unser Support unter mail@netcup.de gerne weiter.

Zitat von chrisch80

Moderatoren : Wäre sowas möglich das man Mails nicht doppelt bekommt?

Hallo chrisch80,

vielen Dank für deinen Vorschlag.

Grundsätzlich handelt es sich dabei erst einmal, wie auch schon hier im Thread diskutiert, um "normales" Verhalten. Ob es erwünscht ist, kommt sicherlich auf den Grund für die Duplikate und den jeweiligen Anwender an.

Ich werde aber intern prüfen lassen, ob wir an diesem Verhalten etwas ändern können. Einen zeitlichen Horizont für eine etwaige Umsetzung kann ich jedoch zum aktuellen Zeitpunkt nicht mitteilen. Danke für dein Verständnis.

Zitat von adrianer

Hallo [netcup] Lars S. ,

email ist gerade raus.

Hi,

danke, wir haben diese erhalten und sie liegt der zuständigen Abteilung vor. Diese antwortet dir schnellstmöglich.

Zitat von tab

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.

Zitat von KB19

[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.

Zitat von mainziman

Moderatoren

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

traceroute[6] -I shinkansen.host

Code

[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 ~]#

Alles anzeigen

aber hier die andere Richtung von Nürnberg [shinkansen.host] nach Wien [6in4gate.tunnel], ebenfalls IPv4/IPv6

traceroute[6] -I 6in4gate.tunnel

Code

[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 ~]#

Alles anzeigen

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;

iperf3 [-4|-6] -c 6in4gate.tunnel -R

Code

[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 ~]#

Alles anzeigen

Alles anzeigen

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.

Zitat von H6G

Hey 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.

Zitat von H6G

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.).

Zitat von Bud

[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.

Zitat von iKameo

Moin 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

forum.netcup.de/system/attachment/10916/

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.

Zitat von Lukay

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:

• Name der NIC mit ip a bestimmen (z.B. ens3)
• IPv6-Adresse hinzufügen: ip -6 addr add IPv6-Adresse/64 dev <NIC-Name>
• Default-Gateway hinzufügen: ip -6 route add default via <Default-GW aus dem SCP (z.B. fe80::1)> dev <NIC-Name> (die ggf. erscheinende Meldung "RTNETLINK answers: File exists" kann ignoriert werden)

Zitat von Bud

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

Zitat von aRaphael

Apropos domain...

Ich wollte gerade die DNS einer meiner domais auf einen neuen Server ändern und die ist komplett leer (bis auf den www cname)

pasted-from-clipboard.png

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.