Nasz serwer e-mail () został przeniesiony na nasz serwer bare metal sponsorowany przez Xenyth w Toronto. Teraz korzystamy z czystej przestrzeni IP ogłoszonej za pośrednictwem BGP z naszym AS, aby poprawić dostarczalność e-maili, unikając sąsiedztwa IP/AS, które wysyłają spam.

@bkong_a Na przykład, nasz serwer w Toronto ma Xenyth jako naszego bezpośredniego dostawcę. Xenyth kieruje ruch przez swoją infrastrukturę do swoich upstreamów (Arelion, GTT, Zayo oraz również tylko IPv6 Hurricane Electric) i peerów (na giełdach Onix i TorIX oraz prywatnych peerach takich jak Google).

@bkong_a Mamy własny AS (Autonomous System) do wdrażania naszych własnych sieci i routingu. Używamy go do ogłaszania naszej przestrzeni IP naszym dostawcom i kontrolowania, jak ogłoszenia są wykorzystywane przez ich upstreamy. W przypadku naszych sieci DNS anycast musimy przeprowadzić rozbudowane inżynierie ruchu.

@bkong_a Dla DNS anycast mamy 11 lokalizacji dla ns1 i 9 lokalizacji dla ns2. Oto przykład, jak działa inżynieria ruchu z naszej lokalizacji ns1 Vultr we Frankfurcie: Kontrolujemy, które upstreamy/partnerzy otrzymują nasze trasy z Vultr i dostosowujemy routing upstream.

@bkong_a Obecnie nie mamy żadnych serwerów, które bezpośrednio miałyby wiele oddzielnych upstreamów. To oznacza, że jeszcze nie mamy przypadku użycia do importowania tras z naszych upstreamów i dostosowywania, gdzie kierujemy na podstawie routingu BGP. Planujemy to jednak zrobić dla jednego nadchodzącego serwera.

@bkong_a W tej chwili po prostu eksportujemy nasze trasy do naszego pojedynczego bezpośredniego dostawcy z każdego serwera, na którym używamy BGP. Dla instancji DNS anycast ogłaszamy IPv4 /24 oraz IPv6 /48 do użytku produkcyjnego, a także inną IPv6 /48 do eksperymentów z inżynierią ruchu.

@bkong_a Anycast oznacza, że ten sam blok IP jest ogłaszany w wielu lokalizacjach, więc dostawcy będą podejmować decyzje na podstawie rozproszonych decyzji o trasowaniu. Ogólnie rzecz biorąc, preferowane są krótsze trasy, a trasy, za które dostają zapłatę (klienci tranzytowi), są preferowane nad tymi, za które nie dostają.

@bkong_a Dla naszej lokalizacji w Toronto ogłaszamy również unicast IPv4 /24 oraz IPv6 /48. Bloki IPv4 /24 i IPv6 /48 to najmniejsze wspierane jednostki do routingu w internecie publicznym, dlatego właśnie te są używane. Mniejsze bloki mogą być również używane w ramach Xenyth lub naszej własnej sieci.

@bkong_a Nasz serwer Xenyth wykonuje trochę rzeczywistego routingu, ponieważ ma na sobie 2 kontenery: jeden zapewniający instancję DNS anycast ns2, a drugi zapewniający nasz serwer pocztowy. Mamy ten routing skonfigurowany statycznie, ale technicznie możliwe byłoby użycie BGP do tego.

@Avamander @HSVSphere Stalwart nie istniał, gdy zaczynaliśmy hostować naszą własną pocztę e-mail. Nie był dostępny jako opcja, a zajęło to trochę czasu, zanim stał się bardziej kompletny i dojrzały. Wygląda interesująco, ale mamy serwer pocztowy produkcyjny i nie możemy łatwo go wymienić ani wypróbować nowej implementacji.

