Unser E-Mail-Server () wurde auf unseren Bare-Metal-Server migriert, der von Xenyth in Toronto gesponsert wird. Wir verwenden jetzt sauberen IP-Raum, der über BGP mit unserem AS angekündigt wird, um die E-Mail-Zustellbarkeit zu verbessern, indem wir verhindern, dass IP/AS-Nachbarn Spam versenden.

@bkong_a Zum Beispiel hat unser Toronto-Server Xenyth als unseren direkten Anbieter. Xenyth leitet über ihre Infrastruktur zu ihren Upstreams (Arelion, GTT, Zayo und auch IPv6-only Hurricane Electric) und Peers (an den Onix- und TorIX-Börsen sowie privaten Peers wie Google).

@bkong_a Wir haben unser eigenes AS (Autonomes System), um unsere eigenen Netzwerke und das Routing zu implementieren. Wir nutzen es, um unseren IP-Raum unseren Anbietern anzukündigen und zu kontrollieren, wie die Ankündigungen von ihren Upstreams verwendet werden. Für unsere Anycast-DNS-Netzwerke müssen wir umfangreiche Traffic-Engineering-Maßnahmen durchführen.

@bkong_a Für Anycast DNS haben wir 11 Standorte für ns1 und 9 Standorte für ns2. Hier ist ein Beispiel, wie das Traffic Engineering von unserem ns1 Vultr Frankfurt Standort funktioniert: Wir steuern, welche Upstreams/Peers unsere Routen von Vultr erhalten und optimieren das Upstream-Routing.

@bkong_a Wir haben derzeit keine Server, die direkt mehrere separate Upstreams haben. Das bedeutet, dass wir noch keinen Anwendungsfall für den Import der Routen von unseren Upstreams und die Anpassung der Routen basierend auf BGP-Routing haben. Wir planen jedoch, dies für einen kommenden Server zu tun.

@bkong_a Im Moment exportieren wir nur unsere Routen zu unserem einzelnen direkten Upstream von jedem Server, wo wir BGP verwenden. Für die Anycast-DNS-Instanzen kündigen wir ein IPv4 /24 und ein IPv6 /48 für den Produktionsgebrauch an, zusammen mit einem weiteren IPv6 /48 für Experimente im Bereich Traffic Engineering.

@bkong_a Anycast bedeutet, dass derselbe IP-Bereich an mehreren Standorten angekündigt wird, sodass Anbieter basierend auf verteilten Konsens-Routing-Entscheidungen entscheiden. Im Allgemeinen werden kürzere Routen bevorzugt, und Routen, für die sie bezahlt werden (Transitkunden), werden gegenüber denen bevorzugt, für die sie nicht bezahlt werden.

@bkong_a Für unseren Standort in Toronto kündigen wir auch ein Unicast IPv4 /24 und IPv6 /48 an. IPv4 /24 und IPv6 /48 Blöcke sind die kleinsten unterstützten Einheiten für das Routing über das öffentliche Internet, deshalb werden diese verwendet. Kleinere Blöcke können auch innerhalb von Xenyth oder unserem eigenen Netzwerk verwendet werden.

@bkong_a Unser Xenyth-Server übernimmt ein wenig tatsächliches Routing selbst, da er 2 Container darauf hat: einer bietet eine ns2 Anycast-DNS-Instanz und der andere unseren Mailserver. Wir haben dieses Routing statisch konfiguriert, aber es wäre technisch möglich, BGP dafür zu verwenden.

@Avamander @HSVSphere Stalwart existierte nicht, als wir anfingen, unseren eigenen E-Mail-Dienst zu hosten. Es war nicht als Option verfügbar, und es dauerte eine Weile, bis es vollständiger und ausgereifter wurde. Es sieht interessant aus, aber wir haben einen Produktions-Mail-Server und können ihn nicht einfach austauschen oder eine neue Implementierung ausprobieren.

