Beiträge von gunnarh

  • Reverse DNS Deligation für IPv6

    Danke mainziman für den Hinweis auf RFC 2317 - Classless IN-ADDR.ARPA delegation

    Muss gestehen das kannte ich bislang nicht und habe ich "in the wild" auch noch nie gesehen.

    Interessanter Ansatz, wenngleich das streng genommen keine Delegation ist, denn man ist ja für jede einzelne IP-Adresse vom gesetzten CNAME in der Zone des betreffenden /24er Subnetzes abhängig. Aber interessante Lösung - vielleicht möchte Netcup das ja anbieten ;)

  • Server 1 soll IP von Server 2 nutzen

    Zitat von anco

    Das wird Facebook auch wissen und ich denke auch technisch differenzieren. Desweiteren sieht ein Proxy meistens nach aussen auch anders aus als ein normaler Client.

    Die von mir zitierten Nutzungs-Szenarien sind Carrier Grade NAT oder haushaltsübliches NAT des SOHO-Routers, da ist also kein Proxy im Spiel, der einen Forwarded-For-Header setzen könnte.


    Und in Unternehmen mit Proxy wird heutzutage üblicherweise auch kein Forwarded-For-Header mehr gesetzt, da dies zu viel Netzwerk-Internas nach außen preisgibt.

  • Server 1 soll IP von Server 2 nutzen

    Zitat von Skinnygirl

    Meinst Du damit, dass das mit "mehrere Accounts über eine IP-Adresse ansteuern", nicht problematisch ist?


    Warum sollte dies problematisch sein? Bei jedem Haushaltsanschluss (der in der Regel nur eine IPv4 besitzt) sind heute typischerweise 3-5 Personen mit ihren unterschiedlichen Konten gleichzeitig online und nutzen SocialMedia. Bei CarrierGradeNat-Teilnehmeranschlüssen teilen sich dutzende Kunden die gleiche IPv4 und größere Unternehmen oder Unis mit mehreren tausend Concurrent-Usern haben meist auch nur eine 1-stellige Anzahl an IP-Adressen über die sie ihre ausgehenden Web-Zugriffe abwickeln.

  • Roundcube 1.3.1 (sieverules)

    RainLoop ist aber nur für Personal / Non-Commercial Use kostenfrei. https://www.rainloop.net/purchase/

    Drei Mailserver sind vermutlich nicht "Personal Use", Mailserver betreibt man - selbst wenn nicht kommerziell betrieben - doch in der Regel mit mehreren (fremden) Postfächern.


    => EDIT: Sorry, ziehe diesen Aspekt zurück, es gibt auch eine unter AGPLv3 stehende Community Edition!


    Ich würde RoundCube für jeden Mailserver getrennt installieren. Der Wartungsaufwand beim gelegentlichen Versions-Upgrade ist überschaubar, die Fummelei mit der Multi-Domain-Konfiguration wäre mir zu nervig.

  • E-Mailverschlüsselung für Vertragsänderungen S/MIME doer PGP

    eIDAS führt kein neues Signatur- oder Verschlüsselungsverfahren ein, es regelt lediglich die Anforderungen hinsichtlich Zertifikatsdiensteanbieter und wechselweise Anerkennung qualifizierter elektronischer Signaturen. De-Fakto bleibt zur Nutzung dann nur SMIME. Ob ich mir von meiner Gegenstelle nun das SMIME-Zertifikat besorgen muss, es per LDAP aus einem der Verzeichnisdienste rausklaube oder einen GPG/PGP-Key auf einem Keyserver raussuche kommt vom Aufwand her aufs gleiche raus. Das leidige Thema der E-Mail-Verschlüsselung wird durch eIDAS auch nicht handhabbarer.

  • E-Mailverschlüsselung für Vertragsänderungen S/MIME doer PGP

    Der netcup-Mailserver ist zwar leider nicht mit DANE abgesichert, verwendet aber immerhin ein gültiges TLS-Zertifikat für den STARTTLS-SMTP-Transportschutz und bietet zeitgemäße Cipher-Suiten an. Für meinen Geschmack ist das nicht "unverschlüsselt" sofern Dein Mailserver passend konfiguriert ist.


  • Abuse Meldung root Server Traffic out

    Die Ziel-IP ist Dein (Cloud-)Storage-Provider? Sicher?


    Mir kommt das etwas merkwürdig vor. Ich schiebe z.B. jeweils am Monatsletzten eine Vollsicherung mit ca. 50-60GB auf einen anderen Server, der nicht im NetCup-Rechenzentrum steht. Das ist somit deutlich mehr als Du hier verbraucht hast. Und ich tue das in ca. 3 Stunden. Eine Abuse-Meldung habe ich noch nie erhalten. Allerdings muss ich zugeben, dass ich dabei offenkundig nicht so flott unterwegs bin wie du.


    Wer hat Dir das geschickt? NetCup im eigenen Namen, oder jemand anderer und NetCup hat es Dir nur aufbereitet und weitergeleitet?


    Zur Frage des "maximalen Speed": Die Abuse-Meldung spricht von "Treshold Packets: 30000 packets/s" und weiters von "74445 packets/s" sowie "724.8 MBit/s". Wenn ich 724,8MBit durch 74445 Pakete/s dividiere komme ich somit auf eine durchschnittliche Paketgröße von 1217 Bytes -> OK, das klingt plausibel. Dass Dein Server mit 725MBit gesendet hat klingt jetzt auch nicht unplausibel.


    Um demnach den Treshold von 30.000 Paketen/sek nicht zu überschreiten, dürftest Du bei einer Paketgröße von eben ca. 1217 Bytes demnach nicht mehr als mit 290MBit/Sek bzw. 36MByte/Sek senden.

  • Beta: Domains jetzt live im CCP bestellbar

    chrko: DNSKEY Hash versus vollen Public-Key: Danke für den Hinweis, Du hast recht. DENIC nimmt tatsächlich den vollen Key auf, NIC.at nur den Hash. Somit ist der von mir bemängelte Screenshot im Wiki doch nicht falsch, er trifft nur nicht auf .at Domains zu.


    Ich rege hier an beim Eingabefeld doch den Begriff "Hash" nebst "Öffentlicher Schlüssel" zu ergänzen und im Wiki vielleicht einen Hinweis zu Unterschieden je nach Domain-Endung aufzunehmen.


    Was die Pflege der im Whois hinterlegten Daten angeht: Ich bin der Meinung, dass der Status-Quo nicht mit den nic.at Registrierungsrichtlinien im Einklang ist. Konkret hat der Admin-C auch eine E-Mail Adresse verpflichtend zu beinhalten, diese fehlt jedoch in meinem Handle und ich habe keine Möglichkeit sie zu ergänzen. Weiters ist als Tech-C der technisch für die Zone Verantwortliche zu führen. Das ist nur dann Netcup, wenn Netcup die authoritativ antwortenden Nameserver für die betreffende Domain hostet. Da ich jedoch meine eigenen Nameserver verwende ist ein auf Netcup lautender Tech-C nicht korrekt.

  • Beta: Domains jetzt live im CCP bestellbar

    Feedback meinerseits:

    • Habe heute die Domain hitco.at erfolgreich zu NetCup transferiert
    • Da während des Transfers keine eigenen Nameserver setzbar sind, muss man zwischenzeitlich in Kauf nehmen, dass die NetCup-Nameserver gesetzt werden und kann diese dann aber bereits wenige Sekunden nachdem der Transfer vollzogen war im CCP auch gleich wieder entfernen und seine eigenen Nameserver eintragen. Ich habe den Transfer um ca. 13:30 vorgenommen - die nic.at Nameserver reloaden um 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ), somit hatte ich ausreichend Zeit bis die Änderungen um 15:00 überhaupt nach außen hin sichtbar geworden sind, um meine eigenen Nameserver wieder einzutragen.
    • Der Roboter arbeitet wirklich "live" - da gibt es nichts zu bemängeln. Nameserver-Änderungen sind wenige Sekunden später bereits am whois.nic.at sichtbar, die tatsächlichen Nameserver-Reload-Zeiten von nic.at habe ich ja bereits genannt, zu diesen Zeiten werden die Änderungen auch tatsächlich auf den nic.at-Root-Nameservern aktiv.

    Leider gibt es aus meiner Sicht auch etwas weniger erfreuliches zu berichten:

    • Der Tech-C Kontakt ist nicht durch mich beeinflussbar, da trägt sich fix [netcup] Felix P. als "Felix Preuss" mit seinen Daten ein. Ich bevorzuge selbst mit meinem Handle aufzuscheinen, gemäß Support wurde mir nur mitgeteilt das wäre nicht möglich. War bisher bei allen Registraren bei denen ich war problemlos möglich. Das ist somit sehr überraschend und unerfreulich.
    • Im Whois fehlt bei meinem Handle meine E-Mail-Adresse und Telefonnummer. Mag sein, dass andere Kunden bevorzugen diese Daten nicht zu veröffentlichen, ich möchte aber das diese Daten aufscheinen. Auch das ist gemäß Support (Ticket [NC#2017082310003211]) nicht anpassbar, auch nicht vom Support manuell. Das ist somit ebenfalls sehr überraschend und unerfreulich.
    • Was außerdem noch aufgefallen ist, der Screenshot zur DNSSec-Konfiguration im Wiki ist veraltet bzw. nicht mehr zutreffend. Im Wiki wird suggeriert man müsse für DNSSec den PublicKey (Base64-kodierte, lange Form) einfügen. Das ist jedoch falsch - korrekt ist den z.B. mittels dnssec-dsfromkey ermittelten SHA256-Hash seines DNSSec-PublicKeys in das Formular einzutragen, also z.B. NICHT AwEAAfkizZhZ9JIJae1HfRkcTFohfZJTNaagAcK+FiapxTlXV3hUaS5j zrDG3pq6tcD10dCCFhW5ottpaS/3udxAxU0szo+V/FQm/qUkoZ/Er5h2 JT/s44OXuqyqyQqqZJbokMs3zuZV4CAe4+nm0aYl7AEwgS+A1Kafb1BL XIkxxfIulhFJEJYiFxzeNpdG/DWmSisUHb2msyTsMqwM/0+JVnnxEmGD 8Tya99DnQssX40mQpE4BNoMq37/iA94ZVcGPv11dMb5NGfOd8blKvF5v Rv1cPTrn/cQVZp7NKqW6KcrVFixN38pAdlgVMA3/CVzkkUbkLLNTrCkS /n1Ki+tRf40=sondern korrekt 368431C5B526955803D14E4448D146BB99F3C5EE723CDD9E2B4C82C335C37284

  • Firewall für Vserver

    Deine IPTables Scripts behandeln nur IPv4, kein IPv6

    UFW handled mir die IPv6-Regeln völlig automatisch und synchron dazu mit.


    30x sudo iptables aufzurufen ist nicht grade hübsch, man legt sich dazu EIN Script an welches man von einem einzigen sudo iptables laden lässt.


    Wo hängst Du das IP-Tables Script ein? Wie überwachst Du, dass die Regeln korrekt appliziert wurden und auch bei Restart von Networking oder der Maschine wieder zur Anwendung kommen? Alles Dinge, die man freilich auch selbst sich überlegen und wunderbar lösen kann, aber man kann freilich auch das Framework das sich andere dafür schon ausgedacht und implementiert haben nutzen -> UFW.


    Wenn Du kein UFW verwenden möchtest, dann erfinde zumindest nicht die Lösung neu, sondern mache es so wie die Debian-Leute es empfehlen.

  • Firewall für Vserver

    Welche Distribution setzt Du ein?

    Ich bin mittlerweile davon abgekommen IPTables manuell mittels Scripts zu konfigurieren, verwende stattdessen das (zumindest bei Debian und Ubuntu) nutzbare Paket uwf (auf Ubuntu ohnehin per Default installiert, auf Debian über die Paketverwaltung nachinstallierbar).

  • Beta: Domains jetzt live im CCP bestellbar

    Danke @Georg für den Hinweis auf Reseller-Account.

    Nach Durchsicht des Threads Reselling von Domains: Geschlossene Beta-Phase gestartet denke ich aber, dass der Unterschied für Reseller nur die freie Handle-Verwaltung ist, andere Unterschiede hätte ich in den dort geposteten Screenshots jetzt nicht bemerkt. Vielleicht kann sich ja [netcup] Felix P. oder [netcup] Johannes B. hierzu äußern.


    Wenn man also nicht bei der Bestellung bereits seine eigenen Nameserver angeben oder - noch besser - gleich alle Daten im Zuge des Transfers unverändert übernehmen kann, dann bliebe mir nur zu pokern.


    Die Reload-Zeiten bei nic.at sind 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ).


    Wenn ich angenommen um 19:05 transferiere bleibt mir hoffentlich genügend Zeit bis 21:00, in der hoffentlich der Transfer abgeschlossen ist und ich alle Einstellungen (DNSSec und Nameserver-Einträge) wieder wie gewünscht übers Netcup-Domainverwaltungs-Interface konfiguriert habe, sodass die zwischenzeitlich gesetzten NetCup-Nameserver-Einträge gar nie nach außen sichtbar geworden wären. Hat jemand hier schon eine .at Domain transferiert? Geht das in "Echtzeit" und werden die Änderungen vom Roboter zeitnah in der nic.at Registry eingetragen, sodass sich dieser Plan zeitlich ausgeht?

  • Beta: Domains jetzt live im CCP bestellbar

    Danke CmdrXay für den Screenshot - aber das scheint mir ein Screenshot aus Deiner Domain-Verwaltung NACH Abschluss der Bestellung bzw. des Transfers zu sein. Während des Bestell- bzw. Transfer-Prozesses wird offenbar NICHT angeboten eigene Nameserver einzutragen.


    Dein Hinweis betreffend TTL zeigt mir zudem, dass Du meine Frage bzw. mein Wunschszenario offenbar missverstanden hast. Ich will nur den Registrar wechseln, ich will KEINE Nameserver wechseln. Ich betreibe drei authoritative Nameserver selbst und das soll auch so bleiben. Die in der nic.at-Registry hinterlegten Nameserver und DNSSec-Einträge sollen beim Transfer möglichst unberührt bleiben.

  • Beta: Domains jetzt live im CCP bestellbar

    Ich möchte eine .at Domain ohne Unterbrechung zu Netcup transferieren. Im Zuge des Transfers sollen also die bei nic.at die hinterlegten Nameserver NICHT verändert sondern meine drei bestehenden Nameserver beibehalten werden.


    Sehe ich das richtig, dass das nicht möglich ist? Der hier unter https://www.netcup-wiki.de/wiki/Domains_CCP#Bestellung skizzierte Bestellprozess sieht offenkundig keine Beibehaltung der bestehenden NS-Records oder die Angabe von Kunden-Nameservern vor, sondern provisioniert erst mal jedenfalls die NetCup-Nameserver, was natürlich eine Unterbrechung der Verfügbarkeit meiner Services auf dieser Domain zur Folge hat.

  • Von PHP5 auf PHP7 migrieren - Wie am sichersten?

    Welche Debian-Version nutzt Du?

    Ich mutmaße Du hast nicht auf Debian 9 (Stretch) migriert, sondern nutzt die OldStable Debian 8 (Jessie) oder gar noch Debian 7 (Wheezy).

    Bei Debian 9 käme PHP7 automatisch mit, ältere Releases bieten über die Paketverwaltung regulär aber nur PHP5 an.


    Wenn Du Deine Debian-Release nicht auf 9 (Stretch) hochziehen willst oder kannst, kannst Du durch Nutzung alternativer Paketquellen wie z.B. https://www.dotdeb.org dennoch auf Debian 7 oder 8 bereits PHP7 einsetzen.

  • Domänencontroller auf vServer

    Technisch theoretisch zwar möglich, aber ich wüsste ad-hoc nicht wie du das auf einer bei NetCup gehosteten VM korrekt lizenzierst. Microsoft lizenziert keine VMs, sondern physisches Blech mit physischen CPUs bzw. Kernen. Ich würde für so ein Vorhaben daher einen Hoster wählen, der dir die Windows-Lizenz mitvermietet oder gleich in der Microsoft Azure Cloud hosten, dann brauchst Du Dich um die Lizenzierung nicht zu kümmern. Was das VPN angeht würde ich mich in Direct Access und Offline Domain Join einlesen.