Beiträge von nagmat84

Du verpasst den Punkt. Es geht nicht darum, dass Delisting zu beantragen. Es geht darum, dass es eine Zumutung ist, überhaupt das Delisting beantragen zu müssen. Wenn man versehentlich, nachvollziehbar einmal alle Jubeljahre auf der Blocklist landet, wäre das noch akzeptabel. Hier liegt aber ein Fall vor, dass ich ungefähr alle sechs Wochen das Delisting erneut beantragend muss.

Ich persönlich habe so gut wie keine `outlook.de`/`outlook.com`/`hotmail.com`-Kontakte. Daher bekomme ich es selbst auch nicht immer zeitnah mit, wenn mein Server wieder Opfer eines Kollateralschadens geworden ist. Auf meinem VPS sind sechs Nutzer aktiv. Die übrigen Nutzer haben mehr Bekannte mit Microsoft-Konten. Ich bekomme dann nur ca. alle zwei Monate mitgeteilt, dass mein VPS mal wieder nicht funktionieren würde. Alle anderen Bekannten, die bei Microsoft, GMail oder Apple seien, hätten untereinander schließlich keine Probleme. Sprich: Microsofts Taktik, die ich hier unterstelle, geht auf. Angemerkt sei hier noch, dass eine Zustellung zu GMail oder Apple seit Anbeginn einwandfrei funktioniert; nur Microsoft blockt regelmäßig.

Ein Delisting bei Microsoft funktioniert in der Regel innerhalb von 48h, wenn man es selbst bei Microsoft beantragt, oder eher 4-5 Tage, wenn es über Netcup läuft. Gegen die Reaktionzeit beim Delisting kann ich mich nicht beschweren.

Das Problem ist jedoch, dass das Spielchen nach sechs Wochen wieder von vorne losgeht, einige Zeit anhält, weil ich es nicht zeitnah mitbekomme und damit für _mich_ (nicht für Microsoft) ein Reputationsschaden einhergeht.

Das Problem ist auch hinlänglich bei Netcup bekannt. Ich zitiere gekürzt aus der gestrigen Mail vom Netcup-Support:

Zitat

Guten Tag <...>,

vielen Dank für Ihre Nachricht.

