Наш поштовий сервер () було перенесено на наш «голий метал» сервер, який спонсорує Xenyth у Торонто. Зараз ми використовуємо чистий IP-простір, оголошений через BGP разом із нашим AS, щоб покращити доставку електронної пошти, не допускаючи IP/AS сусідів, які надсилають спам.

@bkong_a Наприклад, наш сервер у Торонто має Xenyth як прямого провайдера. Xenyth маршрутизує через їхню інфраструктуру до їхніх верхніх каналів (Arelion, GTT, Zayo, а також Hurricane Electric, що підтримує лише IPv6) та однолітків (на біржах Onix і TorIX разом із приватними пірами, такими як Google).

@bkong_a У нас є власна автономна система (AS) для реалізації власних мереж і маршрутизації. Ми використовуємо його, щоб анонсувати наш IP-простір нашим провайдерам і контролювати, як ці оголошення використовують їхні upstream-провайдери. Для наших DNS-мереж anycast нам потрібно провести масштабну інженерію трафіку.

@bkong_a Для anycast DNS у нас є 11 локацій для ns1 і 9 локацій для ns2. Ось приклад того, як працює інженерія трафіку з нашого ns1 Vultr у Франкфурті: Ми контролюємо, які upstream/peers отримують наші маршрути від Vultr і налаштовуємо маршрутизацію upstream.

@bkong_a Наразі у нас немає серверів, які безпосередньо мають кілька окремих upstream-каналів. Це означає, що ми поки не маємо можливості імпортувати маршрути з наших апстрімів і налаштовувати маршрути на основі маршрутизації BGP. Ми плануємо зробити це для одного майбутнього сервера.

@bkong_a Наразі ми просто експортуємо наші маршрути на наш єдиний прямий upstream з кожного сервера, де використовуємо BGP. Для DNS-екземплярів anycast ми оголошуємо IPv4 /24 та IPv6 /48 для виробничого використання, а також ще один IPv6 /48 для експериментів з інженерією трафіку.

@bkong_a Anycast означає, що один і той самий IP-блок оголошується в кількох локаціях, тому провайдери прийматимуть рішення на основі розподіленого консенсусу маршрутизації. Загалом, коротші маршрути віддають перевагу, а маршрути, за які вони отримують оплату (транзитні клієнти), віддають перевагу над тими, за які вони не отримують.

@bkong_a Для нашого офісу в Торонто ми також анонсуємо унікастове IPv4 /24 та IPv6 /48. Блоки IPv4 /24 і IPv6 /48 — це найменші підтримувані пристрої для маршрутизації через публічний інтернет, тому саме їх і використовують. Менші блоки можна використовувати як у Xenyth, так і в нашій власній мережі.

@bkong_a Наш сервер Xenyth трохи виконує власну маршрутизацію, оскільки на ньому є два контейнери: один надає ns2 anycast DNS, інший — наш поштовий сервер. Ми просто налаштували цю маршрутизацію статично, але технічно можливо використовувати BGP для цього.

@Avamander @HSVSphere Stalwart не існувало, коли ми почали розміщувати власну електронну пошту. Вона не була доступна як опція, і знадобився час, щоб вона стала більш повною та зрілою. Виглядає цікаво, але у нас є продакшн-поштовий сервер, і ми не можемо легко його замінити або спробувати нову реалізацію.

@Avamander @HSVSphere Існують середні бокси з проблемами сумісності з DNSSEC, і вони мають слабке впровадження, окрім більшості основних серверів DNS-резолверів та автономних DNS-провайдерів, які його реалізують. Те саме стосується багатьох інших, таких як QUIC і WebRTC. DNSSEC працює добре на практиці і дуже цінний.

@Avamander @HSVSphere Певні браузери забезпечують дотримання політик прозорості сертифікатів. Окрім використання браузером, зокрема для MTA-STS з поштовими серверами, ці вимоги на практиці не виконуються. Часто її не дотримуються. WebPKI також використовується для нативних додатків, між серверами тощо, а не лише для браузерів.

@Avamander @HSVSphere Є й інші способи зробити це, окрім BGP. Це не надто безпечна система. WebPKI, що не є браузером, не забезпечує CT і становить значну частину трафіку TLS. Майже ніхто не контролює CT для своїх послуг, тому він не надає того, що подається для організацій, не пов'язаних із Google.

@Avamander @HSVSphere Google припинила як динамічне, так і статичне закріплення сертифікатів для не-Google. Вони стверджували, що перестали ним користуватися, але продовжували користуватися. Це порушення антимонопольного законодавства. Це частина величезної кількості нечесної антиконкурентної поведінки з боку Google, і MTA-STS також є частиною цього.

@Avamander @HSVSphere WebPKI залежить від DNS-безпеки. WebPKI довіряє доменному реєстру, TLD та IANA. WebPKI не уникає використання DNS як кореня довіри, оскільки базується на контролі DNS перевірки домену. TLD може направити ваш DNS в інше місце і отримати сертифікати для домену.

@Avamander @HSVSphere WebPKI залежить від DNS-безпеки. WebPKI довіряє доменному реєстру, TLD та IANA. WebPKI не уникає використання DNS як кореня довіри, оскільки базується на контролі DNS перевірки домену. TLD може направити ваш DNS в інше місце і отримати сертифікати для домену.

@Avamander @HSVSphere WebPKI фундаментально залежить від безпеки DNS. MTA-STS фундаментально невпевнений і є лише слабким тимчасовим підходом. Електронна пошта фундаментально залежить від DNS-безпеки з багатьох причин, а WebPKI також залежить від DNS-безпеки. Вибачте, ці брехні нам не зійдуть з рук.

@Avamander @HSVSphere WebPKI фундаментально залежить від безпеки DNS. MTA-STS фундаментально невпевнений і є лише слабким тимчасовим підходом. Електронна пошта фундаментально залежить від DNS-безпеки з багатьох причин, а WebPKI також залежить від DNS-безпеки. Вибачте, ці брехні нам не зійдуть з рук.

@1ngenious @TorontoIX Наразі у нас є 5 виділених серверів для оновлень. Наші сервери оновлень також є підмножиною з 11 локацій для наших вебсайтів/мережевих сервісів, які також мають 6 VPS-екземплярів для ширшого глобального покриття. Ми також використовуємо сервер у Торонто для електронної пошти та авторитетного DNS.

@1ngenious @TorontoIX — це системний контейнер на . Це ще один системний контейнер, що забезпечує 1 з 9 локацій для нашої мережі NS2 Anycast. Інші 8 — це VPS-інстанси. Наш ns1 — це 11 екземплярів Vultr VPS.