Il nostro server email () è stato migrato sul nostro server bare metal sponsorizzato da Xenyth a Toronto. Ora stiamo utilizzando uno spazio IP pulito annunciato tramite BGP con il nostro AS per migliorare la deliverability delle email evitando che i vicini IP/AS inviino spam.

@bkong_a Ad esempio, il nostro server di Toronto ha Xenyth come nostro fornitore diretto. Xenyth instrada attraverso la propria infrastruttura verso i propri upstream (Arelion, GTT, Zayo e anche Hurricane Electric solo IPv6) e peer (sugli scambi Onix e TorIX insieme a peer privati come Google).

@bkong_a Abbiamo il nostro AS (Sistema Autonomo) per implementare le nostre reti e il routing. Lo usiamo per annunciare il nostro spazio IP ai nostri fornitori e controllare come gli annunci vengono utilizzati dai loro upstream. Per le nostre reti DNS anycast, dobbiamo fare un'ampia ingegneria del traffico.

@bkong_a Per il DNS anycast, abbiamo 11 posizioni per ns1 e 9 posizioni per ns2. Ecco un esempio di come funziona l'ingegneria del traffico dalla nostra posizione ns1 Vultr di Francoforte: Controlliamo quali upstream/peer ricevono le nostre rotte da Vultr e ottimizziamo il routing upstream.

@bkong_a Attualmente non abbiamo server che abbiano direttamente più upstream separati. Ciò significa che non abbiamo ancora un caso d'uso per importare le rotte dai nostri upstream e ottimizzare dove instradare in base al routing BGP. Tuttavia, abbiamo in programma di farlo per un server in arrivo.

@bkong_a Al momento, stiamo semplicemente esportando le nostre rotte al nostro unico upstream diretto da ciascun server dove utilizziamo BGP. Per le istanze DNS anycast, annunciamo un IPv4 /24 e un IPv6 /48 per uso in produzione insieme a un altro IPv6 /48 per esperimenti di ingegneria del traffico.

@bkong_a Anycast significa che lo stesso blocco IP viene annunciato in più posizioni, quindi i fornitori decideranno in base a decisioni di routing di consenso distribuito. In generale, si preferiscono percorsi più brevi e quelli per cui vengono pagati (clienti di transito) sono preferiti rispetto a quelli per cui non lo sono.

@bkong_a Per la nostra sede di Toronto, annunciamo anche un unicast IPv4 /24 e IPv6 /48. I blocchi IPv4 /24 e IPv6 /48 sono le unità più piccole supportate per il routing attraverso internet pubblico, quindi è per questo che vengono utilizzati. Blocchi più piccoli possono essere utilizzati all'interno di Xenyth o della nostra rete.

@bkong_a Il nostro server Xenyth fa un po' di routing effettivo perché ha 2 container: uno che fornisce un'istanza DNS anycast ns2 e l'altro che fornisce il nostro server di posta. Abbiamo solo configurato staticamente quel routing, ma sarebbe tecnicamente possibile utilizzare BGP per questo.

@Avamander @HSVSphere Stalwart non esisteva quando abbiamo iniziato a ospitare la nostra email. Non era disponibile come opzione, e ci è voluto un po' di tempo prima che iniziasse a diventare più completo e maturo. Sembra interessante, ma abbiamo un server di posta in produzione e non possiamo facilmente sostituirlo o provare una nuova implementazione.

@Avamander @HSVSphere Ci sono middlebox con problemi di compatibilità con DNSSEC e ha una scarsa adozione al di là della maggior parte dei server resolver DNS principali e dei fornitori di DNS autonomi che lo implementano. Lo stesso vale per molte cose come QUIC e WebRTC. DNSSEC funziona bene nella pratica ed è molto prezioso.

@Avamander @HSVSphere Alcuni browser applicano politiche di Trasparenza dei Certificati. Al di fuori dell'uso del browser, inclusi MTA-STS con i server email, tali requisiti non sono applicati nella pratica. Spesso non vengono seguiti. WebPKI è utilizzato anche per app native, tra server, ecc. non solo per i browser.

@Avamander @HSVSphere Ci sono altri modi per farlo oltre a BGP. Non è un sistema particolarmente sicuro. Il WebPKI non basato su browser non applica il CT ed è una grande parte del traffico TLS. Quasi nessuno monitora il CT per i propri servizi, quindi non fornisce ciò che viene descritto come fornito per le organizzazioni non Google.

@Avamander @HSVSphere Google ha abbandonato sia il pinning dei certificati dinamico che statico per i non-Google. Hanno affermato di aver smesso di usarlo ma hanno continuato a farlo. È una violazione delle leggi antitrust. Fa parte di una enorme quantità di comportamenti anticoncorrenziali disonesti da parte di Google e MTA-STS è parte di questo.

@Avamander @HSVSphere WebPKI dipende dalla sicurezza DNS. WebPKI si fida del registro dei domini, del TLD e dell'IANA. WebPKI non evita che il DNS sia una radice di fiducia perché si basa sulla verifica del controllo DNS tramite la Validazione del Dominio. Il TLD può puntare il tuo DNS altrove e ottenere certificati per il tuo dominio.

@Avamander @HSVSphere WebPKI dipende dalla sicurezza DNS. WebPKI si fida del registro dei domini, del TLD e dell'IANA. WebPKI non evita che il DNS sia una radice di fiducia perché si basa sulla verifica del controllo DNS tramite la Validazione del Dominio. Il TLD può puntare il tuo DNS altrove e ottenere certificati per il tuo dominio.

@Avamander @HSVSphere WebPKI dipende fondamentalmente dalla sicurezza DNS. MTA-STS è fondamentalmente insicuro e non è altro che un approccio debole e temporaneo. L'email dipende fondamentalmente dalla sicurezza DNS per molteplici motivi e anche WebPKI dipende dalla sicurezza DNS. Non ci si può liberare di quelle bugie con noi, mi dispiace.

@Avamander @HSVSphere WebPKI dipende fondamentalmente dalla sicurezza DNS. MTA-STS è fondamentalmente insicuro e non è altro che un approccio debole e temporaneo. L'email dipende fondamentalmente dalla sicurezza DNS per molteplici motivi e anche WebPKI dipende dalla sicurezza DNS. Non ci si può liberare di quelle bugie con noi, mi dispiace.

@1ngenious @TorontoIX Attualmente abbiamo 5 server dedicati per gli aggiornamenti. I nostri server di aggiornamento fungono anche da sottoinsieme delle nostre 11 sedi per i servizi del nostro sito web/rete, che hanno anche 6 istanze VPS per fornire una copertura globale più ampia. Utilizziamo il server di Toronto anche per l'email e il DNS autorevole.

@1ngenious @TorontoIX è un contenitore di sistema su . è un altro contenitore di sistema che fornisce 1 delle 9 posizioni per la nostra rete anycast ns2. Gli altri 8 sono istanze VPS. Il nostro ns1 è composto da 11 istanze VPS Vultr.