Google ist Dein Freund, Kapitel 3.6.2 hier:
https://www.denic.de/fileadmin…cumentation/DENIC-23p.pdf
QuoteDas DNSKEY-RRSet muss an allen autoritativen Servern identisch sein [sonst Ausgabe von
ERROR].
Mindestens einer der zur Registrierung übergebenen Schlüssel muss sichtbar sein [sonst
Ausgabe von ERROR]. Für jeden nicht sichtbaren Schlüssel wird eine WARNING erzeugt.
Eventuell im DNSKEY-RRSet zusätzlich vorhandene Schlüssel werden nicht betrachtet.
Was meinst Du mit "DNSSEC sollte auf dem Slave aber aktiviert sein"?
Ein Bind in aktueller Konfiguration unterstützt DNSSEC und hat dieses automatisch aktiviert. Du müsstest es also schon explizit deaktivieren.
Es geht auch nicht darum ob Du DNSSEC Validation aktiviert hast.
Wenn die Zone am Master signiert ist, und der Slave ein halbwegs aktueller Bind in der Default-Konfiguration ist, dann ist am Slave nichts besonderes zu berücksichtigen, eine DNSSEC aktivierte Zone sieht am Slave in der Config nicht anders aus als eine Zone ohne aktivem DNSSEC.
Ein Schreibfehler in der übergeordneten Zone (also beim Registrar) führt dazu, dass alle DNSSEC aktivierten Resolver die Signatur als ungültig ansehen werden und Deine Domain daher von allen DNSSEC aktivierten Resolvern nicht mehr korrekt aufgelöst werden kann.
Ob Dein Registrar beim Eintragen des ZSK(257) eine Prüfung vornimmt, und das Eintragen nur dann durchführt wenn der von Dir eingegebene Schlüssel zur aktuellen Zone passt lässt sich ohne den Registrar zu kennen nicht sagen. Einige Registries und/oder Registrare prüfen das und lehnen den Key wenn er zu einer Fehlkonfiguration führen würde ab. Aber verlassen darauf würde ich mich nicht.
Die Konfiguration der Slave Server ändert sich mit dnssec nicht.
Dein Fehlerszenario betreffend Schreibfehler ist mir unklar. Wenn aus Sicht bind keine passenden keyfiles vorhanden sind scheitert die Signatur und die Zone bleibt unsigniert.
Ja, der Verweis in der Config zeigt weiterhin auf das unsignierte (mit einem Editor änderbare) File.
Im Modus "inline-signing yes; auto-dnssec maintain;" muss du Dich um das signierte File und das Journal (jnl bzw. jbk) nicht kümmern, darum kümmert sich bind selbst.
Nachtrag: Wenn dich der Inhalt des ".signed" Files interessiert lässt sich dieses mit "named-checkzone" dumpen. Das Journal lässt sich mit named-journalprint anzeigen.
Im Betriebsmodus "inline-signing yes; auto-dnssec maintain;" ist es nicht nötig die Zone manuell mittels "rndc signing" zu signieren. Nach einem Reload von Bind müsste dieser automatisch die Zonen signieren, was Du mit entsprechenden Log-Output im SysLog nachvollziehen kannst.
Vielleicht hilft Dir ja mein HowTo: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/
Die DNSSEC Konfiguration startet in Kapitel 2.5
Mögliche Fehlerquellen:
Wir haben das Scheduling für IO-Operationen so erweitert, dass länger andauernde IO-Last nicht dazu führt, dass eine Herabstufung der Priorität derart große Auswirkungen hat, wie hier zum Teil geschildert. Ich würde Sie bitten dieses einmal zu testen.
Wunderbar, danke vielmals.
War hier im Thread bislang nur "stiller Mitleser".
Habe bis 29.01.2019 eine tägliche Datensicherung meines RS 500 SAS G7SEa1 mittels Veeam Backup Agent for Linux durchgeführt, ab 30.01.2019 war mir dies nicht mehr möglich, da nach ca. 20min die Disk-IO (Lesen) auf 1-8MB/Sek eingebrochen ist. Habe Veeam dann nach einigem Tüfteln - da nicht mehr praktikabel verwendbar - deaktiviert und die letzten Monate ein file-basiertes Backup mit Duplicity verwendet.
Motiviert durch diesen Thead habe ich heute mein damaliges Veeam-Backup erneut versucht (Config und Version unverändert wie im Jänner/Februar) => Klappt nun wieder problemlos. Disk-IO Lesen >30MB/Sec - der Backup Job ist in erwarteten 1,5 Stunden durchgelaufen.
=> Danke vielmals [netcup] Felix für die Änderung und auch an den Thread-Ersteller geomap und allen Mitwirkenden für das Aufzeigen und Dokumentieren dieser Problematik!
Es ist wie oben bereits skizziert best-practice einen KSK zu generieren, diesen über den Registrar in der übergeordneten Zone zu verankern und die Zone selbst mittels ZSK zu signieren. Man KANN das theoretisch auch anders machen (nur ZSK, kein KSK) - ich wüsste nur nicht, warum man sich das antun sollte, zumal das einen ZSK-KeyRollover erheblich verkompliziert.
Du beschreibst den Kontext Deiner Frage nicht, insofern ist meine Antwort sehr allgemein:
Der Zone Signing Key (Type 256 = ZSK) signiert die ganze Zone, also jeden einzelnen Eintrag in der Zone.
Der Key-Signing-Key (Type 257 = KSK) hingegen signiert nur den DNSKEY-Eintrag des Zone-Signing-Keys und wird in der darüber liegenden Zone verankert.
Beim Registrar hinterlegst du daher den KSK. Dieser signiert deinen ZSK. Wenn Du Dir das lieber "graphisch" veranschaulichen möchtest, hier kann man sich die Situation visualisieren lassen, z.B. anhand meiner Domain: http://dnsviz.net/d/hitco.at/dnssec/
Ein ausführliches How-To mit Erläuterung zum Thema findest Du hier: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/
Einer meiner Server (bzw. der Host-Node auf dem er läuft) fiel gestern Abend aus. Dazu erhielt ich von NetCup eine (vermutlich automatisiert) erstellte E-Mail.
Soweit vorbildlich, Server lief kurze Zeit später auch wieder.
Jedoch folgendes Feedback hierzu: Die E-Mail Header sind falsch eingerückt, sowohl in Thunderbird als auch in Roundcube-Webmail wird mir daher weder ein korrektes "From" noch ein korrektes "Subject" angezeigt. Hier ein Screenshot aus Thunderbird, es geht um die Zeile "Von: Tue". Die Zeile darüber die korrekt formatiert ist, ist eine von mir selbst erstellte Kopie der erhaltenen e-Mail die ich manuell im Header mittels Editor korrigiert habe (mir war nicht auf Anhieb klar worin das Problem bestand):
Konkretes Problem:
Die Einrückung von "To:", "Subject:" und "Date:" verwirrt die E-Mail Clients. Wenn man die Einrückung entfernt ist die Darstellung korrekt (siehe oben).
[netcup] Alexander - vielleicht möchte derjenige der für dieses Versand-Script zuständig ist dieses Problem korrigieren.
Ein Aspekt der oft übersehen wird: Ein Virenscanner der sich als Systemdienst tief im System verankert schwächt auch die Security. Wenn er korrekt funktioniert erkennt er zwar möglicherweise Malware. Aber er weist auch Sicherheitslücken und Bugs auf, und verringert daher die Systemstabilität, die Performance und potentiell auch die Verfügbarkeit. Somit ist die These "hilfts nix, schadet es nicht" aus meiner Sicht nicht zutreffend. Man muss den Einsatz-Zweck der VM und die Vor- und Nachteile beurteilen.
Der entscheidende Punkt ist, ob auf dem Server jemand Files ablegen und diese gar öffnen oder exekutieren kann/darf.
Dass man auf einem Server nicht "im Web surft" versteht sich von selbst.
Wenn der Server nur von einem einzigen vertrauenswürdigen und kompetenten Admin bedient wird, und sich sonst niemand anmelden kann, dann ist ein Malware-Schutz denke ich entbehrlich. Am Anderen Ende des Einsatz-Spektrums wäre der schon angesprochene Terminalserver, wo Endanwender Dinge öffnen oder gar exekutieren können - diesen würde ich in Bezug auf Malware-Schutz absichern wie einen Client, also mit On-Access-Wächter.
Mit speedtest-cli von meinem "RS 500 SAS G7SEa1" getestet: 415MBit Download, 370MBit Upload
Mit meinem "VPS 500 G7" getestet: 320MBit Download, 168MBit Upload
Ist nur eine Momentaufnahme. Werte schwanken durchaus. Aber Werte unter 100MBit hatte ich noch nie.
Ich würde mal mit "iftop" oder "vnstat -l" prüfen, was der Server gerade so am Netzwerk zu tun hat und Auslastung besteht.
Führe folgendes aus:
und poste uns hier den Inhalt von output.txt in Code-tags. So können wir prüfen, ob nicht doch irgend ein von Dir im RegEdit-GUI nicht erkennbarer Fehler an Deiner Konfiguration vorliegt. Typische Fehler sind z.b. Spaces vor oder nach dem Valuename etc... die man im GUI nicht bemerkt.
Um noch was zum Topic beizutragen:
Auch der Chromium-basierte Edge-Dev redirected bei Eingabe von lieben-gruß.de tatsächlich zu lieben-gruss.de
Scheint als würde von den getesteten Browsern (Chrome, Edge, Edge-Dev, Firefox) nur Firefox tatsächlich lieben-gruß.de abzurufen.
Betreffend Edge:
Edge unter Windows 10 hat eine EdgeHTML Engine integriert
Edge-Dev ist in Public-Beta zur separaten Installation verfügbar, dieser hat eineChromium-Engine integriert
Der User-Agent String von Edge lautet aktuell:
da ist also sehr wohl "Edge" klar erkennbar. Der User-Agent String von Edge-Dev (Chromium-basiert) hingegen gibt sich nicht als "Edge" sondern "Edg" aus:
Jener von Chrome zum Unterschied:
Und Firefox:
Bei derart hochfrequenten Änderungen musst Du die Zonen ja ohnehin dynamisch (im Fall von Bind z.B. mittels nsupdate) modifizieren, und kannst nicht das Zonen-File editieren (das würde nämlich jedes mal ein Reload von Bind nötig machen um wirksam zu werden). In diesem Fall - wenn nsupdate verwendet wird - wird auch kein AXFR sondern ein IXFR (inkrementell) ausgelöst. Ich sehe da kein Problem mit 10 Änderungen pro Sekunde, das geht problemlos, automatisch und sehr zeitnah.
Die Config per rsync rüberzuschieben ist nur dann sinnvoll durchführbar, wenn alle Zonen statisch sind.
Wie hast Du vor DNSSEC zu konfigurieren? Bei BIND nutze ich z.B. gerne "auto-dnssec maintain" und muss mich um nichts kümmern. Die Zonen sind dann allerdings nicht statisch sondern sämtliche DNSSEC Einträge werden automatisch von Bind gewartet - die Slaves bekommen die Änderungen unmittelbar und ebenfalls ohne mein Zutun mittels AXFR.
Tja, jetzt wundern wir uns also wirklich was alles geht.
QuoteKann es den gefährlich sein einen einen Exit-Node zu betreiben?
Das hängt davon ab, welche "Gefahren" Dir wie bedrohlich erscheinen.
Angenommen es werden schwere Straftaten (z.B. Terrorismus, Bombendrohungen etc...) begangen, die auf eine IP-Adresse welche Dir zugeordnet wird zurückgeführt werden können. Dann bist Du erst einmal frontal in der "Schuss-Linie", musst dich de-fakto "freibeweisen", dass die Maschine nicht von Dir sondern von beliebig vielen dir gar nicht bekannten Personen als Exit-Node verwendet wurde. Wenn die Gefahr noch aufrecht ist (z.B. Bombendrohung) dann haben die Ermittlungsbehörden auch entsprechend starken Druck - da prüft man nicht erst ob ein Indiz stimmig ist, da wird jedem Verdacht nachgegangen. Der Provider rückt Deinen Namen raus und eine halbe Stunde später läutet es bei Dir an der Türe (sofern überhaupt geläutet und nicht gleich geöffnet wird).
Ich denke es könnte den meisten Menschen erstmal sehr unwohl dabei sein, wenn Polizisten mit schwerer Bewaffnung die Wohnung stürmen, durchsuchen, eventuell auch alle Datenträger und IT-Geräte in der Wohnung beschlagnahmen... So eine Hausdurchsuchung verursacht eventuell Schäden, jedenfalls aber große Unannehmlichkeiten. Du wirst dir vermutlich - auch wenn Du unschuldig bist - rechtliche Unterstützung organisieren, das kostet Geld. Im Best-Case klärt sich die Sache in wenigen Tagen auf und Du bekommst Dein Zeug unversehrt wieder. Wenn es schlecht läuft tut man Deine Behauptungen erst mal als Schutzbehauptungen ab, wird dich stundenlang befragen und Du bekommst Dein Zeug erst Monate später zurück.
abstrusen Annahme aus, dass Gehörlose, Schwerhörige, Blinde und Sehschwache automatisch Sozialhilfe benötigen würden?!
Wenn das so ankam, dann entschuldige ich mich - das war meinerseits nicht gemeint und auch (wie hoffentlich dennoch ersichtlich war) nicht der Punkt meines Postings den ich ansprechen wollte.
Was die Gebührenpflicht trotz Gehörlosigkeit angeht: Die GIS-Gebühr musst Du - so wie sie konstruiert ist - als Rundfunksteuer betrachten. Es spielt keine Rolle, ob Du den Content des ORF tatsächlich konsumierst oder ob Du dazu überhaupt in der Lage bist (körperlich oder auch technisch gesehen). Sobald man ein Rundfunkgerät besitzt hat man zu zahlen. Und die hierbei benachteiligte Gruppe sind nicht nur Gehörlose - es gibt zig andere Beispiele wo gar kein Content konsumiert wird und dennoch Gebührenpflicht besteht.