Ihre Verärgerung verstehe ich. Die durchgeführten Blacklistings [...] sind für uns nicht nachvollziehbar. Bei Spam-Vorfällen in einem Webhosting reagieren wir schnell und strikt, da wir die Problematik gut verstehen. Wir überwachen unsere Systeme 24/7/365 auf diese Art von Situationen. Oftmals jedoch werden, trotz unserer massiven Anstrengungen, z.B. auch ganze IP-Blöcke gesperrt. [...] Leider ist das Ganze eine bekannte "Geschäftspraxis" seitens Microsoft, von der nicht nur wir, sondern mehrere, große Provider betroffen sind. Dies wurde auch schon von der Fachpresse berichtet: [https://www.heise.de/newsticker/mel…ls-3975197.html] [...] Weiterhin hat sich der Heise-Verlag auch einmal mit der globalen Thematik beschäftigt: [https://www.heise.de/newsticker/mel…en-4259518.html]

Wir sind uns der Tatsache bewusst, dass dies für unsere Kunden ein nicht tragbarer Zustand ist und sind daher schon seit geraumer Zeit im intensiven Dialog mit Microsoft. Leider stellt sich der Konzern in der Zusammenarbeit mehr als quer, [...] Auch diese Haltung wurde bereits online diskutiert: [https://community.spiceworks.com/topic/2075724-…tmail-blacklist]

[...]

Mit freundlichen Grüßen,

netcup Team

Alles anzeigen

Dieses "Querstellen" seitens Microsoft habe ich nun selbst erlebt. Das eigentliche Delisting ging relativ schnell und unproblematisch, aber warum es überhaupt zu der Sperrung kam und wie man gedenkt zukünftiges Overblocking zu vermeiden, wollte man nicht kommentieren. Nachdem das Delisting durch war, haben wir noch mehrfach Mails ausgetauscht, weil ich insistiert habe, dass das Delisting einen dauerhaften Effekt hat.

Hier auch wieder gekürzt, meine Nachricht an Microsoft:

Zitat

Dear [...] and Manjushri,

it appears that for the time being mail delivery from my mail server to the Microsoft mail servers works again. Hence, your mitigation show a (probably temporary), positive effect.

However, this does not answer my question: How do you ensure that this mitigation stays in effect *permanently*? I have to insist on that. Your practice of repeatingly overblocking mail servers at haphazard which are demonstrably of good standing is unacceptable. [...]

My mail server is a dedicated server which has not transmitted any spam mail since it exists. The mail server verifiably implements state-of-the-art anti-spam measures which even go beyond your own recommendations at <URL entfernt>. As you have confirmed yourselves my mails server (<IP>) itself hasn't been blocked. Hence, I must assume that you have blocked the entire IP range 202.61.192.0/18 or 2a03:4000::/32 or even the entire AS 197540.

As I wrote in my previous mail, this incident has been re-occurring several times. In each of the cases, my IP seems to have been a collateral victim due to your practice of overblocking entire network ranges. However, it appears as if any exemption from a block list only lasts until the next time the network range is blocked again.

I am considering to file a complain based on the European Digital Markets Act for the sector "communication platforms" and/or other applicable regulations. By not allowing to make permanent exceptions to your block list for inculpable mail servers you discriminate small providers and self-hosted solutions and abuse your market power as a "Gate Keeper" in a harmful and willful way. I strongly recommend you to find a lasting solution to this matter.

Die Antwort von Microsoft

Zitat

Hello,

Thank you for contacting the Outlook.com Deliverability Support Team.

I do apologize, but I am unable to provide any details about this situation since we do not have the liberty to discuss the nature of the block or our internal rules beyond those publicly documented at [URL entfernt]. Your IP ([IP entfernt]) has already been mitigated. We regret that we are unable to provide any additional information or assistance at this time.

Thanks again,

Das heißt Microsoft sagt im Wesentlichen, sie hätten Regeln an die man sich doch gefälligst halten solle, aber nur ein paar sind öffentlich dokumentiert und wieso und weshalb man darüber hinaus geblockt worden sei, würden sie nicht mitteilen. Das ist für mich ein nicht tragbarer Zustand. Ich nehme auch stark an, dass Microsoft es niemals wagen würde, GMail, Apple oder ähnliche große Anbieter so zu behandeln und mal hin- und wieder "versehentlich" zu sperren. Hätten wir eine stärker fragmentierte Provider-Landschaft und Microsoft würde sich so verhalten, dann würden Nutzer auch eher dazu tendieren, die Ursache Microsoft anzulasten, weil Microsoft-Kunden plötzlich keine Mails mehr empfangen könnten. Bei der vorliegenden Oligopol-Situation funktioniert so ein Verhalten. Aus meiner juristischen Laienperspektive ist das aber genau die Art von "Gate Keeper"-Verhalten, für die der DMA gemacht wurde.

Und nochmals: Ich bin noch nicht einmal Gegner von IP-Range-Blockaden. Falls ein Anbieter sich jedoch für diesen Mechanismus entscheidet, sollte zudem Mindestvoraussetzung sein, dass es eine Art permanente Allow List gibt, die verhindert, dass man wiederholt Opfer einer solchen IP-Range-Blockade wird. Es wäre auch akzeptabel, dass man von der Allow Liste wieder entfernt wird, sofern von dem Server selbst Spam ausgeht. Die Allow List wäre nur dazu da, um einer pauschalen IP-Range-Sperrung zu entgehen. Ziemlich offensichtlich hat Microsoft ja eine solche Liste, nur scheint die zurückgesetzt zu werden, wenn auch die Sperrung für den umliegenden IP-Bereich im ganzen aufgehoben wird.

Weiß jemand wo man eine Beschwerde gegen den DMA (Digital Markets Act) einlegen kann?

Am liebsten elektronisch, notfalls auch per altmodischer Post. Ich habe jetzt die Verordnung einmal komplett reingezogen und weiß, dass für die Durchsetzung ausschließlich direkt die EU zuständig ist, aber wo kann man eine Beschwerde/Hinweis/... einreichen? (Ich habe auch schon beim Bundeskartellamt nachgefragt, weil ich nach erfolgloser Suche gemutmaßt hatte, dass evtl. das BKartA als nationale Behörde dafür zuständig sein könnte, dort hat man aber nur mit den Achseln gezuckt.)

Hintergrund ist der Folgende:

Ich betreibe einen kleinen dedicated VPS bei Netcup mit nur einer handvoll von aktiv genutzten E-Mail-Konten. Mit schöner Regelmäßigkeit landet der gesamte Netcup-IP-Bereich 202.61.192.0/18, in dem sich auch mein VPS befindet, bei Microsoft (outlook.com, outlook.de, hotmail.com) auf der Blockliste. Ich selbst habe sämtliche State-Of-The-Art-Anti-Spam-Maßnahmen umgesetzt und gehe damit sogar über das Hinweis, was MS empfiehlt, um ein Blocking zu verhindern (Link habe ich leider gerade nicht mehr parat.) Das man bei Netcup häufiger als "Kollateralschaden" geblockt wird, ist bekannt. Dazu gibt es genug Threads auch in diesem Forum. Anfänglich habe ich mich über https://olcsupport.office.com/ delisten lassen. Auf Dauer nervt das aber, insb. weil man i.d.R. als erstes eine automatisierte Antwort erhält mit der Mitteilung, die eigene IP-Adresse sei nicht geblockt. Erst wenn man eskaliert und darauf hinweist, dass wahrscheinlich der ganze Netzbereich geblockt wurde, geht es dann doch. Ich musste dazu aber auch schon zwei-/dreimal sehr deutlich werden.

Offensichtlich ist es Microsoft also möglich, bei geblockten Bereichen einzelne IPs wieder als Ausnahme in eine Art "Allow List" zu setzen. Allerdings scheint dies nicht von Dauer zu sein. Denn nach ungefähr sechs Wochen geht das Spielchen von vorne los. Ich vermute, dass der Eintrag auf der Allow List nur solange bestehen bleibt, wie auch der zugehörige IP-Bereich beblockt ist. Sobald aber der gesamte IP-Bereich wieder freigegeben wurde, wird auch der Ausnahmeeintrag entfernt und wenn dann beim nächsten Mal wieder der IP-Bereich gesperrt wird, ist man erneut mitbetroffen.

Ich tendiere daher dazu Beschwerde gegen Microsoft einzureichen auf Basis der DMAs. Ich habe mit keinem anderen der großen Mail-Anbieter solche Probleme. Insbesondere deren Hinweise, man könne doch auch einfach Microsoft als Mail-Anbieter nutzen und alles nach outlook.com migrieren, um das "smooth/trouble-free/undisturbed mail experience" zu haben, hinterlässt bei mir den Eindruck, dass Microsoft dies durchaus absichtlich macht, um kleine Mail-Anbieter oder self-hosted Mailer unattraktiv zu machen. Spambekämpfung ist wichtig, aber wenn Microsoft wollen würde, könnte Microsoft durchaus eine permanente Allow List pflegen. Das darf gerne auch an Vorbedingungen geknüpft sein, dass man selbst bestimmte Anti-Spam-Maßnahmen umgesetzt hat. So wie es momentan aber abläuft, drängt sich bei mir der Eindruck auf, dass Microsoft eine "Gate Keeper"-Funktion ausübt, bei der die anderen großen Mailanbieter bevorzugt, aber kleine Anbieter bzw. Self-Hosting-Lösungen diskriminiert werden.

Mir ist auch bewusst, dass wahrscheinlich am Ende nichts dabei herauskommt und die Sache im Sande verläuft. Da steckt dann auch für mich viel Arbeit drin. Wenn man es aber zumindest nicht versucht, ändert sich auch nichts. Also wo würde man eine Beschwerde einreichen?

Hallo,

hat auch jemand Probleme sich in das CCP einzuloggen? Ich probiere es seit zwei Monaten zum ersten Mal wieder. Zuvor hat es immer funktioniert. Kundennummer und Passwort werden akzeptiert. Dann erscheint das Dialogfeld zur TAN-Eingabe. Ich gebe die TAN ein, werde zurück auf die Login-Seite geleitet und erhalte die Meldung "Fehler bei Verarbeitung der Daten". Hat noch jemand anderes das Problem? Was kann das sein?

Gruß und Danke

PS: Ich habe auch Zwei-Faktor-Authentifzierung für das Kundenforum aktiviert und hier kann ich mich nachwievor einloggen wie man sieht.

Hi everyone,

hopefully, the collective expertise of the forum can help me to settle the issue, because I don't know what else to do.

I have a virtual Netcup root server RS 4000 G9.5 in Nuremberg, some hosted storage space located in Helsinki from a different provider and I use Borg Backup to backup my data from the virtual root server. My problem: The backup is slow as hell. However, I am not able to find the root cause. I don't know whether the problem is I/O (disk) bound, CPU bound or network bound. No matter at what monitor statistics I look, each tells me that neither of the limits is the problem, but still the backup is slow.

Command to create Borg archive:

borg create                                                                                 \
  --compression none                                                                        \
  --exclude-if-present '.nobackup'                                                          \
  --keep-exclude-tags                                                                       \
  --exclude-from '/etc/borgbackup/exclude.conf'                                             \
  ssh://u377394@backup.mhnnet.de:23/~/borg-backups::'{hostname}-{utcnow:%Y-%m-%d_%H:%M:%S}' \
  /etc                                                                                      \
  /home                                                                                     \
  /usr/local                                                                                \
  /var/backup/data                                                                          \
  /var/lib/portage/world                                                                    \
  /var/spool/mail/                                                                          \
  /var/www

Note: I use no compression on purpose as most data (in /var/www) is highly compressed data (e.g. JPEGs) anyway. (It is mostly a Nextcloud installation.)

While the backup is running

• htop shows 4.6% CPU utilization on one core for python-3.11/borg
• iotop sporadically shows 3.5MB/s disk utilization on /dev/vda3 for python-3.11/borg
• wireshark shows me 9.8MBit/s network utilization on enp0s3ad

Neither of these numbers is near the theoretically maximum.

To find out the maximum disk I/O, I ran

root@server ~ $  fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.34
Starting 1 process
test1: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=132MiB/s,w=43.1MiB/s][r=33.8k,w=11.0k IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=12416: Sat Dec  2 14:17:57 2023
  read: IOPS=38.6k, BW=151MiB/s (158MB/s)(3070MiB/20384msec)
   bw (  KiB/s): min=40160, max=332584, per=100.00%, avg=155611.50, stdev=81780.78, samples=40
   iops        : min=10040, max=83146, avg=38902.93, stdev=20445.29, samples=40
  write: IOPS=12.9k, BW=50.3MiB/s (52.8MB/s)(1026MiB/20384msec); 0 zone resets
   bw (  KiB/s): min=13416, max=109768, per=100.00%, avg=52001.53, stdev=27407.36, samples=40
   iops        : min= 3354, max=27442, avg=13000.38, stdev=6851.83, samples=40
  cpu          : usr=9.30%, sys=32.49%, ctx=134727, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=151MiB/s (158MB/s), 151MiB/s-151MiB/s (158MB/s-158MB/s), io=3070MiB (3219MB), run=20384-20384msec
  WRITE: bw=50.3MiB/s (52.8MB/s), 50.3MiB/s-50.3MiB/s (52.8MB/s-52.8MB/s), io=1026MiB (1076MB), run=20384-20384msec

Disk stats (read/write):
  vda: ios=784345/262272, merge=0/91, ticks=1006159/184131, in_queue=1190487, util=99.08%

This tells me that the theoretical read performance of the disk is 151MiB/s. Yes, I know that traversing many files in a directory tree is slower than writing a single huge in large chunks, but 3.5MB/s is very far below 151MiB/s.

To find out the maximum network throughput between my server and the remote storage, I created a file with randomness, copied it over with scp and analyzed the result with Wireshark.

On one console I did

admin@server ~ $ tcpdump -i enp0s3 -s 86 -w /dev/shm/scp-to-backup.pcap "ip6 host 2a01:4f9:3b:5682::2 and tcp port 23"
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 86 bytes
442415 packets captured
442415 packets received by filter
0 packets dropped by kernel

Notes: I only dumped the first 86 bytes of each packet which is the size of the combined Ethernet, IPv6 and TCP header to avoid capturing the entire payload. The IP address 2a01:4f9:3b:5682::2 belongs to backup.mhnnet.de

On another console I did

backup@server ~ $ openssl rand -out /dev/shm/sample.txt -base64 $(( 2*2**30 * 3/4 ))
backup@server ~ $ scp -P 23 /dev/shm/sample.txt u377394@backup.mhnnet.de:/home/sample.txt
sample.txt   100%   2080MB   45.7MB/s   00:45

Here, we see 45.7MB/s and not 9.8MBit/s which I get when Borg Backup is running. The latter is 37 times slower! (Note bytes vs. bits). Also Wireshark shows me a nice 400 (4x10^8) MBit/s which is actually the theoretical maximum between Netcup and the other data center in Finland.

Screenshot_20231217_172721.png

So what makes Borg Backup so incredibly slow? Has anybody any clever ideas what to investigate next?

Zitat von KB19

Die 26 Euro klingen sehr nach einem Netto-Preis! (€ 31,58 sind € 26,54 exkl. MwSt.)

Vermutlich war der vorherige Inhaber ein Geschäftskunde? Dementsprechend stand bei der Übernahme in der Zeile wahrscheinlich auch kein "(inkl. in XX geltender MwSt.)" dabei.

Kann sein. Lässt sich jetzt leider nicht mehr feststellen.

Zitat von aRaphael

Nein. Du bekommst zwar nichts zurück, aber der neue Inhaber zahlt auch erst die nächste Rechnung ab der nächsten Abrechnungsperiode ab März. Der Vertrag läuft wie bisher weiter, nur mit einem neuen Inhaber.

Das mit dem "Nicht zurückerstatten", bezieht sich nur auf Zufriedenheitsgarantie/Widerruf und schon gezahlte Leistungen. Da bekommt der neue Besitzer nichts zurück. (Sonst ordere ich 50 dicke Server, übertrage sie dir und du lässt sie zurückgehen und kassierst das Geld = Geldwäsche)

OK. Das macht Sinn.

Allerdings ließe sich Geldwäsche auch durch exaktes Abrechnen unterbinden. Netcup müsste dazu dem Vorinhaber die im Voraus zu viel bezahlten Gebühren zurückerstatten und dem Nachinhaber ab dem Moment des Inhaberwechsels die Gebühren in Rechnung stellen. Aber ich sehe auch, dass dies zu viel Arbeit auf Seitens Netcup wäre. Ist schon gut, dass Netcup überhaupt einen Inhaberwechsel ermöglicht.

Danke für alle Antworten. Meine Frage ist damit geklärt.

Hallo zusammen,

ich habe vor Kurzem einen RS 4000 G9.5 SE TT23 per Inhaberwechsel übernommen. Dummerweise habe ich mir den Text, der vor Abschluss des Inhaberwechsels erschien, nicht kopiert. Ich erinnere mich nur daran, das dieser Text Informationen darüber enthielt, dass Netcup irgendwelche Kosten nicht zurückerstatten würde und dies wurde mit dem Risiko von Geldwäsche begründet. Hat jemand noch diesen Text und kann ihn hier posten?

Außerdem habe ich einige Fragen zum Ablauf beim Inhaberwechsel und wer welche Kosten trägt.

Ich habe den RS 4000 G9.5 SE TT23 übernommen, weil er als Special Edition 2 TB Speicher hat und einen individuell vereinbarten monatlichen Preis von irgendetwas um 26€ hätte haben sollen. Als Neuinhaber zahle ich aber den regulären Preis von 32€. Das macht den Server für mich trotz 2GB wieder unattraktiv und war für mich auch überraschend. (Ist allerdings auch etwas logisch, weil der individuell vereinbarte Preis für die Special Edition anscheinend nur individuell für den Erstinhaber gilt.)

Die Mindestvertragslaufzeit des RS ist 12 Monate. Der Vorinhaber hatte den RS zum 30.05.2023 bestellt. Durch den Inhaberwechsel hat sich die Laufzeit nicht verlängert, sodass auch für mich der früheste Kündigungstermin der 29.05.2024 ist.

Ich musste für den RS nun bereits die kommenden drei Monate (Dez '23 - Feb' 24) im Voraus bezahlen. Was passiert nun, wenn ich den RS per Inhaberwechsel wieder abstoße und bspw. einen Nachfolgeinhaber z.B. ab Januar finden würde? Wer zahlt dann welche Gebühren? Wenn ich den oben erwähnten Hinweis richtig erinnere, bekomme ich meine Gebühren nicht mehr zurück, aber der neue Inhaber zahlt dann trotzdem bereits ab Januar. Korrekt?

Only recently, I got myself a VPS 4000 G10. Now there are some question regarding the root file system of my upcoming Linux installation.

a) Am I assuming correctly that RAID 10 is already handled for me by the underlying host system? From the guest system I only see a single "hardware" (i.e. actually virtual) hard drive disk.

b) Are there any recommendations whether ext4 or XFS should be use? I assume the underlying host system uses ZFS. Has ext4 or XFS on top of a virtual disk stored on ZFS any known weaknesses, draw backs or disadvantages (let it be in efficiency)?