@Avamander @HSVSphere Istnieją urządzenia pośredniczące z problemami z kompatybilnością DNSSEC, a jego adopcja jest słaba poza większością głównych serwerów rozwiązywania DNS i samodzielnych dostawców DNS, którzy go wdrażają. To samo dotyczy wielu rzeczy, takich jak QUIC i WebRTC. DNSSEC działa dobrze w praktyce i jest bardzo wartościowy.

@Avamander @HSVSphere Niektóre przeglądarki egzekwują zasady przejrzystości certyfikatów. Poza użyciem przeglądarek, w tym dla MTA-STS z serwerami pocztowymi, te wymagania nie są w praktyce egzekwowane. Często nie są przestrzegane. WebPKI jest również używane dla aplikacji natywnych, między serwerami itp., a nie tylko w przeglądarkach.

@Avamander @HSVSphere Istnieją inne sposoby, aby to zrobić poza BGP. To nie jest szczególnie bezpieczny system. WebPKI poza przeglądarką nie egzekwuje CT i stanowi ogromną część ruchu TLS. Prawie nikt nie monitoruje CT dla swoich usług, więc nie zapewnia tego, co jest przedstawiane jako zapewniające dla organizacji niebędących Google.

@Avamander @HSVSphere Google zrezygnował zarówno z dynamicznego, jak i statycznego przypinania certyfikatów dla użytkowników spoza Google. Twierdzili, że przestali z tego korzystać, ale nadal to robili. To naruszenie przepisów antymonopolowych. To część ogromnej ilości nieuczciwych praktyk antykonkurencyjnych ze strony Google, a MTA-STS również się w to wpisuje.

@Avamander @HSVSphere WebPKI zależy od bezpieczeństwa DNS. WebPKI ufa rejestratorowi domen, TLD i IANA. WebPKI nie unika DNS jako źródła zaufania, ponieważ opiera się na weryfikacji domeny sprawdzającej kontrolę DNS. TLD może wskazywać na inny DNS i uzyskiwać certyfikaty dla twojej domeny.

@Avamander @HSVSphere WebPKI zależy od bezpieczeństwa DNS. WebPKI ufa rejestratorowi domen, TLD i IANA. WebPKI nie unika DNS jako źródła zaufania, ponieważ opiera się na weryfikacji domeny sprawdzającej kontrolę DNS. TLD może wskazywać na inny DNS i uzyskiwać certyfikaty dla twojej domeny.

@Avamander @HSVSphere WebPKI zasadniczo zależy od bezpieczeństwa DNS. MTA-STS jest zasadniczo niebezpieczny i nie jest niczym innym jak słabym rozwiązaniem tymczasowym. E-mail zasadniczo zależy od bezpieczeństwa DNS z wielu powodów, a WebPKI również zależy od bezpieczeństwa DNS. Nie zamierzamy dać się nabrać na te kłamstwa, przepraszam.

@Avamander @HSVSphere WebPKI zasadniczo zależy od bezpieczeństwa DNS. MTA-STS jest zasadniczo niebezpieczny i nie jest niczym innym jak słabym rozwiązaniem tymczasowym. E-mail zasadniczo zależy od bezpieczeństwa DNS z wielu powodów, a WebPKI również zależy od bezpieczeństwa DNS. Nie zamierzamy dać się nabrać na te kłamstwa, przepraszam.

@1ngenious @TorontoIX Obecnie mamy 5 dedykowanych serwerów do aktualizacji. Nasze serwery aktualizacyjne działają również jako podzbiór naszych 11 lokalizacji dla naszych usług internetowych/sieciowych, które mają również 6 instancji VPS, aby zapewnić szerszy zasięg na całym świecie. Używamy serwera w Toronto do e-maili i autorytatywnego DNS.

@1ngenious @TorontoIX to kontener systemowy na . to kolejny kontener systemowy, który zapewnia 1 z 9 lokalizacji dla naszej sieci anycast ns2. Pozostałe 8 to instancje VPS. Nasze ns1 to 11 instancji VPS Vultr.