O nosso servidor de email () foi migrado para o nosso servidor bare metal patrocinado pela Xenyth em Toronto. Agora estamos a usar um espaço de IP limpo anunciado via BGP com o nosso AS para melhorar a entregabilidade de emails, evitando que vizinhos de IP/AS enviem spam.

@bkong_a Por exemplo, o nosso servidor em Toronto tem a Xenyth como nosso fornecedor direto. A Xenyth roteia através da sua infraestrutura para os seus upstreams (Arelion, GTT, Zayo e também o Hurricane Electric apenas IPv6) e pares (nas trocas Onix e TorIX, juntamente com pares privados como o Google).

@bkong_a Temos o nosso próprio AS (Sistema Autónomo) para implementar as nossas próprias redes e roteamento. Usamos isso para anunciar o nosso espaço de IP aos nossos provedores e controlar como os anúncios são utilizados pelos seus upstreams. Para as nossas redes DNS anycast, precisamos fazer uma engenharia de tráfego extensa.

@bkong_a Para DNS anycast, temos 11 localizações para ns1 e 9 localizações para ns2. Aqui está um exemplo de como a engenharia de tráfego funciona a partir da nossa localização ns1 Vultr Frankfurt: Controlamos quais upstreams/parceiros recebem nossas rotas da Vultr e ajustamos o roteamento upstream.

@bkong_a Atualmente, não temos servidores que tenham diretamente múltiplos upstreams separados. Isso significa que ainda não temos um caso de uso para importar as rotas dos nossos upstreams e ajustar onde roteamos com base no roteamento BGP. No entanto, planejamos fazê-lo para um servidor que está por vir.

@bkong_a Neste momento, estamos apenas a exportar as nossas rotas para o nosso único upstream direto de cada servidor onde usamos BGP. Para as instâncias de DNS anycast, anunciamos um IPv4 /24 e um IPv6 /48 para uso em produção, juntamente com outro IPv6 /48 para experimentação em engenharia de tráfego.

@bkong_a Anycast significa que o mesmo bloco de IP está a ser anunciado em múltiplas localizações, então os provedores decidirão com base em decisões de roteamento de consenso distribuído. Em geral, rotas mais curtas são preferidas e rotas pelas quais são pagos (clientes de trânsito) são preferidas em relação às que não são.

@bkong_a Para a nossa localização em Toronto, também anunciamos um unicast IPv4 /24 e IPv6 /48. Os blocos IPv4 /24 e IPv6 /48 são as menores unidades suportadas para roteamento através da internet pública, por isso é isso que está a ser utilizado. Blocos menores podem ser usados dentro da Xenyth ou da nossa própria rede também.

@bkong_a O nosso servidor Xenyth faz um pouco de roteamento real porque tem 2 containers: um que fornece uma instância DNS anycast ns2 e outro que fornece o nosso servidor de e-mail. Temos esse roteamento configurado estaticamente, mas seria tecnicamente possível usar BGP para isso.

@Avamander @HSVSphere O Stalwart não existia quando começámos a hospedar o nosso próprio email. Não estava disponível como uma opção, e levou algum tempo até começar a ser mais completo e maduro. Parece interessante, mas temos um servidor de email em produção e não podemos facilmente trocá-lo ou experimentar uma nova implementação.

@Avamander @HSVSphere Existem middleboxes com problemas de compatibilidade com DNSSEC e a sua adoção é fraca além da maioria dos servidores de resolução DNS principais e dos provedores de DNS independentes que o implementam. O mesmo se aplica a muitas coisas, como QUIC e WebRTC. O DNSSEC funciona bem na prática e é muito valioso.

@Avamander @HSVSphere Navegadores específicos impõem políticas de Transparência de Certificados. Fora do uso de navegadores, incluindo para MTA-STS com servidores de e-mail, esses requisitos não são aplicados na prática. Muitas vezes não são seguidos. WebPKI também é usado para aplicativos nativos, entre servidores, etc. não apenas navegadores.

@Avamander @HSVSphere Existem outras maneiras de fazer isso além do BGP. Não é um sistema particularmente seguro. O WebPKI não baseado em navegador não impõe CT e é uma grande parte do tráfego TLS. Quase ninguém monitora CT para seus serviços, então não fornece o que é retratado como fornecendo para organizações que não são do Google.

@Avamander @HSVSphere O Google abandonou tanto o pinning de certificados dinâmico quanto o estático para não-Google. Eles afirmaram que tinham parado de usá-lo, mas continuaram a usá-lo. É uma violação antitruste. É parte de uma enorme quantidade de comportamento anticompetitivo desonesto por parte do Google e o MTA-STS também faz parte disso.

@Avamander @HSVSphere WebPKI depende da segurança do DNS. WebPKI confia no registro de domínio, TLD e IANA. WebPKI não evita que o DNS seja uma raiz de confiança porque se baseia na validação de domínio verificando o controle do DNS. O TLD pode apontar seu DNS para outro lugar e obter certificados para seu domínio.

@Avamander @HSVSphere WebPKI depende da segurança do DNS. WebPKI confia no registro de domínio, TLD e IANA. WebPKI não evita que o DNS seja uma raiz de confiança porque se baseia na validação de domínio verificando o controle do DNS. O TLD pode apontar seu DNS para outro lugar e obter certificados para seu domínio.

@Avamander @HSVSphere WebPKI depende fundamentalmente da segurança do DNS. MTA-STS é fundamentalmente inseguro e não passa de uma abordagem fraca e temporária. O email depende fundamentalmente da segurança do DNS por várias razões e o WebPKI também depende da segurança do DNS. Não vão conseguir escapar com essas mentiras connosco, desculpem.

@Avamander @HSVSphere WebPKI depende fundamentalmente da segurança do DNS. MTA-STS é fundamentalmente inseguro e não passa de uma abordagem fraca e temporária. O email depende fundamentalmente da segurança do DNS por várias razões e o WebPKI também depende da segurança do DNS. Não vão conseguir escapar com essas mentiras connosco, desculpem.

@1ngenious @TorontoIX Atualmente temos 5 servidores dedicados para atualizações. Nossos servidores de atualização também atuam como um subconjunto das nossas 11 localizações para os serviços do nosso site/rede, que também possuem 6 instâncias de VPS para fornecer uma cobertura mundial mais ampla. Usamos o servidor em Toronto para e-mail e DNS autoritativo também.

@1ngenious @TorontoIX é um container de sistema em . é outro container de sistema que fornece 1 das 9 localizações para a nossa rede anycast ns2. Os outros 8 são instâncias VPS. O nosso ns1 é composto por 11 instâncias VPS da Vultr.