c) I have read that the block size of ext4/xfs should match the block size of the underlying host fs to avoid efficiency penalties. I assume Netcup uses 4k blocks for ZFS. Is that somewhere documented?

d) Are there other parameters (like the block size avove) that should be taken care of and aligned to the underlying host fs when creating the guest fs?

Bests, Matthias

Hallo zusammen,

ich bin quasi soetwas für der "Familien- und Verwandschaftsadmin". Auf meinem VPS betreibe ich diverse Nextcloud-Instanzen für unterschiedliche Domains mittels Virtual Hosting.

Gibt es eine Möglichkeit bei Netcup .de-Domains zu registrieren, sodass diese in meinem CCP-Portal erscheinen, damit ich diese administrieren kann, aber der "materiell Berechtigte" im DENIC-Deutsch, also der rechtliche Eigentümer, jemand anderes, in diesem Fall mein Vater, ist? Ob die Rechnung für die monatliche Registriergebühr dann auf mich ausgestellt ist oder meinen Vater wäre mir einerlei.

Im Grund gibt es drei verschiedene "Rollenfunktionen" und optimalerweise ließen sich diese im CCP getrennt verwalten:

• der technische Administrator/Verwalter der Domain: ich
• der Rechnungsadressat der Domain
• der Eigentümer der Domain: z.B. mein Vater