@Avamander @HSVSphere Es gibt Mittelboxen mit Kompatibilitätsproblemen bei DNSSEC, und die Akzeptanz ist außerhalb der meisten großen DNS-Resolver-Server und eigenständigen DNS-Anbieter gering. Das Gleiche gilt für viele Dinge wie QUIC und WebRTC. DNSSEC funktioniert in der Praxis gut und ist sehr wertvoll.

@Avamander @HSVSphere Bestimmte Browser setzen Richtlinien zur Zertifikatstransparenz durch. Außerhalb der Nutzung von Browsern, einschließlich für MTA-STS mit E-Mail-Servern, werden diese Anforderungen in der Praxis nicht durchgesetzt. Oft wird dem nicht gefolgt. WebPKI wird auch für native Apps, zwischen Servern usw. verwendet, nicht nur für Browser.

@Avamander @HSVSphere Es gibt andere Möglichkeiten, dies über BGP hinaus zu tun. Es ist kein besonders sicheres System. Non-Browser WebPKI erzwingt kein CT und ist ein großer Teil des TLS-Verkehrs. Kaum jemand überwacht CT für seine Dienste, sodass es nicht das bietet, was es für Nicht-Google-Organisationen darstellt.

@Avamander @HSVSphere Google hat sowohl dynamisches als auch statisches Zertifikat-Pinning für Nicht-Google fallen gelassen. Sie behaupteten, sie hätten damit aufgehört, haben es aber weiterhin verwendet. Das ist ein Verstoß gegen das Antitrustrecht. Es ist Teil einer enormen Menge an unehrlichem wettbewerbswidrigem Verhalten von Google, und MTA-STS gehört auch dazu.

@Avamander @HSVSphere WebPKI hängt von der Sicherheit des DNS ab. WebPKI vertraut dem Domain-Registrar, TLD und IANA. WebPKI vermeidet nicht, dass DNS eine Vertrauensbasis ist, da es auf der Überprüfung der Domainvalidierung und der DNS-Kontrolle basiert. TLD kann Ihr DNS anderswohin verweisen und Zertifikate für Ihre Domain erhalten.

@Avamander @HSVSphere WebPKI hängt von der Sicherheit des DNS ab. WebPKI vertraut dem Domain-Registrar, TLD und IANA. WebPKI vermeidet nicht, dass DNS eine Vertrauensbasis ist, da es auf der Überprüfung der Domainvalidierung und der DNS-Kontrolle basiert. TLD kann Ihr DNS anderswohin verweisen und Zertifikate für Ihre Domain erhalten.

@Avamander @HSVSphere WebPKI hängt grundlegend von der DNS-Sicherheit ab. MTA-STS ist grundlegend unsicher und nichts weiter als ein schwacher Übergangsansatz. E-Mail hängt aus mehreren Gründen grundlegend von der DNS-Sicherheit ab, und auch WebPKI hängt von der DNS-Sicherheit ab. Mit diesen Lügen kommen wir nicht durch, tut mir leid.

@Avamander @HSVSphere WebPKI hängt grundlegend von der DNS-Sicherheit ab. MTA-STS ist grundlegend unsicher und nichts weiter als ein schwacher Übergangsansatz. E-Mail hängt aus mehreren Gründen grundlegend von der DNS-Sicherheit ab, und auch WebPKI hängt von der DNS-Sicherheit ab. Mit diesen Lügen kommen wir nicht durch, tut mir leid.

@1ngenious @TorontoIX Wir haben derzeit 5 dedizierte Server für Updates. Unsere Update-Server fungieren auch als Teilmenge unserer 11 Standorte für unsere Website-/Netzwerkdienste, die ebenfalls 6 VPS-Instanzen haben, um eine breitere weltweite Abdeckung zu bieten. Wir nutzen den Server in Toronto auch für E-Mail und autoritativen DNS.

@1ngenious @TorontoIX ist ein Systemcontainer auf . ist ein weiterer Systemcontainer, der 1 der 9 Standorte für unser ns2 Anycast-Netzwerk bereitstellt. Die anderen 8 sind VPS-Instanzen. Unser ns1 besteht aus 11 Vultr VPS-Instanzen.