Vår e-postserver () har blitt migrert til vår bare metal-server sponset av Xenyth i Toronto. Vi bruker nå ren IP-plass annonsert via BGP med vår AS for å forbedre e-postleveransen ved å unngå at IP/AS-naboer sender spam.

@bkong_a For eksempel har vår Toronto-server Xenyth som vår direkte leverandør. Xenyth ruter gjennom infrastrukturen sin til sine upstreams (Arelion, GTT, Zayo og også IPv6-only Hurricane Electric) og peers (på Onix- og TorIX-børsene sammen med private peers som Google).

@bkong_a Vi har vårt eget AS (Autonomous System) for å implementere våre egne nettverk og ruting. Vi bruker det til å annonsere IP-området vårt til våre leverandører og kontrollere hvordan kunngjøringene brukes av deres upstreams. For våre anycast DNS-nettverk må vi gjøre omfattende trafikkutvikling.

@bkong_a For anycast DNS har vi 11 lokasjoner for ns1 og 9 lokasjoner for ns2. Her er et eksempel på hvordan trafikkteknikk fungerer fra vår ns1 Vultr Frankfurt-lokasjon: Vi kontrollerer hvilke upstreams/jevnaldrende som mottar rutene våre fra Vultr og justerer upstream-rutingen.

@bkong_a Vi har for øyeblikket ingen servere som direkte har flere separate upstreams. Det betyr at vi ennå ikke har et bruksområde for å importere rutene fra våre upstreams og justere hvor vi ruter basert på BGP-ruting. Vi planlegger å gjøre det for en kommende server.

@bkong_a Akkurat nå eksporterer vi bare rutene våre til vår enkeltstående direkte oppstrøms fra hver server hvor vi bruker BGP. For anycast DNS-instansene annonserer vi en IPv4 /24 og en IPv6 /48 for produksjonsbruk, sammen med en annen IPv6 /48 for trafikkingeniør-eksperimentering.

@bkong_a Anycast betyr at den samme IP-blokken annonseres på flere steder, så leverandørene vil avgjøre basert på distribuerte konsensus-rutingbeslutninger. Generelt foretrekkes kortere ruter, og ruter de får betalt for å bruke (kollektivkunder) foretrekkes fremfor de de ikke gjør.

@bkong_a For vår lokasjon i Toronto annonserer vi også unicast IPv4 /24 og IPv6 /48. IPv4 /24 og IPv6 /48-blokker er de minste støttede enhetene for ruting over det offentlige internett, og derfor brukes disse. Mindre blokker kan også brukes innenfor Xenyth eller vårt eget nettverk.

@bkong_a Vår Xenyth-server gjør litt av selve rutingen selv fordi den har to containere: en som gir en ns2 anycast DNS-instans og en annen som tilbyr vår e-postserver. Vi har bare den rutingen statisk konfigurert, men det ville teknisk sett være mulig å bruke BGP til det.

@Avamander @HSVSphere Stalwart eksisterte ikke da vi begynte å hoste vår egen e-post. Det var ikke tilgjengelig som et alternativ, og det tok en stund før det begynte å bli mer komplett og modent. Det ser interessant ut, men vi har en produksjonspostserver og kan ikke enkelt bytte den ut eller prøve en ny implementering.

@Avamander @HSVSphere Det finnes mellombokser med DNSSEC-kompatibilitetsproblemer, og det har dårlig utbredelse utover de fleste store DNS-resolverservere og frittstående DNS-leverandører som implementerer det. Det samme gjelder mange ting som QUIC og WebRTC. DNSSEC fungerer fint i praksis og er veldig verdifullt.

@Avamander @HSVSphere Spesifikke nettlesere håndhever retningslinjer for Certificate Transparency. Utenom nettleserbruk, inkludert for MTA-STS med e-postservere, håndheves ikke disse kravene i praksis. Det blir ofte ikke fulgt. WebPKI brukes også for native apper, mellom servere osv., ikke bare nettlesere.

@Avamander @HSVSphere Det finnes andre måter å gjøre det på enn BGP. Det er ikke et spesielt sikkert system. Ikke-nettleser WebPKI håndhever ikke CT og utgjør en stor del av TLS-trafikken. Nesten ingen overvåker CT for tjenestene sine, så de leverer ikke det de blir fremstilt som for ikke-Google-organisasjoner.

@Avamander @HSVSphere fjernet Google både dynamisk og statisk sertifikatpinning for ikke-Google. De hevdet at de hadde sluttet å bruke det, men fortsatte å bruke det. Det er et brudd på konkurranseloven. Det er en del av en enorm mengde uærlig konkurransehemmende atferd fra Google, og MTA-STS er også en del av det.

@Avamander @HSVSphere WebPKI er avhengig av DNS-sikkerhet. WebPKI stoler på domeneregisteret, TLD og IANA. WebPKI unngår ikke at DNS er en root of trust fordi det er basert på domenevalidering som sjekker DNS-kontroll. TLD kan peke DNS-en din et annet sted og hente sertifikater for domenet ditt.

@Avamander @HSVSphere WebPKI er avhengig av DNS-sikkerhet. WebPKI stoler på domeneregisteret, TLD og IANA. WebPKI unngår ikke at DNS er en root of trust fordi det er basert på domenevalidering som sjekker DNS-kontroll. TLD kan peke DNS-en din et annet sted og hente sertifikater for domenet ditt.

@Avamander @HSVSphere WebPKI avhenger grunnleggende av DNS-sikkerhet. MTA-STS er grunnleggende usikkert og bare en svak midlertidig løsning. E-post er fundamentalt avhengig av DNS-sikkerhet av flere grunner, og WebPKI er også avhengig av DNS-sikkerhet. Vi kommer ikke unna med de løgnene med oss, beklager.

@Avamander @HSVSphere WebPKI avhenger grunnleggende av DNS-sikkerhet. MTA-STS er grunnleggende usikkert og bare en svak midlertidig løsning. E-post er fundamentalt avhengig av DNS-sikkerhet av flere grunner, og WebPKI er også avhengig av DNS-sikkerhet. Vi kommer ikke unna med de løgnene med oss, beklager.

@1ngenious @TorontoIX Vi har for øyeblikket 5 dedikerte servere for oppdateringer. Våre oppdateringsservere fungerer også som en delmengde av våre 11 lokasjoner for våre nettside-/nettverkstjenester, som også har 6 VPS-instanser for å gi bredere global dekning. Vi bruker serveren i Toronto også til e-post og autoritativ DNS.

@1ngenious @TorontoIX er en systembeholder på . er en annen systemcontainer som gir én av de 9 lokasjonene for vårt NS2 Anycast-nettverk. De andre 8 er VPS-instanser. Vår ns1 er 11 Vultr VPS-instanser.