Und bevor jemand vorschlägt, ich sollte doch einfach unterschiedliche Kundenkonten für das CCP nutzen. Das wird auch chaotisch, weil ich dann mit vier CCP-Konten jonglieren müsste. Außerdem wäre das auch nicht 100% sauber, weil ich dann die Zugangsdaten zu Kundenkonten hätte, die mir offiziell nicht gehören würden, ich also de facto unter fremden Namen handeln würde.

Hallo zusammen, insb. liebe Netcup-Produktmanager,

ich bin auf der Suche nach einem VPS und habe leider bislang nicht die für mich optimale Konfiguration finden können. Daher poste ich einfach mal, was ich so suche. Vielleicht geht es auch anderen Kunden so wie mir und der ein oder andere Netcup-Produktmanager liest hier mit.

Ich betreibe einen VPS (derzeit noch nicht bei Netcup) zur Datensynchronisation und Sharing für meine Familie und Verwandtschaft, im wesentlichen aus Datenschutzgründen und um nicht von Google/Apple/Microsoft abhängig zu sein. Bei allen VPS-Angeboten hapert es letztlich am Speicherplatz für Dateien bzw. viel Speicherplatz gibt es dann nur in Zusammenhang mit viel CPU/RAM-Leistung, was aber nicht unbedingt benötigt wird bzw. dann auch zu teuer ist für eine rein private Nutzung.

