József Kadlecsik: DKIM/DMARC v teorii a praxi
Když používáme e-mail, musíme vlastně používat dva úplně oddělené protokoly: SMTP pro odesílání a IMAP pro příjem pošty. Když odesíláte poštu, doručíte ji na svůj server a ten ji pak potřebuje předat vzdálenému serveru právě pomocí SMTP.
SMTP je velmi starý protokol, který byl v průběhu let mnohokrát rozšířen, ale pořád jde o velmi konzervativní. Po přijetí už nesmí být mail ztracen beze stopy. Server je zodpovědný za to, že bude pošta doručena.
Pokud něco selže, uživatel se musí o problému dozvědět nebo musí existovat alespoň záznam v logu.
Veškerá komunikace probíhá v otevřené podobě. Existuje sice možnost šifrování, ale ta je nepovinná a v případě problémů servery přejdou zpět k nešifrovanému přenosu. Můžu trvat na tom, že TLS 1.0 je starý prolomený protokol a pak ho můžu vypnout. Povede to ale jen k tomu, že budu více pošty posílat nešifrovaně.
Protokol umožňuje uživatelům přeposílat si maily z jednoho serveru na druhý. Při přeposílání pošty mezi přijímacími servery se musí přepisovat hlavička odesílatele na původní, jinak dojde k zacyklení. Přeposílající server tedy má možnost přepsat hlavičky. Tato vlastnost je pevnou součástí samotného protokolu, proto je tak těžké bojovat se spamy. Kdokoliv může posílat poštu za kohokoliv.
Snažíme se proto chránit uživatele před spamy a podvodnými maily pomocí různých protokolů. DKIM umožňuje přidat elektronický podpis vytvořený pomocí páru RSA klíčů, přičemž veřejný klíč určený k ověření je uložen v DNS záznamu typu TXT. Pokud ale cizí server dostane poštu z naší doménou bez podpisu v hlavičce, jak zjistí, že jsme měli použít DKIM?
K tomu slouží DMARC, který umožňuje zveřejnit politiku našeho serveru. Můžeme tak oznámit světu, že používáme DKIM.
Příjemce se pak opět pomocí TXT záznamu dozví, co má udělat s poštou, která nemá platný podpis. Může být přijata, vložena do karantény nebo zcela odmítnuta, pokud jsme si jisti, že pošta z daného adresního prostoru od nás nikdy neodchází nepodepsaná.
I tento systém má v praxi své problémy. Stále je například možné si libovolně vymyslet jméno uváděné před samotnou e-mailovou adresou a problémy nastávají typicky také v e-mailových konferencích, které z principu upravují přeposílanou poštu. Má to řešení, pokud server s DKIM počítá.
Adresa konference se použije v položce From, původní pak jde do Reply-To a server vytvoří nový podpis DKIM.
DKIM a DMARC jsou velmi dobré věci a měli byste je nasadit na svých serverech. Pokud outsourcujete poštovní servery, jděte za svým poskytovatelem a chtějte po něm nasadit DKIM a DMARC.
Dnes je to prakticky povinné, už jen proto, že GMail to u většiny domén vyžaduje.
Fredrik Korsbäck: síťová infrastruktura v AWS
AWS dříve nakupovala velký drahý síťový hardware v obrovských šasi. Byli jsme běžnými zákazníky a využívali jsme hardware na maximum. Někdy nám nestačil a museli jsme obcházet jeho omezení.
Dnes už se ve velkých sítích nic podobného nepoužívá, staví se vlastní řešení z malých jednoduchých síťových prvků.
Bylo potřeba začít přemýšlet o jednotlivých komponentách, místo o velkých uzavřených krabicích. S dodavateli se bavíme o komponentách: ASIC, správa, telemetrie, routovací protokol a SDK. Mezi tím vším je dnes linuxové jádro.
Jednotlivé oddělené komponenty dávají svobodu rozhodnout se o tom, co v síti skutečně potřebujete a které komponenty jsou pro vás zbytečné. Síť může dělat čím dál méně věcí, takže může být jednodušší a levnější.
Jednotlivé služby v AWS jsou velmi rozdílné a nejsou dnes omezovány unifikovaným způsobem stavby sítě. Už zhruba 80 % datacenter AWS bylo migrováno na tento nový typ sítě.
AWS dnes ve velkém využívá vlastních routerů 102.8T, který nabízí 32 portů 400G a je možné je skládat do raku až po 1024 portech. Pro externí konzumenty je dostupných 256 z nich, zbytek míří do naší sítě.
Směrem ven pak jde všechno od peeringu, přes transit, CDN, backbone a další. Takový rack ale potřebuje zhruba 30 kW energie, což není málo. Proto je možné rozdělit rack do čtyř menších, které je pak možné snadněji energeticky obsloužit.
Největším problémem takového řešení je množství kabelů, které do racku přicházejí. Je to velký problém, protože to komplikuje zprávu a obrovské množství kabelů zhoršuje průtok vzduchu.
Kvůli množství kabelů je potřeba každý pátý rack vyhradit čistě na kabeláž, protože jde o tisíce samostatných kabelů.
Když dnes někdo peeruje s AWS, nenavazuje spojení přímo se síťovým prvkem, ale s jednoúčelovým kontejnerem běžícím v cloudu v některém z datacenter. Používáme celou flotilu route reflektorů, které pro nás dělají různé věci.
Většinu provozu se pak daří odbavit zhruba s 20 000 prefixy. Celá tabulka má stovky tisíc prefixů, ale většinu z nich nikdy nepoužijeme.
Arnold Nipper: novinky v PeeringDB
PeeringDB je otevřená databáze sítí a poskytovatelů, kterou spravují samotní uživatelé. Jsme dobrovolnická organizace, která je stoprocentně financována ze sponzorských darů.
Denně přijde asi 30 třicet požadavků, v průměru jsou vyřízeny během několika hodin.
Mezi nedávné novinky patří lepší viditelnost peerinu na route serverech, automatický sběr dat z různých zdrojů a jejich vzájemné porovnávání, nové klíče pro API a limity na neautentizované dotazy. Přibyly také další informace o jednotlivých členech, včetně například možnosti napájení v datacentrech.
Vylepšeno bylo také vyhledávání v databázi, které by mělo vracet relevantnější výsledky. Začali jsme používat také geolokaci, takže je možné například vyhledat určitým způsobem vybavené datacentrum ve vybraném okolí.
Nina Bargisen: embedded CDN v roce 2023
CDN je vždy tvořena geograficky distribuovanými servery, které drží obsah a mohou ho posílat nejbližším uživatelům. Embedded CDN má servery uvnitř sítí poskytovatelů a jejich smyslem je obsluhovat tyto uživatele právě jen jednoho poskytovatele. Tyto CDN se začaly rozšiřovat s tím, jak přibývalo objemného obsahu.
Jde zejména o různé OTT služby, video či herní platformy.
Provozovatelé různých embedded CDN dělají věci různými způsoby, používají různé přístupy a přidání uzlu do vlastní sítě může být velmi komplikované. Štve mě to, proto vždycky vyzývám provozovatele sítí, aby spolu mluvili a spolupracovali.
Takové služby poskytují různé společnosti jako Akamai, Netflix, Google, Amazon, Facebook, Cloudflare a jiní. Další určitě přijdou, velcí tvůrci obsahu používají obvykle několik různých CDN najednou.
Podle dostupných statistik dnes 3500 různých ASN používá embedded CDN. Nejčastěji je tvoří servery společnosti Google, Netflix, Facebook a Akamai.
Existují čtyři způsoby, jak uživatele navigovat k nejbližšímu zdroji dat v CDN. První variantou je anycast, kdy provozovatel oznamuje své rozsahy z různých AS. Druhou variantou je využít mapování pomocí DNS. Třetí možností je pak použití BGP a signalizace různých cest různým sítím. Obvykle je jako primární klíč využívána geolokace jednotlivých uživatelů, kteří jsou pak podle ní směřování k nejbližším serverům.
Nerozhoduje se ale jen podle geolokace, ale také podle dalších parametrů. Tady přichází na řadu magie.
Provozovatel CDN má vytvořené komplikované mapování jednotlivých poskytovatelů a jejich zpoždění k jednotlivým uzlům. Část rozhodování tvoří také zatížení jednotlivých serverů nebo také dostupnost obsahu. Na všech serverech totiž nemusí být všechen obsah.
Pokud se rozhodujete přidat do své sítě uzel nějaké CDN, musíte zvážit několik věcí. Jednak je potřeba zjistit, zda vaši uživatelé intenzivně daný zdroj využívají a má to pro vás smysl. Musíte také zajistit, že vaše síť bude s technologií dané CDN kompatibilní a přinese vám to kýžené výhody.
Z hlediska hardware je to poměrně snadné, budete potřebovat jednu až dvě pozice v racku a síťové rozhraní o rychlosti 10, 50 či 100 GE. Technologie se zlepšují, úložiště zrychlují a čím dál menší servery jsou schopny generovat větší a větší provoz.
Martin Barry: peering s CDN Fastly
Fastly je CDN, která je přítomna v 97 datacentrech a má celkovou teoretickou kapacitu 252 terabitů za sekundu. Za posledních pět let se tohle číslo zvýšilo desetkrát.
Zákazníky jsou provozovatelé streamovacích služeb, různé videotéky a další podobné sítě náročné na datové přenosy.
Proč musí taková CDN peerovat s ostatními sítěmi? Dosáhne tím jednak nižšího zpoždění, ale také vyšší propustnosti a v neposlední řadě také zajistí redundanci tras. Umožňuje nám to také snížit náklady za konektivitu.
Fastly nenabízí nasazení svých keší do jednotlivých sítí, snaží se naopak stavět menší množství velmi výkonných uzlů. Provoz je mezi uživatele rozdělován jednak pomocí anycastu, ale také pomocí DNS. Ve výchozím stavu dostáváte obsah z nejbližšího uzlu, ale mohou také existovat důvody, kdy potřebujeme provoz přesměrovat jinam. Proto do něj pak můžeme zasáhnout.
Typicky je to proto, že na nejbližším uzlu není daný obsah k dispozici. Buď to neumožňují místní zákony nebo zákazník omezil doručování z daného regionu. Fastly také neprovozuje vlastní páteřní síť, takže musíte mít dostupné prefixy daného uzlu, jinak k vám i přes peering potečou data veřejným internetem.
(Autorem fotografií je Jaromír Novák, NIX.CZ.)
ČLÁNKY DO MAILU