Beiträge von MichaelOF

    Hab ich alles nie bestritten,

    TTL ist ein KANN Wert, ein Resolver KANN bis zu diesem Wert cachen.

    Muss er aber nicht. Und tun die meisten nicht (mehr).

    https://dnschecker.org ist kein "Tool, das DNS-Konfigurationen überprüft". Sondern einfach nützlich Abfragen auf "normale", weltweit verteilte, öffentliche Nutzung erlaubende Nameserver ermöglicht.

    Der Platzhirsch Google dokumentiert das ganze sogar für seinen Public DNS (IPv4 u.a. 8.8.8.8):

    "... können Sie auch warten, bis die TTLs der Einträge ablaufen. Diese sind in der Regel auf sechs Stunden begrenzt, auch wenn die tatsächliche TTL länger ist."


    Selbstredend würde auch ich die TTL rechtzeitig runtersetzen, wenn ich geplante Änderungen machen möchte. Umso kritischer eine Erreichbarkeit ist, umso sorgfältiger sollte man sich nach wie vor daran halten.

    Aber es IMHO ist es gut zu wissen, dass es inzwischen idR auch schneller geht. FALLS man mal vergessen hat, rechtzeitig zurückzusetzen :D

    NaN "ich werde mal mit einer neuen (gestern ;)) .de Domäne testen..."...

    Vorher:
    TTL stand auf 3600.

    Testschritte:

    1. TTL validiert, Google Toolbox und https://dnschecker.org/, SOA Record: 3600

    2. TTL auf 604800 gesetzt, 7 Tage, max. TTL. nach RFC

    (eine Weile warten...)

    3. TTL validiert, Google Toolbox und https://dnschecker.org/, SOA Record: 604800

    (eine Weile warten...)

    4. TTL auf 3600 gesetzt

    (eine Weile warten...)

    5: TTL validiert, Google Toolbox und https://dnschecker.org/, SOA Record: 3600

    Schritte 1- 5 heute, mein Post vorhin ist ~ 2h alt...

    Resümee für mich:7 Tage verstreichen recht schnell im DNS Universum :D

    NaN My misunderstanding, wrong direction :) You read the TS initial post in way that he wants to peform OUTGOING port scans, he rents a VPS, and wants to use for outgoing scans, destination wherever, his "customers or companies who have a bug bounty program".

    Based on mistake by me, pls forget everthing misleading written by me.

    Although "customers" probably expect the port scans, and maybe even "companies who have a bug bounty program" would not really have "potentially unaware sysadmins", the outgoing port scan as a traffic pattern should trigger Netcup's abuse monitoring.

    Make sense, being polite is of course always a good idea.

    But still IMHO as the TS wrote "... my line of work inevitably involves performing some (light) port scanning ..." - why should this be forbidden for his "own", yes rented VM?

    In fact I did this for myself (not as "bounty hunter"), but for proofing that REALLY only the ports I want to open are open. From a Linux box at home, or even via Android apps like "Ping"... Was a while ago pretty "funny" that e.g. docker was pretty free on a normal user level to open each and every port......

    ... INCOMING port scans from OUTSIDE Netcup are "allowed"

    (Sarcasm off): IMHO any server owner sees

    "- brute forcing ssh credentials

    - running scans 24/7"

    In my case summarized in my daily logwatch email.

    So as this technically possible, not covered by any DDoS or whatever provider side protections, why shouldn't it be possible that you rent your own server and port scan it from outside as long as you want?? As both parties are/is "YOU", it IMHO couldn't even be a legal issue... I can burgle into my home as long as I want :D

    NaN Danke für die ausführliche Klarstellung und Ergänzung der Aspekte autoritativ vs. übrige Nameserver. Und den wichtigen Hinweis dass kleiner 300 sec idR nicht sinnvoll, selbst DynDNS braucht einen Moment...

    Mir ging es hauptsächlich um Obergrenzen. AFAIK sind die nach wie vor im RFC genanten 7 Tage ein Wert, denn die meisten Nameserver ignorieren (auf 86400 "reduzuieren") und eben ohne es zu müssen früher neu holen. https://toolbox.googleapps.com/apps/dig/#SOA/ hat jedenfalls gezeigt, dass Änderungen von bei Netcup verwalteten Domänen viel schneller als die angegebene TTL sichtbar werden. Ist eine Weile her, aber soweit ich mich erinnern kann, zeigte die Google Toolbox sogar eine TTL von 86400 = 1 Tag an OBWOHL ich für die geparkte .eu Domäne im CCP 7 Tage eingetragen hatte.

    ich werde mal mit einer neuen (gestern ;)) .de Domäne testen...

    Bei mir auch :D

    Ich bin vom Anspruch der "Old-School nettiquette Höfliche", bin schon so alt, dass ich die Zeiten noch kenne, wo jedes Byte gezählt wurde ;) Am Anfang bzgl. RAM, gegen Ende dann immer noch bzgl. Netzwerk-Traffic. Also hab ich als TTL Default meistens "nett" 6-12h, und setze es auf 300sec wenn ich konkret basteln möchte. Inzwischen ist es aber ohnehin so, dass die TTL eher eine "Empfehlung" ist, Google z.B. als Platzhirsch ignoriert sie, zumindest ab einem Wert von (?)

    Ich hatte mal eine .EU Domäne aus einer Netcup-Aktion mit einer laut RFC max. TTL. von 7 Tagen "geparkt", und hatte sie dann aber in wenigen Stunden "zurück", als ich dann irgendwann doch recht spontan Änderungen machen wollte...

    Hallo,

    ohne selbst Webhosting zu nutzen: Dieses ist erst einmal unabhängig von einer Domäne, welche wie Du ja schreibst schon vorhanden war, also keine im Webhosting inkludierte Domäne ist.

    Ganz pragmatisch, weil ich nicht genau weiß, was Schritt 3 ggf. in den DNS Settings einer zu verbindenden Domäne ändert:
    1. Du wirst vermutlich ohnehin zuerst die TTL deiner Domain auf einen niedrigen Wert setzen, damit Änderungen schnell propagiert werden. Also irgendwas zwischen 300 (5 min) und 3600 (1h) z.B.

    2. Ich würde dann vorher einen Screenshot der DNS Records machen, die Domäne wie beschrieben mit dem Webhosting verbinden. Und mir dann anschauen, was das CCP draus gemacht hat :)

    Passt da irgendwas nicht - zurücksetzen. Dann wäre das Webhosting immer noch nicht verbunden - aber deine DNS Settings nach TTL in sec wieder so wie vorher :)

    Schau Dir z.B. mal diesen Post hier aus dem Forum an, da ist ein Screenshot, welche DNS Records bei Webhosting gesetzt werden.

    "Pflicht" sind der MX Record, die CNAME keyN._domainkey (für DKIM), den TXT _dmarc (für DMARC), den TXT " v=spf1...." (für SPF).

    Für Netcup's Webhostings Mail vermutlich auch den TXT _mta-sts (für MTA-STS Strict Transport Security), um Transport-Fehler auszuschließen. Ein MTA muss das aber an sich nicht verpflichtendhaben.

    Der CNAME autoconfig ist nice to have, ermöglicht diversen Email-Clients wie z.B. Thunderbird oder KMail die Autokonfiguration. Nutzt du das nicht, müssen Clients halt SMTP/IMAP etc. Settings manuell vornehmen.

    Die A und AAAA Records brauchst du bei "nur Mail" NICHT.

    Bzw. irgendwann angepasst, vermutlich ohne die "*" Einträge, wenn du zukünftig Webhostung UND deine aktuelle Domänenverwendung kombinieren möchtest.

    Hallo zusammen,


    bevor ich ein Support Ticket aufmache mal ein Versuch in die Runde:

    Ich habe meinen VPS vor kurzem auf einen RS migriert. Seitdem ist es recht oft so, dass BS-Updates (OpenSuse Leap 15.6) beim Schritt Abfragen der GPG Keys etc. hängen, Beispiel:

    Code
    [server:mail|https://download.opensuse.org/repositories/server:/mail/15.6/] Neue Repository-Metadaten konnten nicht abgerufen werden.
    Verlauf:
     - Zeitüberschreitung beim Zugriff auf 'https://mirror.linux-schulserver.de/opensuse/repositories/server:/mail/15.6/repodata/e68a9c82b1b5bf26f4115d747a4a8a24fb56da6d8dab1722e8466bf34afabddb-primary.xml.gz'.

    Ein traceroute auf diesen Mirror bleibt irgendwo zwischendrin im H*tzner-Netzwerk hängen
    Gleiche Operation von zuhause (Netz der DTAG, auch OpenSuse Leap 15.6) klappt fehlerfrei.


    Kennt jemand dieses Verhalten? Blockt hier H*tzner eingehend? Oder blockt Netcup ausgehend?
    Und warum trat dieses Phänomen vor wenigen Wochen als VPS nicht auf? Setup identisch, Klon, Anzahl Abrufe max 1-3/Tag, also kein DoS oder sowas :)

    Nervt auf jeden Fall!

    Gruß,

    Michael

    finnvweiss Hui, dass ist eine globalgalaktische Frage auf die ich versucht bin, mit "42" zu antworten :D

    Im Ernst: Da gibt es je nachdem wie du es aufsetzt einige Wege zum Ziel.

    Willst du final einmalig umziehen, oder brauchst du sowas wie DEV/STAGING/PROD, auf Dauer?

    Wenn "FTP+SQL" dann fileadmin und typo3conf. DB wenn MySQL/MariaDB z.B. via mysqldump.

    Du könntest das ganze aber auch in ein SitePackage und/oder eine komplette Extension packen. Und sogar via Git(Hub) von a nach b schaufeln.....

    Mögliche Lösung, bezieht sich zwar auf Konkurrenz, sollte aber evtl. 1:1 anwendbar sein. Hab kein Webhosting, daher kann ich nicht testen.

    https://www.typo3lexikon.de/typo3-tutorials/installation/#php-umgebung

    Das zweite kann ich bestätigen:

    Bei mir läuft Typo3 auf meinem VPS, und ich hatte recht lange die Warnung (gelb) bzgl. max_execution_time übersehen.

    Ganz präzise: Ich hatte das Limit in eine VHOST spezifische conf Datei eingetragen.

    Code
    <IfModule mod_php.c>  php_value max_execution_time 240
      ...</IfModule>

    Das ganz war aber ursprünglich eingepackt (OpenSuse Leap) in IfModule mod_php7.c, und wurde daher nach einem PHP 7 auf 8 und Apache Update irgendwann gar nicht mehr angezogen.

    Aufgefallen wie gesagt erst viiiieeeel später, gestört hat es nie :)

    Hallo,

    Screenshot_20250612-111939.png


    habt ihr Erfahrungen, wie lange so eine Prüfung normalerweise dauert?

    Und warum es diese Prüfung überhaupt gibt? Scheint ja nur dort so zu sein?

    Ich dachte, eine "Frage zu Tutorials" passt am besten in die Schublade "Howto Netcup".

    DIESE Rückfrage eigentlich IMHO auch, aber an das Henne und Ei traue ich mich nicht :D

    VG Michael

    Hallo zusammen,


    aus einigen für mich sehr spannenden Aspekten eines Threads hier im Forum habe ich was gebastelt, was evtl. "Tutorial-würdig" sein könnte.


    Dazu aber vorab ein paar Fragen:
    - Das "neueste" Tutorial ist aus 2023 - lebt das Thema überhaupt noch? Oder sagt Netcup zu allem Eingereichtem "nein", und jeder hat deshalb die Lust verloren? ;)

    - Im CONTRIBUTING.md steht "We will not accept tutorials that can be found anywhere else on the web, especially if not in context with netcup." - mehr als nachvollziehbar. Mein evtl. Tutorial wäre aber nicht "pur Netcup". Soweit ich im Netz finde neu, aber anwendbar bei jedem Hoster. Sind ganz viele ex. Tutorials wie z.b. dieses hier auch, was mich wieder zu meiner ersten Frage zurückführt :)
    - Der Weg, ein Tutorial einzureichen, geht via Github. Ich bleibe im Netz gerne anonym - sowohl hier im Forum, als auch bei Github. Würde der "Link" zu mir als realem Kunden dennoch fkt., wenn ich (m)einen Pseudonym-Github User dazu nehme? Bekäme man ein "universelles" NC Voucher?

    VG Michael