Hier meine Setup:

• Basisdienste
  • OpenLDAP 2.6
  • PostgreSQL 15
  • PHP FPM 8.2
  • Redis 7.0
• Maildienste
  • Postfix 3.8 mit
    • rspamd 3.6
    • clamav 1.0
  • Dovevot 2.3
• Apache mit
  • Nextcloud (für Dateisynchronisation, Kalender, Kontakte und Webmail)
  • Lychee (für Photos)

Genutzt wird das ganze von sechs Personen mit durchschnittlich 2-3 Geräten (Laptop/Smartphone/Tablet), d.h. es sind ca. 12-15 Clients, die auf die Services zugreifen. Von der benötigten Rechenleistung würden ca. 4 Cores und 8 GB RAM ausreichen. Problematisch ist die Datenmenge. Derzeit sind es 1,2 TB insgesamt.

Von der Rechenleistung würde etwas in der Klasse eines VPS 1000 G10 sicherlich locker ausreichen. Er bietet aber nur 160GB Storage. Auf der anderen Seite gibt es den S 2000 G7. Dieser bietet 3TB Storage, ist dann aber doch etwas schwachbrüstig. Mir ist bewusst, dass ich auch beide kombinieren und über ein VLAN zusammenschalten kann, aber für eine rein private Nutzung ist das preislich sehr unattraktiv.

