Beiträge von joas

Ja, ich. Hat wunderbar geklappt mit KVM auf Debian.

Jetzt ist die Domain ayake.de auflösbar.

Anhand die vorhandene Einträge gehe ich davon stark aus, dass es das Paket Webhosting von netcup gemeint ist.

Es kann bis zu 48 Stunden dauern, bis die Domain weltweit bekannt ist.

Da die Domain noch nicht aufgelöst werden kann, leitet der Router von der Telekom auf die entsprechende Hilfeseite.

Edit: Mist, ich bin zu langsam...

Zitat von mainziman

joas das ist mir schon klar, und Dein Beispiel mit de.ssl-tools.org kenne ich bereits, und klappt bei IPv6 ebenfalls nicht ...

und des hardenize.com liefert einen kompletten Quark (mail01.ipv6help.de ist kein SMTP Host - was ist des dann?);

ist das jetzt eine Verschwörung gegen IPv6?

Wieso soll hardenize.com Quatsch ausspucken? Der MX-Eintrag von ipv6help.de ist momentan auf mail01.ipv6help.de gesetzt, und somit ist dies für die Außenwelt ein SMTP-Host.

also ich kann das Problem mit IPv6 nicht bestätigen, bei mir läuft alles bestens. Von zuhause aus kann ich meinen Server per IPv6 zugreifen.

Auch über lookingglas von telia und anexia funktioniert IPv6 einwandfrei.

Zitat von [netcup] Kai

Der SSL Test als solches scheint gerade ein IPv6 Problem zu habe. Auch Seiten außerhalb unseres Netzwerks haben dort die selbe Fehlermeldung.

mainziman wie Kai von netcup schon sagte, der Fehler liegt bei SSLLabs, es hat nichts mit uns zu tun. Deshalb sollte man nicht nur auf eine Testseite vertrauen, sondern immer möglichst auch anderen Seiten zum Testen nutzen. z.B. hardenize.com oder de.ssl-tools.net

Perfekt, werde gleich testen.

Ich würde so gerne DNSSEC für die TLD .berlin nutzen wollen.

Gibt es dazu Planung?

Edit: es gibt ja für TLD .hamburg und .koeln DNSSEC, für die Hauptstadt müsste es doch wichtig sein, mittels DNSSEC abzusichern.

Jetzt ist das Paket openssl 1.1.1 bei Debian Sid angekommen. Somit wird dieses Paket mit großer Wahrscheinlichkeit bei Buster erscheinen. Oder auch nicht...

Zitat von vmk

::1:see:bad:c0de

Korrektur:

::1:5ee:bad:c0de

Ich glaube, da hat netcup was angepasst, unter Einstellung->Optimierung bei SCP taucht eine dritte Option "BSD" auf.

Ob es dann besser funktioniert? Kann es jemand testen?

Zitat von mfnalex

Das hab ich ja noch nie gehört Ich hab den Eintrag jetzt rausgenommen, mal sehen was passiert.

Ha! Ich glaube, dein Record für Subdomain www ist wieder da.

Ich erinnere mich ganz dunkel an einem Fall. Kann auch sein, dass ich falsch liege.

Wenn irgendein Record sprich "_443._tcp.www" oder irgendwas ähnliches gesetzt wird, dann setzt auch zusätzlich ein einiger A-Record für www voraus.

Die Frage ist, hast du da gestern vielleicht was Ähnliches gesetzt?

Zitat von H6G

Sieht soweit gut aus, bei nicht vorhandener Subdomain sollte es eigentlich ein NXDOMAIN mit SOA zurück geben. Die Netcup Server liefern aber NOERROR mit SOA auf eine A Anfrage zurück - ein Indiz dafür, dass da etwas nicht stimmt. => Support

Das genau hier meinte ich, das sind die seltene Schluckaufe von DNS-Server.

Ein bestimmter Record von meiner Domain war plötzlich nicht mehr da, obwohl dieser Record ganz klar unter CCP gesetzt war und ich seit Monaten keine Änderung durchgeführt habe. Das lässt sich mit erneutem Speichern beheben. Da werden die Informationen erneut synchronisiert.

Edit: das stelle ich auch grad fest, dass der Fehler immer noch da ist. Dann ist echt ein Fall für Support.

Versuch mal nochmal ohne Änderung auf Speichern zu klicken. Und beobachte das eine Weile. Die Serial springt dann auf das aktuelle Datum und wird erneut synchronisiert.

Es gibt tatsächlich ganz selten ein paar Schluckauf bei den DNS-Servern von netcup.

Ich verstehe auch im Moment nicht, wo das Problem liegt?

Bei der 2FA Methode muss man erst das normale Passwort bei CCP eingeben, dann wird nach dem Code aus dem Authenticator gefragt. Und dazu die Sicherheitsoption bei SCP aktivieren, sodass man nur über CCP zum SCP gelangen kann.

mainziman

das kann man nicht wirklich vergleichen, denn die Maschine ist virtuell.

Schaue mal unten: da steht virtuelle Prozessoren...

Es ist schon ein Unterschied, ob die CPU-Core dediziert sind oder eben virtuell...

Genauso bei mir auch, hat alles gut geklappt. Der Server wurde ordnungsgemäß heruntergefahren und war ca. 22 Minuten down. Auch beim Hochfahren gab es keine Probleme.

Die Programmiersprache "Brainfuck" ist echt im wahrsten Sinne des Wortes die abgef**te Sprache, die ich überhaupt kenne.

Selbst ein Hello World Programm zu schreiben, brauche ich mindestes zwei Dosen Studentenfutter.

Edit: Hier ist der Editor Interpreter, falls ihr mit Brainfuck programmiert wollt.

Das ist eigentlich nicht typisch Debian, so wie ich Debian vor paar Jahren kannte.

Seitdem die Meltdown/Spectre Sicherheitslücken bekannt wurden, bin ich mit Debian nur am Patchen und rebooten.

So habe ich das Gefühl, kann auch sein, dass es mir eingebildet habe.

Zitat von m_ueberall

Ich verwende derartige CNAME-Einträge schon seit vielen Monaten (mit danecheck und DNSSEC/TLSA validator erfolgreich überprüft):

Code

_tcp TLSA ...
[...]
*._tcp CNAME _tcp.example.org
*._tcp.subdomain CNAME _tcp.example.org
*._tcp.subsubdomain.subdomain CNAME _tcp.example.org

Das ist aber ein guter Tipp. Habe sofort bei mir umgestellt