KB19 danke dir, das scheint komplett an mir vorbei gegangen zu sein. Habs angepasst und werd da mal ein Auge drauf haben.
Auch mit den Domainkeys
KB19 danke dir, das scheint komplett an mir vorbei gegangen zu sein. Habs angepasst und werd da mal ein Auge drauf haben.
Auch mit den Domainkeys
mainziman OK, das fänd ich ja klasse.
Aber sagt jemand relay.yourmailgateway.de was ?
Früher war der SPF "v=spf1 mx a -all" OK, jetzt plötzlich nicht mehr. Ich verwende zwar mein Webhosting nicht, aber wurde auch über keine Änderungen informiert.
Hat sich bei den Webhosting Pakete was am Mailing geändert?
Bekannter schickt mir gerade Screenshots per Messenger, dass seine Mails wegen SPF abgewiesen werden, da sie auch nicht vom Webhost kommen, sondern von einem von diesen IPs - relay.yourmailgateway.de.
Auch hab ich im DNS gerade gesehen, dass hier Domainkeys hinterlegt sind, die ich nicht angelegt hatte.
Bei mir war ein Zertifikat betroffen, worüber LE aber auch, wie schon geschrieben, per Mail informiert hatte.
Sicher, dass bei einem Debian Buster du wirklich eth0 als Interface hast und es nicht eher ens3 ist, oder irgendwas in der Richtung?
~76€ inkl. MwSt für 250/40 würde ich nun nicht als horrend teuer im Businessbereich ansehen, wenn man darauf angewiesen ist.
Und der entsprechende Privatkundenanschluß, ohne Entertain oder andere Addons, auch schon 60€ kostet ....
Investier die 10 Euro Ersparnis in einen Server und versuch das nicht zuhause zu betreiben.
Macht bestimmt Spaß, damit ein Cert mit 80-100 Einträgen zu Signieren...
Wieso sollte man 80-100 Einträge in ein Zertifikat packen?
acme.sh läuft auch völlig problemlos mit nem 15 Minuten wait timer.
ASS friend_of_root spricht von einem A-Record, nicht von einem NS-Record.
Aber auch NS Records haben eine TTL, welche nichts mit dem SOA zu tun haben - daher verstehe ich die SOA Argumente hier nicht, welche sich auf die gesamte Zone beziehen.
Wird der Record von den NC Servern, nach der Änderung, schon gar nicht aktualisiert ausgeliefert?
Dann mach ein Ticket auf, das hat dann nichts mit TTLs zu tun.
Kann meinen Vorrednern nur beipflichten. Mit Synology bisher nur gute Erfahrungen gemacht. Alle Synologys bisher mit WD Red bestückt.
damit Du sie durcheinanderwirfst
Naja, wer hier regelmäßig alles zu seinen Gunsten durcheinander wirft, darf das Publikum bestimmen ...
(was auch daran liegen könnte, dass kaum ein Mobilfunkbetreiber IPv6 bis zu den Heizflossen bringt)
Aussagen zur Verbreitung von IPv6 im Mobilfunk kamen zuallererst von dir.
Dass du ein Problem mit IPv6 hast, haben wir jetzt alle verstanden und ich lass das jetzt einfach auch mal so auf sich beruhen.
nebenbei: besorg Dir a ordentliche Quelle, denn die humbug, es gibt nur DREI Mobilfunkbetreiber in Österreich
und die heissen: A1, Orange, und Magenta
Liefer du doch zur Ausnahme mal Fakten ....
Aber einfach nochmals direkt, fürs ganze Land - https://stats.labs.apnic.net/ipv6/AT
(was auch daran liegen könnte, dass kaum ein Mobilfunkbetreiber IPv6 bis zu den Heizflossen bringt)
Hier mal ein wenig aufbereitet - https://www.datamate.org/statu…-mobilfunknetzen-in-dach/
"Österreich ist in DACH Schlusslicht bei der Einführung von IPv6." - ich glaube, ich verstehe langsam deine Haltung ....
analoges sehe ich beim Mailserver, kaum Versuche via IPv6 was abladen zu wollen, fast durchgehend per IPv4;
Kan ich nicht bestätigen. Sowohl privat als auch geschäftlich wird Mail mittlerweile viel per IPv6 eingeliefert.
Versuchter Spam und Bots kommen per IPv4, aber die zählt man ja nicht ....
Hast du an dem Link, an welchem die Switches angebunden sind, mal einen Client angebunden und getestet, ob dieser eine Adresse erhält?
Hin- und Rückroute müssen sich ja darüber im Klaren sein, dass eine IX jetzt nicht mehr verfügbar ist. Das propagiert sich ja nicht in die vorherigen Router
Das muß sich in allen Routern propagieren. Man muß natürlich immer davon ausgehen, einen Link, Router oder einen IX oder Transit Link verlieren zu können. Dies das darf das IGP nicht in Probleme bringen.
Wenn mit den Announcements gespielt wird, hast du Recht, dann wird es gefährlich, wenn Links ausfallen, auf welchen diese spezifischen Announcements propagiert werden.
Idealerweise sollte hier eher mit Kosten, für den Weg nach aussen und AS Path prepending für den Rückweg gearbeitet werden, dann passiert hier auch nichts.
Allokierte Prefixe in den Announcements zu splitten, gehört sich nicht oder anderst herum, wenn wer Prefixes in der Global Routing Tabel verliert, weil Links ausfallen, dann ist das wie, wenn man kein Mitleid hat, wenn kein Backup vorhanden ist ...