Aus meiner Sicht fehlt im Portfolio ein Produkt, dass zwischen den VPS und den Storage-Servern angesiedelt ist. Gerne kann der Storage auch aufgeteilt sein in eine SDD, die nur um die 100GB hat, eine (langsamere) SATA/SAS HDD im TB-Bereich. Dann ließe sich auf der SDD das OS, die Dienste und auch die DB ablegen, aber die Datenverzeichnisse lägen auf der HDD.

Derzeit liebäugle ich mit Eurem Blackfriday-Deal am 24.11.2023 für den RS 4000 G9.5 SE mit 1TB extra. Mit 2TB hätte dieser ausreichend Storage, aber an sich ist er mit 10 dedizierten EPYC-Kernen und 32 GB RAM etwas überkandidelt für meine Anwendung. Ein Drittel der Compute-Power und dafür günstiger, wäre ein Träumchen. Nur so als Gedankenanregung.

Zitat von [netcup] Alexander W.

Wir sind mit Hochdruck dran die DNSSEC Themen ein für alle mal zu fixen. Bitte gebt uns noch ein wenig Zeit.

Gibt es einen Zeitplan, bis wann die Fehler behoben sein sollen? Die Fehler scheinen teilweise schon Jahre alt zu sein. Reden wir von ein/zwei Monaten, einen halben Jahr oder erst in fünf?

Zitat von nagmat84

Aber dass Netcup hier einen einzelnen RRSIG-Record falsch erstellt, andere RRSIG-Record aber korrekt hinbekommt, verheißt nichts Gutes. Das klingt nach einen typischen indeterministischen "Heisenberg-Bug". Wer garantiert, dass beim nächsten Mal, wenn ich die DNS-Zone bearbeitet, wieder "nur" der Signatureintrag zu etwas unbedeutenden wie NSEC3PARAM kaputt gerechnet wird, der für exotische Client-Applikationen benötigt wird, und nicht mal was wichtigeres wie ein A, AAAA, MX usw. Eintrag betroffen ist?

Ich hätte es nicht beschreien sollen. Ich habe soeben die TTL-Werte von 180s wieder auf "vernüftige" Werte im Stunden und Tagesbereich hochgesetzt, weil ich mit Testen fertig war und alle DNS-Einträge zu meiner Zufriedenheit waren. Also habe ich neue TTL-Werte eingetragen, ein Update angestoßen und nun ist die Signatur zum SOA-Record kaputt. Arghhh!

Ich wollte ressourcenschonend sein, denn DNS-Einträge ändern sich nicht alle naselang und ich habe

mhnnet.de.   14400   IN   SOA   root-dns.netcup.net.   ;  4h (TTL for SOA)
                                dnsadmin.netcup.net.
                                          2023111518
                                               86400   ; 24h (refresh from primary to secondaries)
                                                7200   ;  2h (retry if refresh fails)
                                              259200   ;  3d (expiration)
                                               14400   ;  4h (minimum TTL for any record)

verwendet.

Jetzt muss ich "irgendwas" in der Zone ändern, damit es ein neues Update gibt und Netcup hoffentlich dann die Signaturen wieder richtig rechnet. Aber wenn es jetzt blöd läuft, kann es bis zu 24h dauern, bis die neuerliche Änderung durch das DNS-System durchpropagiert ist. Bis dahin könnten manche Clients eine kaputte SOA-Signatur sehen. Grmph. Wieso habe ich es nur weisgesagt.

Es handelt sich in der Tat um einen Fehler seitens Netcup beim Signieren und Erzeugen des zugehörigen RRSIG Records für den Record NSEC3PARAM. Es ist ein Bug und ich hoffe Netcup liest hier mit bzw. ich werde im Nachgang einen Bug Report mit Verweis auf diesen Post an Netcup schicken.

Zitat von heppel

