Notre serveur de messagerie () a été migré vers notre serveur bare metal sponsorisé par Xenyth à Toronto. Nous utilisons désormais un espace IP propre annoncé via BGP avec notre AS pour améliorer la délivrabilité des e-mails en évitant d'avoir des voisins IP/AS envoyant du spam.

@bkong_a Par exemple, notre serveur de Toronto a Xenyth comme fournisseur direct. Xenyth passe par son infrastructure vers ses fournisseurs (Arelion, GTT, Zayo et également Hurricane Electric uniquement en IPv6) et ses pairs (sur les échanges Onix et TorIX ainsi que des pairs privés comme Google).

@bkong_a Nous avons notre propre AS (Système Autonome) pour mettre en œuvre nos propres réseaux et routages. Nous l'utilisons pour annoncer notre espace IP à nos fournisseurs et contrôler comment les annonces sont utilisées par leurs upstreams. Pour nos réseaux DNS anycast, nous devons effectuer une ingénierie de trafic extensive.

@bkong_a Pour le DNS anycast, nous avons 11 emplacements pour ns1 et 9 emplacements pour ns2. Voici un exemple de la façon dont l'ingénierie du trafic fonctionne depuis notre emplacement ns1 Vultr à Francfort : Nous contrôlons quels upstreams/peers reçoivent nos routes depuis Vultr et ajustons le routage en amont.

@bkong_a Nous n'avons actuellement aucun serveur qui dispose directement de plusieurs upstreams séparés. Cela signifie que nous n'avons pas encore de cas d'utilisation pour importer les routes de nos upstreams et ajuster où nous routons en fonction du routage BGP. Cependant, nous prévoyons de le faire pour un serveur à venir.

@bkong_a Pour le moment, nous exportons simplement nos routes vers notre unique upstream direct depuis chaque serveur où nous utilisons BGP. Pour les instances DNS anycast, nous annonçons un IPv4 /24 et un IPv6 /48 pour une utilisation en production, ainsi qu'un autre IPv6 /48 pour des expérimentations en ingénierie de trafic.

@bkong_a Anycast signifie que le même bloc d'IP est annoncé à plusieurs endroits, donc les fournisseurs décideront en fonction des décisions de routage par consensus distribué. En général, les routes plus courtes sont préférées et les routes pour lesquelles ils sont payés (clients de transit) sont préférées à celles pour lesquelles ils ne le sont pas.

@bkong_a Pour notre emplacement à Toronto, nous annonçons également un IPv4 unicast /24 et un IPv6 /48. Les blocs IPv4 /24 et IPv6 /48 sont les plus petites unités prises en charge pour le routage à travers l'internet public, c'est pourquoi ce sont ceux qui sont utilisés. Des blocs plus petits peuvent également être utilisés au sein de Xenyth ou de notre propre réseau.

@bkong_a Notre serveur Xenyth effectue un peu de routage réel lui-même car il a 2 conteneurs : l'un fournissant une instance DNS anycast ns2 et l'autre fournissant notre serveur de messagerie. Nous avons simplement ce routage configuré statiquement, mais il serait techniquement possible d'utiliser BGP pour cela.

@Avamander @HSVSphere Stalwart n'existait pas lorsque nous avons commencé à héberger notre propre email. Ce n'était pas disponible en tant qu'option, et il a fallu un certain temps pour qu'il devienne plus complet et mature. Cela semble intéressant mais nous avons un serveur de messagerie en production et nous ne pouvons pas facilement le remplacer ou essayer une nouvelle implémentation.

@Avamander @HSVSphere Il existe des middleboxes avec des problèmes de compatibilité DNSSEC et son adoption est faible en dehors de la plupart des serveurs de résolveurs DNS majeurs et des fournisseurs de DNS autonomes qui l'implémentent. Il en va de même pour beaucoup de choses comme QUIC et WebRTC. DNSSEC fonctionne bien en pratique et est très précieux.

@Avamander @HSVSphere Certains navigateurs appliquent des politiques de transparence des certificats. En dehors de l'utilisation des navigateurs, y compris pour MTA-STS avec les serveurs de messagerie, ces exigences ne sont pas appliquées en pratique. Elles sont souvent ignorées. WebPKI est également utilisé pour les applications natives, entre serveurs, etc. pas seulement pour les navigateurs.

@Avamander @HSVSphere Il existe d'autres moyens de le faire au-delà de BGP. Ce n'est pas un système particulièrement sécurisé. Le WebPKI non basé sur le navigateur n'impose pas le CT et représente une énorme partie du trafic TLS. Presque personne ne surveille le CT pour ses services, donc cela ne fournit pas ce qu'on prétend qu'il fournit pour les organisations non-Google.

@Avamander @HSVSphere Google a abandonné à la fois le pinning de certificat dynamique et statique pour les non-Google. Ils ont prétendu avoir cessé de l'utiliser mais ont continué à l'utiliser. C'est une violation des lois antitrust. C'est une partie d'un énorme ensemble de comportements anticoncurrentiels malhonnêtes de la part de Google et MTA-STS en fait également partie.

@Avamander @HSVSphere WebPKI dépend de la sécurité DNS. WebPKI fait confiance au registre de domaine, au TLD et à l'IANA. WebPKI ne contourne pas le DNS en tant que racine de confiance car il est basé sur la validation de domaine vérifiant le contrôle DNS. Le TLD peut pointer votre DNS ailleurs et obtenir des certificats pour votre domaine.

@Avamander @HSVSphere WebPKI dépend de la sécurité DNS. WebPKI fait confiance au registre de domaine, au TLD et à l'IANA. WebPKI ne contourne pas le DNS en tant que racine de confiance car il est basé sur la validation de domaine vérifiant le contrôle DNS. Le TLD peut pointer votre DNS ailleurs et obtenir des certificats pour votre domaine.

@Avamander @HSVSphere WebPKI dépend fondamentalement de la sécurité DNS. MTA-STS est fondamentalement peu sûr et n'est rien d'autre qu'une approche temporaire faible. L'email dépend fondamentalement de la sécurité DNS pour plusieurs raisons et WebPKI dépend aussi de la sécurité DNS. Vous ne pourrez pas vous en tirer avec ces mensonges avec nous, désolé.

@Avamander @HSVSphere WebPKI dépend fondamentalement de la sécurité DNS. MTA-STS est fondamentalement peu sûr et n'est rien d'autre qu'une approche temporaire faible. L'email dépend fondamentalement de la sécurité DNS pour plusieurs raisons et WebPKI dépend aussi de la sécurité DNS. Vous ne pourrez pas vous en tirer avec ces mensonges avec nous, désolé.

@1ngenious @TorontoIX Nous avons actuellement 5 serveurs dédiés pour les mises à jour. Nos serveurs de mise à jour agissent également comme un sous-ensemble de nos 11 emplacements pour nos services de site web/réseau, qui disposent également de 6 instances VPS pour offrir une couverture mondiale plus large. Nous utilisons le serveur à Toronto pour les e-mails et le DNS autoritaire aussi.

@1ngenious @TorontoIX est un conteneur système sur . est un autre conteneur système fournissant 1 des 9 emplacements pour notre réseau anycast ns2. Les 8 autres sont des instances VPS. Notre ns1 est constitué de 11 instances VPS Vultr.