Onze e-mailserver () is gemigreerd naar onze bare metal server gesponsord door Xenyth in Toronto. We gebruiken nu schone IP-ruimte die via BGP met onze AS is aangekondigd om de e-mailbezorgbaarheid te verbeteren door geen IP/AS-buren te hebben die spam verzenden.

@bkong_a Bijvoorbeeld, onze server in Toronto heeft Xenyth als onze directe provider. Xenyth routeert via hun infrastructuur naar hun upstreams (Arelion, GTT, Zayo en ook IPv6-only Hurricane Electric) en peers (op de Onix en TorIX exchanges samen met private peers zoals Google).

@bkong_a We hebben ons eigen AS (Autonomous System) voor het implementeren van onze eigen netwerken en routering. We gebruiken het om onze IP-ruimte aan onze providers aan te kondigen en te controleren hoe de aankondigingen door hun upstreams worden gebruikt. Voor onze anycast DNS-netwerken moeten we uitgebreide traffic engineering doen.

@bkong_a Voor anycast DNS hebben we 11 locaties voor ns1 en 9 locaties voor ns2. Hier is een voorbeeld van hoe traffic engineering werkt vanuit onze ns1 Vultr Frankfurt locatie: We controleren welke upstreams/peers onze routes van Vultr ontvangen en stemmen de upstream routing af.

@bkong_a We hebben momenteel geen servers die rechtstreeks meerdere aparte upstreams hebben. Dat betekent dat we nog geen gebruiksgeval hebben voor het importeren van de routes van onze upstreams en het afstemmen van waar we routeren op basis van BGP-routing. We zijn echter van plan dit te doen voor een aankomende server.

@bkong_a Op dit moment exporteren we alleen onze routes naar onze enkele directe upstream vanaf elke server waar we BGP gebruiken. Voor de anycast DNS-instanties kondigen we een IPv4 /24 en een IPv6 /48 aan voor productiegebruik, samen met een andere IPv6 /48 voor experimenten met verkeersengineering.

@bkong_a Anycast betekent dat hetzelfde IP-blok op meerdere locaties wordt aangekondigd, zodat providers op basis van gedistribueerde consensus routeringsbeslissingen zullen beslissen. Over het algemeen hebben kortere routes de voorkeur en routes waarvoor ze betaald worden (transitklanten) hebben de voorkeur boven routes waarvoor dat niet het geval is.

@bkong_a Voor onze locatie in Toronto kondigen we ook een unicast IPv4 /24 en IPv6 /48 aan. IPv4 /24 en IPv6 /48 blokken zijn de kleinste ondersteunde eenheden voor routering over het openbare internet, daarom worden deze gebruikt. Kleinere blokken kunnen ook binnen Xenyth of ons eigen netwerk worden gebruikt.

@bkong_a Onze Xenyth-server doet een beetje eigen routing omdat hij 2 containers heeft: één die een ns2 anycast DNS-instantie biedt en een andere die onze mailserver biedt. We hebben die routing statisch geconfigureerd, maar het zou technisch mogelijk zijn om BGP ervoor te gebruiken.

@Avamander @HSVSphere Stalwart bestond niet toen we onze eigen e-mail begonnen te hosten. Het was niet beschikbaar als optie, en het heeft even geduurd voordat het completer en volwassener werd. Het ziet er interessant uit, maar we hebben een productie-e-mailserver en kunnen deze niet eenvoudig vervangen of een nieuwe implementatie uitproberen.

@Avamander @HSVSphere Er zijn middleboxes met compatibiliteitsproblemen met DNSSEC en de adoptie is slecht buiten de meeste grote DNS-resolverservers en zelfstandige DNS-providers die het implementeren. Hetzelfde geldt voor veel dingen zoals QUIC en WebRTC. DNSSEC werkt in de praktijk prima en is zeer waardevol.

@Avamander @HSVSphere Specifieke browsers handhaven beleid voor Certificaattransparantie. Buiten het gebruik van browsers, inclusief voor MTA-STS met e-mailservers, worden die vereisten in de praktijk niet gehandhaafd. Het wordt vaak niet gevolgd. WebPKI wordt ook gebruikt voor native apps, tussen servers, enz. niet alleen voor browsers.

@Avamander @HSVSphere Er zijn andere manieren om het te doen naast BGP. Het is geen bijzonder veilig systeem. Non-browser WebPKI handhaaft geen CT en is een groot deel van het TLS-verkeer. Bijna niemand monitort CT voor hun diensten, dus het biedt niet wat het wordt voorgesteld te bieden voor niet-Google organisaties.

@Avamander @HSVSphere Google heeft zowel dynamische als statische certificaatpinnen voor niet-Google verwijderd. Ze beweerden dat ze ermee gestopt waren, maar bleven het gebruiken. Het is een schending van de mededingingswet. Het maakt deel uit van een enorme hoeveelheid oneerlijke anticompetitieve gedragingen van Google en MTA-STS maakt daar ook deel van uit.

@Avamander @HSVSphere WebPKI is afhankelijk van DNS-beveiliging. WebPKI vertrouwt de domeinregistrar, TLD en IANA. WebPKI vermijdt niet dat DNS een root of trust is, omdat het gebaseerd is op Domain Validation die de DNS-controle controleert. TLD kan je DNS ergens anders naartoe wijzen en certificaten voor je domein verkrijgen.

@Avamander @HSVSphere WebPKI is afhankelijk van DNS-beveiliging. WebPKI vertrouwt de domeinregistrar, TLD en IANA. WebPKI vermijdt niet dat DNS een root of trust is, omdat het gebaseerd is op Domain Validation die de DNS-controle controleert. TLD kan je DNS ergens anders naartoe wijzen en certificaten voor je domein verkrijgen.

@Avamander @HSVSphere WebPKI is fundamenteel afhankelijk van DNS-beveiliging. MTA-STS is fundamenteel onveilig en niets meer dan een zwakke tijdelijke oplossing. E-mail is om meerdere redenen fundamenteel afhankelijk van DNS-beveiliging en WebPKI is ook afhankelijk van DNS-beveiliging. We gaan niet wegkomen met die leugens bij ons, sorry.

@Avamander @HSVSphere WebPKI is fundamenteel afhankelijk van DNS-beveiliging. MTA-STS is fundamenteel onveilig en niets meer dan een zwakke tijdelijke oplossing. E-mail is om meerdere redenen fundamenteel afhankelijk van DNS-beveiliging en WebPKI is ook afhankelijk van DNS-beveiliging. We gaan niet wegkomen met die leugens bij ons, sorry.

@1ngenious @TorontoIX We hebben momenteel 5 dedicated servers voor updates. Onze update servers fungeren ook als een subset van onze 11 locaties voor onze website/netwerkdiensten, die ook 6 VPS-instanties hebben om bredere wereldwijde dekking te bieden. We gebruiken de server in Toronto ook voor e-mail en autoritatieve DNS.

@1ngenious @TorontoIX is een systeemcontainer op . is een andere systeemcontainer die 1 van de 9 locaties biedt voor ons ns2 anycast-netwerk. De andere 8 zijn VPS-instanties. Onze ns1 bestaat uit 11 Vultr VPS-instanties.