Also eine TTL von 0 und nicht 180, wie von Dir angegeben. Das ist bei meinen Resolvern so. Ebenfalls bei 8.8.8.8 und 8.8.4.4. Allerdings liefern 1.1.1.1 und die Netcup-Server eine TTL von 180. Dnsviz sieht wohl auch die TTL von 0. Wo die falsche TTL her kommt, ist mir unklar. Das Flushen meiner Caches hat nicht geholfen.

Das Du bei Caching Resolvern eine kleinere TTL erhältst als beim Name Server, der autoritative für die Zone ist, ist normal. Ein Caching Resolver trägt die Rest-TTL ein, die zum Zeitpunkt des Zonentransfers noch gültig war. Siehe weiter unten, das wird noch wichtig. Für die Fehleranalyse ist es daher notwendig, den authoritive Name Server direkt anzufragen, wenn man die ursprüngliche TTL erfahren möchte.

Screenshot:

Screenshot_20231115_175553.png

Der NSEC3PARAM Resource Record für mhnnet.de hat eine TTL von 180s (vgl. erster pinker Kreis). Die Signatur ist in einem zugehörigen RRSIG Record für mhnnet.de und NSEC3PARAM hinterlegt.

Ein RRSIG Record ist grundsätzlich wie folgt aufgebaut

<Name> <TTL> IN RRSIG <Original Type> <Sig-Algo> <count of labels> <Original TTL> <validity end> <validity begin> <key id> <issuer name> <signature value>

Wir haben

• Name = mhnnet.de
• TTL = 180 (Standardwert für alle TTL in der Zone)
• Original Type = NSEC3PARAM (Typ des Eintrags der signiert wird)
• Signature Algo = 8 (RSA/SHA-256)
• Count of Labels = 2 (weil "mhnnet.de" aus zwei Namensbestandteilen besteht)
• Original TTL = 0 (Hier ist der Bug, dass müsste 180 sein!)
• Rest sollte klar sein

Wichtig ist hier zu unterscheiden zwischen der TTL des RRSIG Records selbst und der Original TTL. Ersteres gibt an, wie lange der RRSIG Record gültig ist. Der Wert ist im Folgenden egal. Die Original TTL muss den Wert der TTL des zu signierenden Resource Records enthalten. In diesem Fall also die TTL des zu signierenden NSEC3PARAM Records. Dieser ist 180 (erster pinker Kreis), aber Netcup trägt für Original TTL konstant eine Null ein (zweiter pinker Kreis).

Der korrekte ursprüngliche TTL-Wert wird zwingend benötigt, um den Signaturwert korrekt verifizieren zu können. Die Signatur wird über den gesamten zu signierenden RRSIG Record erstellt, in dem 180 steht. Wie heppel bereits festgestellt hat, erscheint an dieser Stelle bei Caching Resolvern mitunter ein kleinerer Wert. Damit nun eine Instanz, die die Signatur prüfen will, die Signatur korrekt nachrechnen kann, muss der originale TTL-Wert mitgeteilt werden. Dafür dient Orig-TTL. Aus dem RFC 4034, Sec. 3.1.4:

Zitat

The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone. The Original TTL field is necessary because a caching resolver decrements the TTL value of a cached RRset. In order to validate a signature, a validator requires the original TTL.

Zusammenfassung: Beim Erzeugen des RRSIG Record baut Netcup Mist. Anstatt den richtigen TTL-Wert aus dem zu signierenden Record einzutragen, trägt Netcup hier eine Null ein. Interessanterweise bekommt es Netcup aber bei den anderen RRSIG Records für die übrigen Einträge korrekt hin.

Zitat von tab

Naja, was ich dir ziemlich sicher sagen kann, das ist kein Fehler, der [...] die Auflösung verhindert. Den Fehler habe ich hier bei netcup schon, seit ich Domains mit netcup Nameservern auf dnsviz anschaue. Noch nie eine solche Domain auf dnsviz.net gecheckt, wo der Fehler nicht gekommen wäre.

Das ist insofern richtig, weil nur die Signatur zum NSEC3PARAM-Eintrag kaputt ist. Die Signaturen für die Einträge, die "üblicherweise" von Clients abgefragt werden (z.B. A, AAAA, CNAME, MX usw.) sind in meinem Fall korrekt berechnet. Aber dies ist trotzdem ein Bug, der gefixt gehört. Es müssen alle Einträge korrekt signiert werden!

Zitat von tab

Ich bin in dem DNSSEC-Thema zu wenig drin, aber was man jedenfalls finden kann, ist z.B.dieser Issue:https://github.com/dnsviz/dnsviz/issues/91

Da wird zumindest behauptet, dass es keinerlei praktische Bedeutung hat.

Klares jein. Ich habe mir mittlerweile auch andere RFC zu DNSSEC durchgelesen. Der Record NSEC3PARAM dient dazu, kryptographisch die Nicht-Existenz von Einträgen zu beweisen. Das ist sicherlich ein exotischer Anwendungsfall. Mir fällt spontan auch keine Client-Software ein, die einen Beweis für die Nicht-Existenz eines Eintrags sinnvollerweise benötigen würde.

