Beiträge von gunnarh

    Der Microsoft postfach-spezifische Spam-Filter erzeugt keine Rückweisung oder Black-Hole, sondern legt den Spam in den Junk-E-Mail Ordner.

    Wenn es Zustell-Probleme gibt, dann betreffen diese meiner Erfahrung nach die Mailserver-IP und sind postfach-unabhängig auch mit Test-Postfächern nachvollziehbar gewesen.


    Deine Einwände haben sicherlich ihre Berechtigung. Aber ohne periodisch eine Zustellung zu validieren wüsste ich auch keinen Mechanismus um dies zuverlässig zu prüfen. Die von Microsoft bereitgestellten Möglichkeiten (Link zu SNDS) um zu prüfen ob die eigene Mailserver-IP auf deren Blacklist steht lieferte mir seit Jahren noch nie einen Treffer, ist also wertlos.

    Meine 2ct zur Microsoft hotmail/live.de/outlook.com Mail-Problematik:


    Wenn der Microsoft-Server die Mails nicht annehmen oder dem Microsoft-Empfänger zustellen will, dann hilft nur ein Ticket hier einzuwerfen:

    http://go.microsoft.com/fwlink/?LinkID=614866


    Nach 1-3 Stunden kommt dann in der Regel eine automatisierte Antwort, und meist klappt es dann auch schon wieder. Wenn nicht nochmals auf die erhaltene Mail antworten, nach weiteren 1-3 Mails landet man dann bei einem tatsächlichen Menschen. Kostet freilich in Summe ein paar Stunden Zeit bis man wieder Mails an das Microsoft-Universum senden kann.


    Ich habe mir folgendes gebastelt, um das Auftreten einer solchen Situation automatisiert zu detektieren:


    1. ich besitze eine mein-microsoft-test-account@outlook.com Mail-Adresse. Dort habe ich auf https://outlook.com in diesem Postfach konfiguriert, dass eine eingehende Mail mit Subject "Mailserver-Testmail-*" an meine-am-netcup-server-gehostete-mailbox@hitco.at weitergeleitet und in Gelöschte Objekte verschoben werden soll.


    2. auf meinem Server sende ich per Cronjob mittels Script eine Mail an mein-microsoft-test-account@outlook.com und warte dann zwei Minuten lang, ob sie korrekt zu mir in die meine-am-netcup-server-gehostete-mailbox@hitco.at Mailbox geforwarded wird. Falls ja alles OK. Falls nein schlägt das Script alarm und ich kann mir das manuell ansehen was los ist (rejected oder geblackholed, lässt sich dann leicht prüfen und als Gegenmaßnahme ein Ticket einwerfen).

    Du möchtest schapitz.de also von von ns[1,2].ipixel.de resolven lassen?


    Dann ist die Zone hierfür aber komplett falsch konfiguriert.

    im SOA steht "ns2.schapitz.de" => Da müsste dann ns1.ipixel.de hin

    und die zwei NS Records dürfen nicht auf ns[1,2].schapitz.de lauten sondern müssen auf ns[1,2].ipixel.de lauten.

    und die beiden A-Records ns1.schapitz.de, ns2.schapitz.de sind obsolet.

    Reverse-DNS ist nicht nötig, ich kenne keine Registry die so etwas prüft.


    Deine ns1 und ns2 IP ist immer noch identisch, so funktioniert das nicht:


    Wie sieht Dein SOA aus?

    Hast Du die beiden Nameserver definiert?

    Verwendest Du IPv4 oder IPv6-DualStack?


    Hier mal als Beispiel mein autoritatives Setup, das du Dir mit einem simplen "dig soa ..." ohnehin von jeder x-beliebigen Domain (so auch von meiner) einfach so als Anschauungsbeispiel abfragen könntest:


    Ein Tipp noch: Es wäre denke ich hilfreich, wenn Du uns einfach die IP nennst, dann könnte man mit einem simplen dig abfragen woran es bei Deinem Setup fehlt. Was diese Anonymisierung von IP-Adressen soll verstehe ich ehrlich gesagt nicht ganz, denn spätestens wenn Du es erfolgreich geschafft hast schapitz.de erfolgreich an den neuen Nameserver zu delegieren können wir Dein Setup ja ohnehin abfragen.

    Nein.

    Vielleicht hilft es Dir, wenn Du Dir die Grafik in Kapitel 2.2 in meinem Tutorial auf Sicherer E-Mail-Dienste-Anbieter (DNSSec & DANE) ansiehst.


    Deine "Records" (z.B. A, AAAA, C-Name, ...) werden mit dem ZSK signiert.

    Der ZSK wird mit dem KSK signiert.

    Der Public-Key des KSK wird in der darüberliegenden Zone hinterlegt (DENIC).


    Update der Records sind nur möglich, wenn Du im Besitz des ZSK-PrivKey bist.

    Ein Update des ZSK ist autonom auf deinem Nameserver möglich, solange Du im Besitz des KSK-PrivKey bist.


    Lediglich für ein Rollover des KSK benötigst Du die Mitwirkung (WebInterface, API) der darüberliegenden Zone.

    Ein Rollover des ZSK hingegen kannst Du beim geschilderten Best-Practice Setup selbst durchführen.

    Ein Update der o.a. Records hingegen ist in jedem Fall autark möglich.

    Zitat

    "Inconsistent set of NS RRs (IP, NS host names)"

    und Du denkst der Fehler trifft nicht zu, oder was konkret ist nun Deine Frage?

    Dieser Inkonsistenz würde ich mal nachgehen, sie beseitigen, dann wird es auch mit der Delegation klappen. Tools wie dig sollten hierzu Deine Freunde sein.


    Deine Frage betreffend Domain1.de oder Domain2.de verstehe ich nicht. Du konfigurierst einen Nameserver, ob der nun ns[1,2].domain1.de oder ns[1,2].domain2.de lautet bleibt Dir überlassen.

    Es gibt kostenfreie nutzbare secondary Domain Server, z.B. von Hurricane Electric.


    Wobei: DENIC kann nicht unterscheiden, ob die beiden IPs vom gleichen Host bedient werden. Sofern sie also zumindest aus unterschiedlichen Subnetzen stammen wird das in der Praxis vermutlich funktionieren.


    Eventuell scheiterst Du ja an der Erstellung der in Deinem Fall nötigen Glue-Records?

    Ich rate Dir Kapitel 2.1.2 und 2.1.3 der DENIC Doku durchzulesen: https://www.denic.de/fileadmin…cumentation/DENIC-23p.pdf

    Nein, das hast du falsch verstanden.


    Ich wiederhole mich daher:

    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.

    Der Zone Signing Key (Type 256 = ZSK) signiert die ganze Zone, also jeden einzelnen Eintrag in der Zone.


    Der ZSK wird vom KSK abgesichert, welcher wiederum in der .DE Zone verankert wird.

    Der Hauptgrund dieser Best-Practice Vorgangsweise besteht darin, dass der Key-Rollover des ZSK bei diversen Nameserver-Implementierungen automatisch passiert bzw. man diesen i.d.R. eben gescriptet/automatisiert durchführt. Wohingegen der KSK ein statischer Key ist, der sich i.d.R. durch einen menschlichen, geplanten Eingriff ändert. Immerhin muss dazu dann ja eine API oder ein WebInterface "bedient werden", welcher den Key in der DE-Zone bei DENIC tauscht bzw. hier parallel zwei Keys als gültig hinterlegt und dann einen löscht (RollOver).

    Nein, der 256er Key ist nicht bei DENIC zu hinterlegen.


    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.


    Der derzeitige Zustand scheint mir korrekt zu sein.

    Da ist in der DENIC Registry noch kein DNSKEY hinterlegt.


    Du kannst das "live" prüfen ohne auf Nameserver-Updates warten zu müssen, indem Du mittels whois direkt Deine Domain abfrägst. Vergleiche mit einer DNSSEC registrierten Domain, bei Dir scheint da noch kein DNSKEY auf, bei bund.de beispielsweise schon.


    Das Eintragen mittels NetCup-Webinterface in die DENIC-Registry sollte "live" funktionieren. Wirksam wird es dann (und somit mit DNSViz prüfbar) sobald die DE-Root-Server reloaden, wie oft das bei DE-Domains passiert weiß ich nicht auswändig (bei AT-Domains gibt es hierfür fixe Zeiten mit 2-Stunden Intervall).

    Ja, ich betreibe eigene Nameserver und nutze DNSSEC - allerdings nicht mit einer DE-Domain, sondern mit ein paar .AT, .BIZ, .NET, .ORG Domains.


    Woran konkret scheiterst Du denn?

    Ganz grundsätzlich kann ich immer noch (obwohl mittlerweile ein paar Jahre alt) mein ausführliches HowTo aus dem Jahr 2015 empfehlen:

    Sicherer E-Mail-Dienste-Anbieter (DNSSec & DANE)


    Beispiele wie die WebOberfläche von NetCup beim Hinterlegen des KSK aussieht findest Du in meinem HowTo zwar nicht, aber im Kapitel 2.7 zeige ich das anhand von Screenshots mit zwei anderen Registraren. Die Vorgangsweise ist immer identisch - entweder man hinterlegt den PubKey oder den Hash davon (je nachdem wie der Provider bzw. die Registry das implementiert haben).


    Wie das bei NetCup mit DE-Domains aussieht ist im NetCup-Wiki dokumentiert:

    Domains CCP – netcup Wiki (netcup-wiki.de)

    Dein Vorhaben erscheint (nicht nur mir, sondern wie KB19 ja bereits sagte) etwas abenteuerlich.


    1. Deine Annahme du könntest Public-IPv4-Adressen oder Ranges eines Anbieters A so einfach bei einem anderen Anbieter B (Netcup) nutzen ist nicht so trivial umsetzbar. Dazu müssten die beiden Anbieter irgend eine Lösung bereitstellen, eine derartige Lösung kannst Du von einem (Massen-)hoster aber nicht erwarten. Welche Möglichkeit meint denn der Anbieter A der IPv4-Adressen hierfür offerieren zu können? Angenommen dieser würde sich hierzu bereiterklären bleibt immer noch die Frage ob Netcup Dir ebenfalls ein Angebot hierfür macht.

    2. Das mittels Tunneling/VPN oder ähnlicher Technologien selbst zu lösen wäre theoretisch zwar möglich, bedarf aber jedenfalls auch Server bei beiden Anbietern - da stellt sich dann die Frage warum dein Proxy nicht gleich bei Anbieter A läuft.

    3. Wie viele Proxy-Instanzen hast Du vor zu betreiben? Hast du dich schon mit einer Squid-Config die mehrere OUTGOING-IP-Adressen benutzt auseinandergesetzt? Bist du Dir sicher, dass das was du (vermutlich) erreichen möchtest so überhaupt realisiert werden kann? Nach welchem Regelwerk sollen denn die vielen outgoing IP-Adressen benutzt werden?