Vår e-postserver () har migrerats till vår bare metal-server som sponsras av Xenyth i Toronto. Vi använder nu rent IP-utrymme som annonserats via BGP med vårt AS för att förbättra e-postleveransen genom att slippa IP/AS-grannar skicka skräppost.

@bkong_a Till exempel har vår Toronto-server Xenyth som vår direkta leverantör. Xenyth leder via sin infrastruktur till sina upstreams (Arelion, GTT, Zayo och även IPv6-exklusiva Hurricane Electric) och peers (på Onix- och TorIX-växlarna samt privata peers som Google).

@bkong_a Vi har vårt eget AS (Autonomous System) för att implementera våra egna nätverk och routing. Vi använder den för att annonsera vårt IP-utrymme till våra leverantörer och kontrollera hur meddelandena används av deras upstreams. För våra anycast DNS-nätverk behöver vi göra omfattande trafikutveckling.

@bkong_a För anycast DNS har vi 11 platser för ns1 och 9 platser för ns2. Här är ett exempel på hur trafikteknik fungerar från vår ns1 Vultr Frankfurt-plats: Vi kontrollerar vilka upstreams/peers som får våra rutter från Vultr och justerar upstream-rutten.

@bkong_a Vi har för närvarande inga servrar som direkt har flera separata uppströmskanaler. Det betyder att vi ännu inte har något användningsområde för att importera rutter från våra upstreams och justera var vi ruttar baserat på BGP-routing. Vi planerar dock att göra det för en kommande server.

@bkong_a Just nu exporterar vi bara våra rutter till vår enda direkta upstream från varje server där vi använder BGP. För anycast DNS-instanserna tillkännager vi en IPv4 /24 och en IPv6 /48 för produktionsbruk tillsammans med en annan IPv6 /48 för trafikingenjörsexperiment.

@bkong_a Anycast innebär att samma IP-block annonseras på flera platser, så leverantörerna kommer att avgöra baserat på distribuerade konsensusbeslut om routing. Generellt föredras kortare rutter och de linjer de får betalt för (kollektivtrafikkunder) föredras framför de de inte gör.

@bkong_a För vår plats i Toronto tillkännager vi också en unicast IPv4/24 och IPv6/48. IPv4 /24 och IPv6 /48-block är de minsta stödda enheterna för routing över det publika internet, därför används de. Mindre block kan också användas inom Xenyth eller vårt eget nätverk.

@bkong_a Vår Xenyth-server gör lite av själva routing eftersom den har två containrar: en som tillhandahåller en ns2 anycast DNS-instans och en annan som tillhandahåller vår e-postserver. Vi har bara den routningen statiskt konfigurerad men det skulle tekniskt sett vara möjligt att använda BGP för det.

@Avamander @HSVSphere Stalwart fanns inte när vi började hosta vår egen e-post. Det fanns inte som ett alternativ, och det tog ett tag innan det började bli mer komplett och moget. Det ser intressant ut men vi har en produktionsmailserver och kan inte enkelt byta ut den eller prova en ny implementation.

@Avamander @HSVSphere Det finns mellanboxar med DNSSEC-kompatibilitetsproblem och det har dålig användning utöver de flesta stora DNS-resolverservrar och fristående DNS-leverantörer som implementerar det. Samma sak gäller för många saker som QUIC och WebRTC. DNSSEC fungerar bra i praktiken och är mycket värdefullt.

@Avamander @HSVSphere Specifika webbläsare upprätthåller policyer för certifikattransparens. Utöver webbläsaranvändning, inklusive för MTA-STS med e-postservrar, upprätthålls inte dessa krav i praktiken. Den följs ofta inte. WebPKI används också för inbyggda appar, mellan servrar, etc., inte bara webbläsare.

@Avamander @HSVSphere Det finns andra sätt att göra det på utöver BGP. Det är inte ett särskilt säkert system. WebPKI som inte är webbläsare upprätthåller inte CT och utgör en stor del av TLS-trafiken. Nästan ingen övervakar CT för sina tjänster, så de levererar inte det de framställs som för organisationer utanför Google.

@Avamander @HSVSphere Google tog bort både dynamisk och statisk certifikatpinning för icke-Google. De påstod att de slutat använda det men fortsatte använda det. Det är ett konkurrensrättsligt brott. Det är en del av en enorm mängd oärligt konkurrensbegränsande beteende från Google och MTA-STS är också en del av det.

@Avamander @HSVSphere WebPKI är beroende av DNS-säkerhet. WebPKI litar på domänregistret, TLD och IANA. WebPKI undviker inte att DNS är en rot av förtroende eftersom det baseras på domänvalidering som kontrollerar DNS-kontroll. TLD kan peka din DNS någon annanstans och få certifikat för din domän.

@Avamander @HSVSphere WebPKI är beroende av DNS-säkerhet. WebPKI litar på domänregistret, TLD och IANA. WebPKI undviker inte att DNS är en rot av förtroende eftersom det baseras på domänvalidering som kontrollerar DNS-kontroll. TLD kan peka din DNS någon annanstans och få certifikat för din domän.

@Avamander @HSVSphere WebPKI beror i grunden på DNS-säkerhet. MTA-STS är i grunden osäkert och inget annat än en svag tillfällig lösning. E-post är i grunden beroende av DNS-säkerhet av flera skäl och WebPKI är också beroende av DNS-säkerhet. Jag kommer inte undan med de lögnerna med oss, tyvärr.

@Avamander @HSVSphere WebPKI beror i grunden på DNS-säkerhet. MTA-STS är i grunden osäkert och inget annat än en svag tillfällig lösning. E-post är i grunden beroende av DNS-säkerhet av flera skäl och WebPKI är också beroende av DNS-säkerhet. Jag kommer inte undan med de lögnerna med oss, tyvärr.

@1ngenious @TorontoIX Vi har för närvarande 5 dedikerade servrar för uppdateringar. Våra uppdateringsservrar fungerar också som en delmängd av våra 11 platser för våra webbplats-/nätverkstjänster, som också har 6 VPS-instanser för att ge bredare global täckning. Vi använder servern i Toronto för e-post och auktoritativ DNS också.

@1ngenious @TorontoIX är en systemcontainer på . är en annan systemcontainer som tillhandahåller en av de nio platserna för vårt NS2 Anycast-nätverk. De andra 8 är VPS-instanser. Vår ns1 är 11 Vultr VPS-instanser.