Posts by m_ueberall

    mein RS 2000 G9 resettet sich alle paar Stunden bis alle paar Tage. […]

    Support hat mit die VM schon auf einen anderen Host umgezogen, dennoch besteht das Problem.

    Ich sage ganz ehrlich, dass ich die AMD/G9-Root-Server-Angebote angesichts dieses Diskussionsfadens schlagartig deutlich unattraktiver finde, da es verschiedene Hosts betrifft…

    fail2ban installieren. Damit kannst du IPs bei zu vielen fehlgeschlagenen Login-Versuchen automatisch eine Zeit lang sperren.

    Oder den Zugriff auf Dienste wie SSH ohne vorherige Authentifizierung mittels knock/fwknop gleich ganz verwehren.

    Nach eigener Beobachtung war es in den vorherigen Jahren immer so, dass im Rahmen des Netcup-Adventskalenders vergleichbare/bessere Offerten verfügbar waren als zuvor zum Black Friday, auch wenn sie teilweise umbenannt wurden…

    Das Bundesfinanzministerium erläutert mir, was NC mir ab dem 1.1. berechnet?

    Als Privatkunde gelten für mich die Inklusivpreise. also im Beispiel 16cent. Ein Nettopreis interessiert mich als Privatmann ja nicht.

    Den zweiten Satz lasse ich (bis auf ein Stichwort unten) mal unkommentiert. :S


    Nullhypothese: NC hält sich an die Vorgaben des Bundesfinanzministeriums bzgl. der Ansetzung der Umsatzsteuer (wie jedes andere Unternehmen auch).

    Gegenhypothese: NC behält aus Werbegründen die reduzierten Bruttopreise noch eine Weile bei (wie das zu realisieren wäre, mag sich jeder selbst überlegen; Stichwort: Nettopreisanpassung) – dann wird NC die Kunden zeitnah darüber in Kenntnis setzen; alternativ kann man NC fragen, denn im Kundenforum hat (nach eigener Beobachtung) niemand eine Glaskugel, die er mit anderen teilt.

    Da passt ja meine Frage gerade:

    Finde ich irgendwo, wie die Preise nach dem 1.1. berechnet werden?

    Hat denn die Suchmaschine der Wahl nichts dazu ausgespuckt?

    Vom 01.07.2020 bis zum 31.12.2020, also für sechs Monate, wird der Regelsatz bei der Umsatzsteuer von derzeit 19 % auf 16 % abgesenkt werden. Entsprechendes gilt auch für den ermäßigten Steuersatz, der von derzeit 7 % auf 5 % herabgesetzt wird. Der ermäßigte Steuersatz wird etwa auf eine Vielzahl von Grundnahrungsmitteln, Hygieneartikeln sowie Presse- und Verlagserzeugnissen angewendet.

    Nach dem 31.12.2020 sind wieder die alten Sätze in Höhe von 19 % beim Regelsteuersatz und 7 % beim ermäßigten Steuersatz anzuwenden.

    Und hier findet sich die Erläuterung vom Bundesfinanzministerium.

    Ich wiederhole meine Empfehlung auch noch einmal :-)

    >> Oder gleich eine modernere Variante: fwknop(d)

    (Falls man kein "klassisches" Port-Knocking haben möchte.)

    Danke für die Erinnerung! Da gab es ja hier noch das (Meta-)TODO, die Nutzung dieses Werkzeugs auf die TODO-Liste zu setzen… ;(

    Nachdem ich gestern 'mal fwknop angesehen habe, frage ich mich, ob das in der Praxis überhaupt große Verbreitung auf mobilen Geräten findet (vgl. Issue #138: "Extend allowed IP's to entire subnets for rapidly changing mobile environments"). Natürlich kann man dort bei Rückgriff auf ein VPN (wie bspw. MeshVPN) auf fwknop[d]/knock[d] verzichten, aber es ist bedauerlich, dass man nicht explizit (zumindest teilweise) eine stringente IP-Adressprüfung deaktivieren kann, zumal es auch die Zertifikatsverwaltung in Testumgebungen o. ä. vereinfachen würde. Werde aus diesem Grund wohl doch noch eine Weile bei meinem präferierten knock-Fork v0.8.1 bleiben… :pinch:

    (Allerdings bin ich ganz Ohr, falls jemand obengenannte Funktionalität in einem fwknop-Fork entdecken sollte! :love:)

    m_ueberall Aber genau so hat er den Eintrag doch angelegt. Oder habe ich nen Knick in der Pupille?


    Für mich sieht das aktuell dann eher nach einer Latenz des DNS-Server aus. Steht im CCP denn hinter allen Records ein "OK"?

    Stimmt, hätte so funktionieren können/sollen. :P

    Entweder wurde der Test ausgeführt, bevor Netcup-seitig die Änderung publiziert wurde oder (wahrscheinlicher) ein lokaler Cache lieferte veraltete Werte. Im Zweifelsfall den client-seitigen Cache löschen und/oder Abfrageergebnisse via https://www.whatsmydns.net/ kontrollieren.

    Nochmal etwas ausführlicher, falls die o.g. Fragen noch offen sind:

    Ich gebe die URL (von netcup gehostet, wo kein content ist) ein "abc.com" so soll ich, ohne das ich es merke, auf die URL "123.squarespace.com" (die bei Squarespace liegt und auf dem der content, also der Shop ist) weitergeleitet werden.

    (1) Niemand soll die Squarespace URL im Browserfenster sehen.

    (2) Außerdem würde ich das SSL zertifikat, das bereits bei Squarespace aktiv ist nutzen.

    (3) Ist dafür nicht diese Art von "Zusammenführung" mit DNS da? Ich hatte es in einigen Foren so verstanden.

    Ich selbst nutze Squarespace nicht. Auf den ersten Blick widersprechen sich (1) und (2) bei der geplanten Verwendung. Squarespace verwendet ein Wildcard-Zertifikat "*.squarespace.com", welches alle Kundenunterdomänen abdeckt. Wenn aber nur die Domäne "example.com" (<-- Standard-Beispieldomänenname) auf der Client-Seite auftauchen soll, dann muss der verwendete Webserver, welcher direkt mit dem Client kommuniziert, auch ein Zertifikat für diese Domäne ausliefern.


    Nehmen wir einmal an, dass es eine "DNS-Zusammenführung" (3) (also eine Weiterleitung von der Domäne "example.com" auf "123.squarespace.com") gäbe – wie oben ausgeführt nicht bei Netcup, aber bei anderen Anbietern möglich. (Bei Netcup wäre lediglich eine Weiterleitung einer Unterdomäne "123.example.com" machbar, mithilfe eines "CNAME"-Eintrags für die Unterdomäne im CCP.) Das hieße, dass der Client bei dem Versuch der Ermittlung einer IP-Adresse von "[123.]example.com" die Antwort erhält, er möge unter den (zugehörigen) DNS-Einträgen für "123.squarespace.com" nach einer IP-Adresse suchen. Die HTTP(S)-Anfrage geht dann zwar an die Serveradresse, die letztlich Squarespace hinterlegt hat, allerdings mit dem Ursprungs(unter)domänennamen "[123.]example.com". (Gewünschtes Verhalten wie oben beschrieben.) Diese Anfrage kann Squarespace aber nur korrekt bedienen, wenn es möglich ist, ein TLS-Zertifikat für die eigene (Unter-)Domäne bei Squarespace zu hinterlegen. Wichtig ist, dass diese DNS-Weiterleitung für *alle* Arten von Abfragen von DNS-Einträgen aktiv ist, welche ursprünglich an "[123.]example.com" gerichtet sind. Es findet client-seitig nur ein applikationsspezifischer Zugriff (hier: HTTP(S)) auf den Dienst (hier: Webserver) statt, die Weiterleitung "greift" schon bei Ermittlung der DNS-Inhalte.


    Eine Weiterleitung ist allerdings auch (nur) bei Verwendung des HTTP(S)-Protokolls möglich:

    (a) Der "einfachste" Fall ist derjenige, bei welchem der Host (welcher "[123.]example.com" bedient) dem Client mithilfe eines HTTP-3xx-Codes explizit mitteilt, er möge eine zweite Anfrage unter Verwendung der "Ersatzadresse" "123.squarespace.com" stellen. Das führt dann dazu, dass die Squarespace-Adresse auf der Clientseite bekannt wird, denn die zweite Anfrage erfolgt explizit unter dem "Ersatznamen". Nicht das ursprünglich genannte gewünschte Verhalten, allerdings benötigt Squarespace keine Kopie des TLS-Zertifikats für "[123.]example.com" und es gibt keinen doppelten Inhalt, wodurch die Webpräsenz nicht von Suchmaschinen abgestraft wird.

    (b) Alternativ kann ggf. ein sogenannter "Reverse Proxy" eingesetzt werden, welcher die Anfragen an [123.]example.com[/xyz] dadurch bedient, dass er diese seinerseits in beide Richtungen umschreibt, intern also 123.squarespace.com[/xyz] kontaktiert und als "Mittelmann" fungiert. Dies führt jedoch zunächst zu redundanten Inhalten, denn dieselbe Anfrage sollte clientseitig ohne Gegenmaßnahmen auch direkt gegen 123.squarespace.com[/xyz] funktionieren. Eine Möglichkeit, gut erzogene Suchmaschinen davon abzuhalten, beide Adressen zu erfassen, ist die Sicherstellung, dass entweder unterschiedliche robots.txt-Dateien/-Einträge für beide (Unter-)Domänen ausgeliefert werden und/oder Kontaktanfragen bekannter Bots seitens Squarespace anderweitig verhindert werden.


    Hat das etwas Licht ins Dunkel gebracht?

    Ich möchte mit Hilfe von Traefik ein LE SSL-Zertifikat für einen Webserver mit der Domain host.subdomain.example.org erstellen und nutze dafür die DNS-Challenge mit einer Kopplung an die Netcup-API.

    Das ist ein "gewolltes Verhalten" (=verwendete BIND-Syntax) von Netcup. Einträge im CCP für Hauptdomäne ("example.org") und Unterdomänen sehen wie folgt aus:

    Code
    1. _acme-challenge TXT ...
    2. _acme-challenge.subdomain TXT ...
    3. _acme-challenge.subsubdomain.subdomain TXT ...

    ("host" wäre hierbei die "subsubdomain"; die Hauptdomäne muss man sich bei dieser Syntax immer am Ende dazudenken.)

    gerne würde ich meine Domain bei netcup (01.com) auf meinen Shop (02.com) […] "weiterleiten".

    Dem Beispiel nach zu urteilen, reden wir hier von der Weiterleitung einer Hauptdomäne auf eine andere. Das geht via DNS bei Netcup (unter Verwendung der Netcup-DNS-Server) nicht, siehe hier.

    Warum bekomme ich dann aber beim aufruf der URL "mail.meineDomain.de" wiederrum die Meldung seitens "Diese Domain wurde geparkt"?

    Wie ich oben erwähnte, ist der (wahrscheinlichere) Grund, dass ein Cache-Eintrag für "mail" auf dem Client-Rechner noch auf die unbekannte IP-Adresse zeigt. Das lässt sich unter Windows oder Linux auf der Kommandozeile durch "nslookup mail.meineDomain.de" überprüfen (unter Linux verwendet man hier statt "nslookup" normalerweise "host" oder "dig"; "host" sollte immer verfügbar sein, "nslookup" ist unter Debian/Ubuntu im gleichen Paket "dnsutils" enthalten wie "dig"). Unter einer neueren Windows-Version lässt sich der (veraltete) DNS-Cache dann ggf. durch Eingabe von ipconfig /flushdns löschen.


    Wenn der obige Befehl jedoch bereits die eigene IP-Adresse zurückliefert, dann muss die "Parknachricht" vom eigenen Server stammen. Der Befehl sudo netstat -tulpen | grep -E ':80|:443' sollte in diesem Falle in der letzten Spalte den Namen des verwendeten Webservers anzeigen, bei dessen Konfiguration man dann weitersuchen kann.

    (1) Ich habe jetzt den Record "@ A" umgeschrieben sodass dort die IP-Adresse meines Root-Server drin steht.
    (2) Allerdings bekomme ich weiterhin die Meldung:" Diese Domain wurde geparkt".

    (3) Die beiden Records für "mail" sowie "ftp" enthalten weiterhin aber eine IP die ich nicht zuordnen kann

    Für die "mail"-Unterdomäne ist (2) die Folge von (3), denn die Wildcard "*" greift nur für nichtgenannte Unterdomänen, und solche werden gerade für "mail" (und "ftp") definiert. Die letzteren beiden sind zu löschen, dann sollte es funktionieren.


    Wenn "www.MeineDomain.de" und "MeineDomain.de" weiterhin auf eine "Parkmeldung" zeigen (trotz Hinterlegung der eigenen IP-Adresse), dann könnte das daran liegen, dass der installierte Webserver genau diese "Parkmeldung" ausliefert.

    Bei einer Änderung im DNS ist aber immer zu beachten, dass auch noch ein lokaler Cache die alten Einstellungen liefern kann! Entweder diesen Cache löschen, ggf. einen anderen Browser verwenden und/oder die Einstellungen via https://www.whatsmydns.net/ verifizieren.