Automatische Neueinträge sollten die kürzest vertretbare ttl haben und nicht die viel zu hohen die hier gesetzt werden.
Guter Hinweis bzgl. der TTL! Für das alte DNS-System wäre es daher vermutlich nicht (mehr) sinnvoll. Aber beim neuen CloudDNS kann die TTL pro Record definiert werden, so daß man für den Null-MX einen sehr kurzen Wert setzen könnte. Bei meiner Domain mit CloudDNS steht bei den Standardwerten (für Domainparker und Webhosting) hier bei jedem Eintrag 3600.
Es scheint daher möglich zu sein, dass netcup inzwischen den Namen bzw. die Bezeichnung des Angebots geändert hat, während die interne Produktbezeichnung weiterhin den ursprünglichen Namen verwendet.
Ja, die Bezeichnungen (für Neubestellungen) haben sich heute im Zusammenhang mit der Preisanpassung geändert. Siehe RAMpocalypse: We need to talk about pricing ... again
Hier wurde der Platzhalter nicht durch den Namen der VM ersetzt:
notification-vm-name.png
Wow, der Mitbewerber mit I hat schon wieder die Preise erhöht!?
Vor ein paar Monaten lag ein VPS mit 4C,4GB,120GB noch bei 4,50 Euro, danach wurde der Preis auf 9 Euro verdoppelt und jetzt liegt er bei 12 Euro im Monat - also diesmal nicht erneut verdoppelt, dafür wurde die Anzahl der Cores halbiert...
Es steht aber noch immer "unschlagbar günstig" drüber. Na dann. 
Kein Wunder, daß bei netcup steht "Aufgrund des aktuell erhöhten Aufkommens kann sich die Bereitstellung des Produktes etwas verzögern."
Da wird man eher einen Hinweis darauf geben, dass man die Daten von Hand eingeben soll (wenn es den nicht schon gibt).
Einen Hinweis habe ich nicht gesehen.
Auch wenn es kleinlich erscheinen mag, aber meiner Meinung nach sollte in der UI und der Doku "Public IP Addresses" verwendet werden statt "Public IP(s)". Umgangsprachlich benutzen wir gerne mal "IP" statt "IP-Adresse", weil es oft bequemer ist, aber in "offiziellen Dokumenten" würde ich es immer ausschreiben.
public-ip-menu.png
In den Beispielen auf der folgenden Seite wird noch target_ip verwendet: https://docs.eoscloud.io/products/howto…oy_a_webserver/
Aktuell kann man eine ACL nur vom Netzwerk aus dem Netzwerk zuordnen und ein Volume einer VM nur auf der VM-Seite. Ich fände es gut, wenn man das auch andersherum könnte. Nachdem man ein Volume erstellt hat, ist man auf der Seite mit den Volumes. Da wäre es doch praktisch, wenn man dort auch direkt die VM zuordnen könnte. Und vielleicht auch optional direkt im Create-Dialog. Analog für ACLs. Entfernen dann ggf. auch.
Für Public IP-Adressen könnte man es sicherlich auch machen.
Wenn ich nach der Aktion "Updated organization" suche und das genauso eingebe, wird der Eintrag nicht gefunden:
audit-filter-search-1.png
Gebe ich hingegen nur "Updated" ein, dann schon:
audit-filter-search-2.png
Wenn ich bei Ressourcen nach "Port" suche, wird nichts gefunden:
audit-filter-search-3.png
Bei "For", wird "Port forwarding rule" aber gefunden:
audit-filter-search-4.png
Der Fehler sollte nun entgültig behoben sein.
Scheint nicht so. Ich habe alle drei Einladungen erneut gesendet und bei der ersten wurde das Datum wieder nicht aktualisiert (es wurde und wird nun aber das Datum vom letzten Mal angezeigt).
resend.png
Im zweiten Fall ist es ein netcup-Problem, denn nach der Zuweisung zu einem Webhosting sollte die Domain auch mit dem Webhosting funktionieren, da hat zumindest der Domainparker nichts im DNS verloren.
Ich habe gerade mal meine einzige Domain, die neulich zu CloudDNS migriert wurde, einem Web-Hosting zugeordnet und die DNS-Einträge für das Web-Hosting wurden nicht eingetragen. Es steht immer noch der Domainparker drin. Und es dauert sehr lange, bis die Domainparker-Seite im Browser angezeigt wird. Bei der Zuweisung einer anderen Domain mit dem alten DNS-System zum selben Web-Hosting wurden die DNS-Einträge nach kurzer Zeit geändert.
Ja genau! Aber wie in anderen Subforen werden auch hier die Themen nach einer gewissen Zeit anscheinend automatisch auf erledigt gesetzt. Ich habe gestern daher einige wieder auf unerledigt gesetzt.
Wäre es möglich, die Bug-Reports, Feature Requests und evtl. die Themen hier bei "Support & Fragen" nicht automatisch auf erledigt zu setzen?
Ich habe mit eosctl organization client-credential create --name eosprodcli --expires-at 2026-10-10T00:00:00Z neue Credentials erzeugt und folgende Ausgabe erhalten:
┌───────────────────────────────────────────────────────────────┐
| property | value |
| ------------------------------------------------------------- |
| _actions | null |
| _self | |
| assignment_id | 019fd89e-8912-7419-8dc5-a230efdae215 |
| assignment_type | realm |
| created_at | null |
| deleted_at | null |
| expires_at | 2026-10-10T00:00:00Z |
| grid | |
| id | 01a0a15c-e5d1-7f01-bb1d-a714b204d361 |
| name | eosprodcli |
| roles | null |
| secret | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| updated_at | null |
└───────────────────────────────────────────────────────────────┘Sollte created_at hier nicht bereits gefüllt sein? Und _actions?
Anschließend habe ich eine Rolle hinzugefügt:
$ eosctl organization client-credential patch 01a0a15c-e5d1-7f01-bb1d-a714b204d361 --roles compute:vm-manager
┌────────────────────────────────────────────────────────┐
| property | value |
| ------------------------------------------------------ |
| _actions | null |
| _self | |
| assignment_id | |
| assignment_type | |
| created_at | null |
| deleted_at | null |
| expires_at | null |
| grid | |
| id | 01a0a15c-e5d1-7f01-bb1d-a714b204d361 |
| name | |
| roles | - compute:vm-manager |
| secret | null |
| updated_at | null |
└────────────────────────────────────────────────────────┘Auch hier wurde für mehrere Werte null geliefert, wo eigentlich etwas stehen sollte. Die Credentials funktionierten aber und ich konnte damit z. B. eosctl compute vm list aufrufen.
Danach habe ich patch ohne Parameter aufgerufen:
$ eosctl organization client-credential patch 01a0a15c-e5d1-7f01-bb1d-a714b204d361
┌────────────────────────────────────────────────────────┐
| property | value |
| ------------------------------------------------------ |
| _actions | null |
| _self | |
| assignment_id | |
| assignment_type | |
| created_at | null |
| deleted_at | null |
| expires_at | null |
| grid | |
| id | 01a0a15c-e5d1-7f01-bb1d-a714b204d361 |
| name | |
| roles | null |
| secret | null |
| updated_at | null |
└────────────────────────────────────────────────────────┘ Eigentlich hatte ich eine Fehlermeldung erwartet, daß ich die Parameter vergessen habe, oder ist das so gewollt? Die Rolle wurde durch den Aufruf "halb" entfernt, d. h. bei einem get-Aufruf kommt null zurück, aber in der Web-UI wird sie noch angezeigt.
$ eosctl organization client-credential get 01a0a15c-e5d1-7f01-bb1d-a714b204d361
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
| property | value |
| --------------------------------------------------------------------------------------------------------------------- |
| _actions | - _update |
| | - _delete |
| _self | https://organization.eoscloud.io/v1/client-credentials/01a0a15c-e5d1-7f01-bb1d-a714b204d361 |
| assignment_id | 019fd89e-8912-7419-8dc5-a230efdae215 |
| assignment_type | realm |
| created_at | 2026-09-14T19:20:15Z |
| deleted_at | null |
| expires_at | 2026-10-10T00:00:00Z |
| grid | grid.eoscloud.io/organization/019fd89e-8912-7419-8dc5-a230efdae215/root/client-credential/01a0a15c- |
| | e5d1-7f01-bb1d-a714b204d361 |
| id | 01a0a15c-e5d1-7f01-bb1d-a714b204d361 |
| name | |
| roles | null |
| secret | null |
| updated_at | 2026-09-14T19:32:35.78038Z |
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘Und ich kann die Credentials nun auch nicht mehr verwenden:
$ eosctl compute vm list
type='https://specs.eoscloud.io/http-problem-type-error', request_id='01a0a17e-5c01-76fa-a392-f7313acf65c1', errors=[path='', kind='compute.vms.errors.error', message='Server Error (500)', context='map[]']Die Liste der Realms im Scope-Dialog ist nicht alphabetisch sortiert:
scope-realm-list.png
Aktuell muss man noch manuell auf den "refresh"-Button klicken, damit der neue Zeitstempel der Einladung angezeigt wird.
Das hat bei der ersten Einladung nicht funktioniert - bei der zweiten schon. Beide Mails sind angekommen.
resend-invitations.png
Auch Neuladen der Seite hat nicht geholfen.
Bei Domains, die neu bestellt werden, wird als MX-Record mail.example.com eingetragen und auf die IP-Adresse 46.38.243.... gesetzt. Schickt man eine Mail an eine Adresse xyz@example.com, so kann diese natürlïch nicht zugestellt werden und es kommt zu einem Timeout beim Zustellungsversuch, der daher mehrmals (mehrere Tage lang) wiederholt wird.
Wäre es vielleicht sinnvoller, einen "No Service MX RR" a.k.a. "Null MX" zu konfigurieren, so daß eine Mail an die Domain postwendend mit "Domain example.com does not accept mail (nullMX)" beantwortet wird? So bräuchte es nur den einen Zustellversuch. Oder gibt es Gründe, die dagegensprechen?
Irgendwie ist hier gerade der Wurm drin... Ich weiß nicht, ob es damit zusammenhängt, aber nachdem ich beim Dashboard auf die Realms-Kachel geklickt hatte, wird hier gerade immer nur ein Realm von dreien angezeigt:
realm-prod-1.png
realm-prod-2.png
Ein Reload der Seite hilft manchmal, um alle drei Realms wieder in der Liste links anzuzeigen, aber wenn ich dann wieder auf die Realms-Seite gehe, ist wieder nur einer da. Hier hatte ich vorher 'test' in der Liste ausgewählt:
realm-test-1.png
Cool - funktioniert!
Undelivered Mail Returned to Sender
...
Domain example.com does not accept mail (nullMX)
Oder hab ich da was in nem RFC überlesen?
Das steht wohl hier: https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
In der älteren Version RFC 2821 stand noch explizit "A RR" drin.
Für Domains ohne MX gibt es daher mittlerweile "Null MX", die in https://www.rfc-editor.org/rfc/rfc7505.txt definiert sind. Das sollte ich mal bei einigen meiner Domains einrichten. Daher danke für die Diskussion hier! 
Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.