Aber, dass Netcup hier einen einzelnen RRSIG-Record falsch erstellt, andere RRSIG-Record aber korrekt hinbekommt, verheißt nichts Gutes. Das klingt nach einen typischen indeterministischen "Heisenberg-Bug". Wer garantiert, dass beim nächsten Mal, wenn ich die DNS-Zone bearbeitet, wieder "nur" der Signatureintrag zu etwas unbedeutenden wie NSEC3PARAM kaputt gerechnet wird, der für exotische Client-Applikationen benötigt wird, und nicht mal was wichtigeres wie ein A, AAAA, MX usw. Eintrag betroffen ist?

Ich habe DNSSEC für meine Domain aktiviert. Die "meisten" DNSSEC-Analyzer sind glücklich (DNSSEC Analyzer, SSL Tools) und auch andere Mail-Server sind mit meinen DANE-Einträgen zufrieden.

Bei DNSViz erhalte ich jedoch die Fehlermeldung:

RRSIG mhnnet.de/NSEC3PARAM alg 8, id 37935: The TTL of the RRset (180) exceeds the value of the Original TTL field of the RRSIG RR covering it (0).

Ich bin kein DNSSEC-Profi. Was bedeutet diese Fehlermeldung? Oder ist das ein False Positive und ist das Ergebnis bei DNSViz einfach falsch?

Alle RR haben bei mir momentan die minimal mögliche TTL von 180s. Bei den betroffenen Fällen habe ich

mhnnet.de.              180     IN      DNSKEY  257 3 8 AwEAAcXNH+ECVOdLRnR5bewh2C/M0C7F+jdWb7KuK2EqRrjUgvdv51ZR MvmTrCPmJ+bKn+ucFLCuaG/B6nWBcmytC0nKllUrTLYVYaKeI2RXwEka bFzgsBbkY2h90aRPKFzazUN1rumJh1UdwNRccTSzEZGUN6iiNnrgm54Q 2CVqKhrzTN
LYypYiACF4pBbAQfIyj2lmwneZwdi4J7UfzA2PMHY6v33u Bu/4U84gHBv+u6wK8e698+8sufdAiduvR8FTMOQCDRcUQnlf02ELP9Fr 2y6d/gxwjRKZiXVE59VCLqa3yCOiVg8LYVoyHxhnT+d5Z23H3P+DfDh2 2QG4F+9fWP8=
mhnnet.de.              180     IN      DNSKEY  256 3 8 AwEAAahpb+4SJ/gSt4Vb9x4MwqX0nvnUxt0kjESnM/aOnWdJfOtlVhs4 r7x+ireDVyCcVodLIQGkm4WzhgKNjG4FZaE7VV4WFqXjC6KL5UJdVBiE W4tY3Ej+TxNMWDUWeA7ZAPLJBDWdwDjobd/5Xy9AoFvDjidEL6vBRcMv 86ooES6H
mhnnet.de.              180     IN      NSEC3PARAM 1 0 100 73D66FE98D54FC17

Daher kann ich aber die Aussage, dass die TTL die Original TTL übersteigen würde nicht nachvollziehen.

PS: Ich bin noch am Testen und sobald alles stabil läuft, wird die TTL von 180s wieder auf angemessene Werte hochgesetzt.

Hat sich erledigt. Man muss nur meckern, dann entscheidet das Universum, dass es klein bei gibt.

Ich habe eine .de-Domain über Netcup registriert. Im CCP habe ich DNSSEC für meine Domain aktiviert. Für ein funktionierendes DNSSEC, müssen in der .de-Zone neben den NS auch die DS Resource Records als "Glue Records" für meine Domain existieren.

Ich habe nun gelernt, dass als Besonderheit bei der DENIC in der .de-Zone nicht nur die DS Resource Records eingetragen werden, sondern DNSKEY Resource Records, die den gesamten Key enthalten und die DENIC erzeugt daraus die notwendigen DS Resource Records selbst.

Wie lange dauert dieser Vorgang üblicherweise? Nachdem ich im CCP DNSSEC aktiviert hatte, hat es keine 30min gedauert, bis die DNSKEY Resource Records für meine Domain in der .de-Zone enthalten waren, die DS Resource Records fehlen aber noch. Wie lange dauert es üblicherweise, bis auch die DS Resource Records existieren?

Intuitiv hätte ich erwartet, dass beide simultan eingetragen werden, also Netcup meldet den DNSKEY Resoruce Record per API-Call an die DENIC, die DENIC berechnet den Wert für den DS Resource Record und trägt sowohl DNSKEY als auch DS Record gleichzeitig ein. Scheint aber wohl nicht so zu sein. Wie lange sollte man warten, bis man man davon ausgehen sollte, dass irgendetwas schief gelaufen ist?