Ondřej Filip: Konec IPv4: tak už došly?
Ondřej Filip chtěl odpovědět na otázku, zda už došly IPv4 adresy. Problém s docházením je, že docházení bylo hodně. Nikdy pak nemůžete říct, kdy opravdu dojdou.
IP adresy už totiž došly několikrát a s různou intenzitou. V únoru 2011 byl alokován poslední blok z IANA, poté došlo k takzvanému spravedlivému dělení bloků. Každý z pěti regionů dostal jeden blok. Technologické úrovně těch regionů jsou ale úplně rozdílné.
V regionu jihovýchodní Asie například jeden blok příliš dlouho nevydržel. On tam jen tak zasyčel a bylo po něm. Rozvoj internetu je tam velmi rychlý.
Podobně to bylo v evropském RIPE NCC. Organizace začaly poslední blok krájet po malých kouscích a tím dramaticky snížily tempo, aby se dostalo na každého. Na druhou stranu, každý kdo přijde, dostane adres relativně málo.
Jinak se k situaci postavily LACNIC a ARIN, které reagovaly zpřísněním pravidel. Snažily se zjistit, jestli je to oprávněná alokace. Ani to příliš nepomohlo, protože v Severní Americe došly adresy v roce 2015.
V Evropě se alokovalo pomalu a jen členům, kteří ještě z posledního bloku nealokovali. To vedlo k jedinému: když už nemůžete jako člen získat další adresy, založíte si další entitu a stanete se členem znovu.
Lidé se zachovali racionálně, začali generovat nové členy a došlo k rychlému nárůstu. Poslední rozsah se začal alokovat velmi rychle.
Do roku 2012 byl nárůst počtu členů lineární a každý měsíc jich přibylo asi 65. Poté to nabralo úplně jinou rychlost, konec byl naprosto extrémní a přibývá jich 700 měsíčně. Jsou to umělí členové, kteří zase brzy zmizí, až nebude co rozebírat.
Poslední blok 185/8 byl vyčerpán už 17. dubna 2018. To ještě nebylo tak dramatické, RIPE dostal ještě další bloky od ukončených členů, takže bylo ještě stále co rozdávat.
Dále se tedy rozdávaly souvislé bloky /22 a ty byly vyčerpány 2. října 2019. Do této doby jste mohli dostat souvislý blok, což je z mnoha důvodů příjemné.
Bohužel po tomto datu už další členové sice dostali stále 1024 adres, ale ne v jednom bloku, ale ve dvou až čtyřech menších blocích. Blížíme se ovšem velmi rychle i k vyčerpání těchto drobků.
Nárůst nových LIR byl v poslední době velmi rychlý, čímž vznikla dlouhá fronta. RIPE stanovil rychlost přijímání nových žádostí na 700 měsíčně.
Čekací doba v poslední době se pohybuje mezi 8 a 9 týdny. Kdo nepožádal dříve, už své adresy nedostane. Pokud jste už požádali, je i tak velká šance, že žádné adresy nedostanete. Tohle je opravdu definitivní konec.
Komunita RIPE přišla s dvěma politikami přidělování dalších adres. První z nich říká, že pokud byly vyčerpány všechny bloky, je možné se zařadit do nové čekací listiny pro přidělení bloku /24. Ta je určena jen pro nové členy, pokud už jste nějaké adresy dostali, už se na novou listinu zařadit nemůžete.
RIPE také ještě drží blok /15 pro internetové uzly, který by měl vydržet 10 let. Do RIPE se vracejí i menší bloky /24, které už není možné oznamovat do internetu, takže se RIPE rozhodl je nevracet a nechat je také pro exchange pointy.
Odkud se vezmou další bloky /24, které se budou podle čekací listiny přidělovat později? IP adresy se pořád vracejí, členové zanikají, slučují se a podobně. Tyhle adresy se nedají hned použít, protože pocházejí obvykle z pochybných společností.
RIPE se je snaží vyřadit z BGP, poté z různých blacklistů spamu a poté adresy leží v karanténě šest měsíců. K dnešnímu dni je to 1300 bloků /24, jinými slovy máme díky nové politice adresy pro 1300 dalších členů.
Ročně se takto vrací 1500 až 2000 bloků, ty budou ale rozebrány vždy velmi rychle. Přibývá 700 členů měsíčně, ale předpokládám, že jich v budoucnu dramaticky ubude.
Ke získání IP adres je možné si založit peeringový uzel nebo pokračovat v původním modelu: založit si nový LIR, zaplatit poplatky na dva roky a počkat na přidělení adres. To vás vyjde přibližně na 19 eur za IP adresu na dva roky. Můžete to také zkusit v Africe, tam ještě nějaké IP adresy jsou. Předpoklad je, že tam máte nějakou přítomnost, ale s tím se dá pracovat.
Poslední možností je pak IP adresy nakoupit.
Existují aukční servery, na kterých je možné nabízet a nakupovat adresy. Cena postupně stoupá, cenová hladina je asi 20 dolarů za adresu a už se občas dostává na 25 dolarů.
To je stále ještě levnější a výrazně rychlejší než zaplatit za členství RIPE. Osobně si myslím, že cena poletí rychle nahoru, protože skončila legální možnost získat IP adresy.
Jakmile pořádně nastartuje protokol IPv6, půjde cena zase velmi rychle dolů.
IPv6 stále roste, navíc velmi dramaticky. Žádný protokol takhle rychle nerostl, ale bohužel to nestačí.
Podle dat společnosti Google je asi 30 % uživatelů připojeno po IPv6. Potřebovali bychom ale, aby to číslo bylo někde okolo 95 %.
Nejlépe jsou na tom v Evropě státy jako Belgie (52 %), Německo (44 %), Řecko (43 %) a Francie (37 %). Česko bývalo dříve také na špici, ale v posledních pěti letech se penetrace příliš nezvyšuje a držíme se dlouhodobě okolo 13 %. Prosím vás, dělejte s tím něco. Zkuste implementovat IPv6, zaostáváme za světem.
Regina Fuchsová: Na TLD scénu vstupuje .ευ
Ve čtvrtek 14. listopadu 2019 okolo 9. hodiny došlo ke klonování stávajících domén v řečtině pod novou koncovku. V 9:31 byla registrována první úplně nová doména.
EURid se tím zařadil mezi správce domén, kteří mají poměrně široké portfolio: spravuje koncovky ve třech různých jazycích. Dneškem se završil proces fast track, který trval osm let. ICAN v něm umožnil delegovat ekvivalent domény v IDN.
EURid v roce 2011 požádal o ekvivalent domény .eu v řečtině a cyrilici. Cyrilice nám byla delegována dřív.
V řečtině by Evropská unie měla zkratku EE, což by bylo ale lehce zaměnitelné s Estonskem. Mohlo by se ale jednat o první dvě písmena řeckého slova Evropa, což ale také není jednoznačné.
Je tu ale určitý generický potenciál, protože ve starořečtině přečtení obou písmen znamená „dobrý“. Asi to nebude trhák, ale někdo s oblibou ve starořečtině by tenhle význam mohl zaregistrovat.
Na začátku proběhlo klonování, tedy domény zapsané jako cyrilice.latinka byly klonovány. Domény pak žijí nezávisle a provozovatelé mají tři roky na převod, protože poté už bude platit, že písmo domény druhé úrovně musí odpovídat písmu domény první úrovně.
EURid spustil první IDN domény v prosinci roku 2009 a nástup byl velmi rychlý. Museli jsme zavést IDN, protože to tak po nás chtěla Evropská komise.
Jiné znakové sady než současná latinka, cyrilice a řečtina už se v Evropské unii nepoužívají.
V doména .eu používá IDN několik tisíc domén: 35 tisíc je jich v latince, 1600 v cyrilici a 2000 v řečtině. Řecko a Kypr dávají dohromady 12 milionů obyvatel, kteří tu znakovou sadu opravdu používají. Uživatele si to jistě najde.
V doméně .cz není IDN zavedeno, sdružení CZ.NIC pořádá od roku 2004 každé dva roky průzkumy, podle kterých si tři čtvrtiny organizací a zhruba polovina individuálních uživatelů zavedení diakritiky v doméně nepřeje. Se zavedením tohoto rozšíření se obvykle pojí obava o vznik nových problémů. Těm se podařilo předejít nebo se v naší praxi vůbec nepotvrdily.
Nedošlo například vůbec k nárůstu soudních sporů, problémy s typosquattingem byly vyřešeny pravidlem „no script mixing“, které zakazuje míchání různých znakových sad. Počet IDN ve světě roste, dnes je jich 9 milionů a tvoří 2,5 % všech domén.
Václav Steiner: Stěhování (nejen DNS) do privátního sálu
CZ.NIC používá tři datová centra: DC Tower a CE Colo v Praze a poté jedna mimopražská lokalita. Připravuje vlastní privátní sál, který mu umožní lepší rozvoj do budoucna, navýšení kapacity a chlazení a zvýšení fyzické bezpečnosti. Nikdo jiný kromě nás do sálu nepřijde, což nám umožňuje dělat věci efektivněji.
Běžný stav v datacentru znamená oddělení od ostatních zákazníků pomocí klece, zdvojená podlaha, sedm racků a orientační příkon 20 kW pro všechny servery. Celkem jde o 111 serverů pro různé služby, laboratoře, testovací prostředí a další.
O stěhování se začalo diskutovat v létě 2018, během listopadu byly k dispozici první podklady. V dubnu 2019 byla podepsaná smlouva a začaly stavební práce. Ty řeší datacentrum podle našich požadavků. Nerozumíme všemu, nemáme zkušenosti třeba s napájením, chlazením a podobně.
V půlce července došlo k předání sálu do užívání.
První fáze stěhování probíhá v listopadu 2019, druhá fáze proběhne v lednu 2020. Byla by škoda to udělat tak, jak to původně bylo a neudělat nic nově. Děláme s tím různé aktualizace: sítě, rozložení serverů a podobně.
Aby bylo možné zprovoznit nový rack, je potřeba také připravit infrastrukturu – například switche.
Pro chlazení se nepoužívá zdvojená podlaha, takže se používají dvě klimatizační jednotky CoolTop3. Ty jsou položeny na racků a foukají seshora dolů.
Větráky jsou předimenzované, takže nemusí běžet všechny najednou a běží vždy jen jedna strana. V případě výpadku pak nedojde k dramatickému nárůstu teploty. Kvůli ochraně před statickou elektřinou jsou v sále dva zvlhčovače, které udržují vlhkost na 20 %. Napájení je řešeno tradičně dvěma nezávislými větvemi.
Při stěhování se začalo síťovou infrastrukturou, která je rozdělena na optickou a metalickou část. Optiku máme níže, protože předpokládáme její další rozvoj a nechceme lézt zbytečně vysoko.
Fyzicky je oddělena také síť pro management, která je vedena přes samostatné starší switche. Doplněny byly i nové páteřní switche Juniper QFX 5200, které mají 100Gbit porty. Všechny servery jsou připojeny dvěma uplinky v ether-channelu. Cílem všech upgradů je navýšit všechna rozhraní na 10 Gbit vedený po optice.
Do konce listopadu bude přestěhována většina serverů, přibližně 85. V lednu pak bude dostěhován zbytek – asi 26 serverů. Tam je toho už méně a bude to asi rychlejší. Samozřejmě pak nás čeká odkabelování, úklid a předání původního sálu.
Samotné stěhování probíhá velmi rychle, u některých služeb je možné servery odstavit na delší dobu, ale část z nich není redundantní. Jeden server se nám daří průměrně přestěhovat za 10 minut. To ale předpokládá, že je připravená kabeláž a ví, do jakého místa ho chce dát.
Současně probíhal také upgrade firmware hardwarových komponent v serverech.
Překvapivě bylo snadné se dohodnout na přesunu serverů jiných organizací, které jsou u CZ.NIC hostované. Daleko složitější bylo se domluvit na propojích v datacentru, aby bylo všechno připravené.
Projekt Ludus: Nástroj pro pokročilou ochranu vašeho routeru
S představením projektu Ludus přišli studenti z FEL ČVUT, kteří spolupracují se sdružením CZ.NIC a Technologickou agenturou ČR. K obraně routerů využívají teorii her, která jim dovoluje nacházet optimální obranné strategie. Důležité je říct, že sledujeme jen provoz přicházející zvenčí, nikdy nás nezajímají toky uvnitř vaší sítě.
Ke sledování provozu se používají honeypoty, které už teď běží v routerech Turris a Omnia. Cílem je ale celou věc dostat na další úroveň a sledovat úspěšnost vytvořených strategií a hlídat úspěšnost celého řešení.
S nasazení honeypotů přichází několik problémů: kam je nasadit, jak je analyzovat a co si dál počít se získanými informacemi. Chceme vzít existující data a připravit pro uživatele hotové výstupy.
Uživatelé se také někdy bojí honeypoty nasazovat, protože se obávají, že tím přitáhnou více pozornosti. Námi naměřená data ukazují, že k mírnému nárůstu provozu dojde, ale ne k nijak výraznému.
Na začátku je celá situace namodelována jako hra, ve které se snažíme najít strategii, při které útočník získá co nejméně. Potřebujeme také šetřit zdroje routerů, které jsou sice poměrně výkonné, ale nemůžeme jim bránit v jejich běžné práci.
Cílem je odklonit provoz domnělého útočníka, který pak neví, který cíl je pravý a co je honeypot.
Zajímavé to začne být, když máme více zařízení, která mohou na hledání strategie spolupracovat. Našim cílem je připravit předem ideální strategie a pak je poslat do všech routerů najednou.
Zároveň vzniká spousta zpětné vazby, kterou je možné zase sbírat a strategii vylepšovat.
K tomuto účelu jsou sbírána metadata o jednotlivých spojení (IP adresa zdroje, port, počty paketů…) a také varování z detekčního systému Surikata. Data anonymizujeme a k identifikaci konkrétního routeru používáme haš, který se ale mění a uživatel si jej může také sám vyměnit.
Uživatel pak nasbíraná data vidí u sebe na routeru a pak také ve veřejně dostupném rozhraní Kibana, kde jsou data agregována ze všech routerů.
Jednou z důležitých metrik je čas strávený v honeypotu. Našim cílem je, aby útočník co nejvíce času trávil v honeypotu a ne v legitimních službách.
Díky datům o útocích je možné sdružovat jednotlivé zdroje provozu do pravidel, která pak slouží k přesměrování útočníka do honeypotu.
Nástroj Ludus je připraven pro uživatele routerů Turris a Omnia, stačí si nainstalovat balíček ludus. Nástroj je plně automatický, najde sám produkční porty a nastaví správné honeypoty. Pokud se rozhodneme vytvořit novou strategii, vaše instalace ji sama objeví a nainstaluje.
Michal Hrušecký: Novinky ze světa routerů Turris
Michal Hrušecký z CZ.NIC představil novinky v projektu Turris, které se udály za poslední rok. Nejvíce nás zaměstnal projekt Mox.
Ten byl zahájen kampaní na Indiegogo, která byla sice dobře naplánovaná, ale nakonec bylo všechno jinak. Začali jsme se čtyřmi moduly a věděli jsme, že máme spoustu možností, jak projekt rozvíjet.
Rychle se ale ukázalo, že lidé chtějí další moduly. Protože se na ně všichni ptali, tak jsme je také dodatečně zveřejnili.
Nakonec bylo k dispozici sedm desek, dvě procesorové, různé krabičky a vylepšení. Skončili jsme s miliardou možností, které jsme museli vyřešit. Trvalo nám to déle, ale nakonec se to podařilo.
Mox je modulární router, který je přizpůsobitelný a může si ho postavit běžný uživatel. Můžete si udělat něco menšího než Omnia, ale zároveň něco mnohem většího.
Součástí projektu je i bezpečnostní program, aktualizace a podpora.
Základní procesorový modul má dvoujádrový procesor ARM s 512 MB nebo 1024 MB RAM, Ethernet, USB a je možné jej rozšířit dalšími moduly. Zvolili jsme prověřený standardní konektor PCI, takže kdokoliv může vyrábět vlastní rozšiřující desky.
K dispozici jsou moduly pro PoE napájení, Wi-Fi, mPCIe, čtyřportový ehternetový switch, optický port nebo další USB porty. Závislosti mezi některými moduly nejsou úplně triviální, proto jsme vytvořili Mox Configurator, který vám umožňuje přehledně zjistit, co je možné s čím kombinovat.
Konfigurátor najdete na mox-configurator.turris.cz.
Mox je možné koupit také nově na Amazonu, kde nejsou k dispozici všechny kombinace, ale čtyři už připravené varianty. Už v kampani se objevila informace o tom, že modulární koncept se velmi špatně vysvětluje uživatelům.
S vývojáři už začaly komunikovat různé firmy, které problematice rozumí více. Pochopily, že Mox nemusí být jen router, ale dá se z něj složit mnoho různých zařízení.
Jde například o firmy vyrábějící IoT zařízení, poskytovatele připojení a další.
Omnia se osvědčila jako platforma, na které další firmy staví další řešení. Je to výkonná platforma, která je navíc otevřená a je možné ji využít mnoha různými způsoby.
Mozilla například připravila software pro IoT, ČTÚ používá Omnie pro měření kvality LTE, švédská firma dává routery do autobusů, vlaků a taxíků. Poskytují připojení k internetu cestujícím, ale připojují do něj senzory, systém pro nákup lístků a informační systém pro cestující.
V letošním roce vyšel Turris OS 4.0, který je postaven nad OpenWRT 18.06. Máme tam vlastní patche, protože se buď ještě nedostaly do upstreamu nebo se s vývojáři neshodneme.
Důležité je, že Turris OS je teď výrazně blíže vývoji OpenWRT. Hodně s nimi teď spolupracujeme. Můžete si také vybrat různé testovací větve a pomoci nám s testováním.
Mezi novinkami je integrace NextCloudu a nové webové ovládací rozhraní ReForis. Je jednodušší na správu pro nás a uživatelsky přívětivější pro nás.
Pro uživatele se také rozdělila dokumentace, protože u té původní nebylo jasné, co je oficiální návod a co je práce komunity. Nově je tedy na wiki.turris.cz komunitní dokumentace, na docs.turris.cz jsou věci podporované vývojáři. Starou wiki postupně čistíme a předáme ji komunitě, své návody budeme přidávat už jen do docs.
Martin Prudek: Turris:Sentinel – sběr dat a dynamický firewall znovu a lépe
Systém sběru dat je tu od začátku projektu Turris, původně se jmenoval uCollect. Bylo to klient-server řešení, které nebylo škálovatelné a bylo napsané přesně na základě tehdejších požadavků.
Bylo to velmi robustní řešení s mnoha vlastnostmi, které se nakonec nikdy nevyužily. Kvůli tomu nebylo možné do systému přidávat mnoho dalších klientů. Už nám ale umožňoval vytvářet různé výstupy, které používáme dodnes, zejména greylist pro dynamický firewall.
Nový systém Sentinel už byl postaven na letitých zkušenostech. Už jsme přesně věděli, co chceme a co vůbec nepotřebujeme.
Hlavním cílem byla škálovatelnost a maximální jednoduchost. Nevíme, kolik milionů routerů Mox se vyrobí a my na to chceme být připraveni.
Pro každý zdroj vznikla pipeline, která se stará o jednu část dat. Umožňuje nám to kdykoliv za provozu replikovat kteroukoliv část infrastruktury a rozšiřovat ji.
Pro propojení jednotlivých části byla vybrána technologie ZMQ, což je jakési „TCP na steroidech“. Prakticky zdarma nám dává škálovatelnost a load balancing.
Zatím jako jediný výstup vzniká DynFW, tedy greylisting škodlivých adres získaný z honeypotů. Výstupy jsou veřejně dostupné na view.sentinel.turris.cz, kde jsou vidět útoky podle států a jsou tu vidět i nejčastěji používaná hesla. Zatím tam toho moc není, chceme postupně přidávat další pohledy.
Libor Peltan: Novinky v projektech Knot DNS a Knot Resolver
Laboratoře CZ.NIC vyvíjejí autoritativní server Knot DNS a také rekurzivní server Knot Resolver. První představovanou novinkou v Knot DNS je Offline KSK, která umožňuje mít KSK mimo aktivní server. DNSKEY se totiž příliš často nemění, takže stačí jen jednou za čas udělat ceremoniál, kdy se klíče vymění offline.
V zóně .cz už se něco podobného používá delší dobu, ale byly k tomu používány skripty, které nebyly univerzální.
Další novinkou je zrychlení updatů do zóny. Knot DNS patří mezi nejrychlejší servery na světě, ovšem jen z hlediska odpovídání klientů. Vyžaduje to, aby zóna byla předem připravená. Když pak přijde malá aktualizace, musí se celá zóna znovu vygenerovat.
Například v německé zóně to trvalo dvě až tři minuty, teď je možné to stihnout v průběhu několika sekund.
Mezi další novinky patří DS push, který je součástí automatizace DNSSEC, což opět zjednodušuje práci provozovatelům autoritativních serverů. Chceme, aby co nejvíce operátorů nasadilo DNSSEC, ale oni se o tom nechtějí starat.
Pokud má operátor ve správě podřazenou i nadřazenou zónu, chce nějak automatizovat přenos DS záznamu do nadřazené zóny. Nově je možné to udělat automatizovaně pomocí zónového přenosu.
V Knot Resolveru je nově implementovaný watchdog zapojený do systemd, který je schopen restartovat zaseknutý server. Nemělo by se to stávat, ale už se to jednou stalo. Takže jsme implementovali možnost restartu.
Přidán byl také modul pro DNS-over-HTTPS (DoH) a zvýšila se efektivita keše pomocí black lies. Pracuje se také na zvýšení výkonu díky zrychlení síťových operací a zrychlení odpovídání z keše. Jsme tak schopni odbavit více dotazů, do budoucna chceme také snížit latenci.
Dříve se v Knot Resolveru zaplnila keš, bylo nutné ji celou smazat a začít od nuly. To znamenalo prudké zvýšení latencí, protože keš byla prázdná.
Resolver teď obsahuje garbage collector, který běží paralelně s hlavním procesem, vyřazuje staré záznamy a uvolňuje keš průběžně.
Petr Špaček: Co (ne)přináší šifrování DNS
V poslední době roste z mnoha stran tlak na šifrování DNS provozu, nejvíce se toto téma skloňuje v souvislosti s prohlížečem Firefox. Zpravidla se tu ale směšují čtyři různé věci, což celou diskusi zatemňuje.
Tyto čtyři věci jsou: DNS-over-HTTPS (DoH), Trusted Recursive Resolver (TRR), DNS v Cloudu (DoC) a DNS v aplikaci (add). Nejjednodušší je vysvětlit DoH: to se jen DNS zabalí do HTTP, to se zabalí do TLS a nakonec to pošleme přes TCP. Jiná změna v tom není, nijak fundamentálně to nemění vlastnosti původního protokolu.
Mnohem zásadnější změnou je TRR, kdy Mozilla za vás vybere nejvhodnějšího poskytovatele DNS resolveru. DNS už není součástí vaší sítě, ale je to resolver někde v cloudu na internetu.
Výsledkem pak je DNS uvnitř aplikace, které se nespoléhá na systémovou knihovnu, ale vše se vyřeší v prohlížeči a posílá se HTTPS tunelem někam do internetu.
Firefox přišel ještě s jednou specialitou, kterou zatím nenajdeme nikde jinde: kanárkovou doménou. Pokud ji zablokujeme na lokálním resolveru, Firefox by to měl pochopit jako instrukci k vypnutí DoH. Někdy to funguje, někdy to nefunguje. Doporučuji přečíst článek od Mozilly.
Najdete ho na support.mozilla.org.
Co všechny tyto změny znamenají z hlediska architektury DNS? V obvyklé situaci prohlížeč komunikuje se stub resolverem, což je knihovna v operačním systému. Ta posílá dotazy na DNS resolver získaný z DHCP – to bývá obvykle nějaký domácí modem s malou keší. Pokud se odpověď nenajde v keši, posílá se dotaz na větší resolver u poskytovatele a pokud není odpověď ani tam, ptá se poskytovatel přímo autoritativních serverů.
Autoritativní servery v tomto případě vidí jen IP adresu resolveru poskytovatele, protože to je on, kdo za uživatele pokládá dotazy do internetu. Neví nic o tom, odkud dotaz přišel na resolver.
Když se mluví o DNS v cloudu, tak se vlastně změní umístění resolveru. Odřízneme ho od místní sítě a přesuneme někam do cloudu na blíže nespecifikované místo.
Zbytek situace je pak stejný, až na to, že autoritativní servery vidí IP adresu cloudového resolveru.
Firefox navíc obchází zmíněnou systémovou knihovnu a komunikuje přímo s resolverem v cloudu. Nevypadá to jako velká změna, ale opak je pravdou. Za prvé chybí sdílená keš, takže každá aplikace se musí ptát znovu sama za sebe. Za druhé chybí sdílená konfigurace, takže každá aplikace může používat jiný resolver s jinou politikou. Třetím problémem je, že všechny dotazy jsou oddělené a otevírají se pro ně samostatná spojení do cloudu.
To v důsledku komplikuje ladění a nasazení čehokoliv, co používá DNS. Neexistuje jednoduchý způsob, jak zjistit, kam která aplikace dotazy posílá a proč třeba jedna služba nefunguje a ostatní ano.
Když se řekne cloud, tak se tím obvykle myslí velká internetová služba, kterých není moc. Těch velkých veřejně dostupných DNS resolverů je tak málo, že se dají spočítat na prstech dvou rukou.
Jak velká je to redukce provozu v porovnání s tradičním stavem? Na autoritativní servery domény .cz přijde denně nejméně 1000 dotazů průměrně ze 100 000 IP adres. Samozřejmě může mít jeden resolver více IP adres a běžně se to dělá.
Přesto je vidět, že konsolidace na pět velkých cloudových resolverů by znamenala dramatickou změnu. Zvýší to atraktivitu pro útočníky, protože návratnost útoku bude najednou úplně jiná.
Často se jako argument pro DNS resolver v cloudu uvádí lepší parametry výhodné pro uživatele. Záleží ovšem na tom, jaká kritéria si stanovíte.
Nejdůležitější pro výkon DNS resolveru je poměr dotazů odbavených z keše (hit rate). Dalšími důležitými parametry jsou latence mezi klientem a resolverem a také algoritmus výběru autoritativního serveru. Úplně na posledním místě, z hlediska latence, je pak komunikační protokol. Pokud se dobře vyřeší navazování spojení a jeho údržba, pak zvolený protokol nehraje příliš velkou roli.
Z hlediska nákladů je ale situace velmi odlišná. Na prvním místě sice stále zůstává úspěšnost kešování, zásadní se ale naopak stává komunikační protokol. Je tu totiž velká asymetrie mezi situací na klientovi a na resolveru. Tam se schází velké množství spojení a je to vlastně jediná věc, kterou ten resolver dělá.
Rostou tak náklady na udržování spojení, paměť a šifrování. Pokud bude nevhodně zvolený komunikační protokol, bude to celé drahé na provoz.
Co je tedy rychlejší? Neexistuje na to jednoduchá a jednoznačná odpověď.
Pokud máme například malý resolver v kanceláři, bude mít proti němu cloudový poskytovatel výhodu ve velké naplněné keši. Záleží ovšem na latenci mezi námi a resolverem. Pokud bude velká, dobrá keš už nás nezachrání.
Pokud ale používáme místní resolver našeho velkého poskytovatele, budou výsledky vynikající, protože všichni uživatelé využijí informace v keši, které se tam dostaly díky dotazům ostatních. V takové situaci je keš velmi dobrá, latence jsou nízké a nemá smysl jít do cloudu.
Nejsložitějším tématem v této oblasti je soukromí. Tady se dostáváme na pomezí technických věcí a politiky. Tím se obvykle všechno zkomplikuje.
DoH přidává k DNS šifrování v podobě TLS. HTTP tam nehraje žádnou roli, to žádné zabezpečení nepřidává.
Je ale potřeba se na otázku soukromí podívat ze širšího pohledu. Načtení jedné webové stránky dnes může vyvolat stovky požadavků poslaných na desítky IP adres. Na načtení hlavní stránky iHned.cz se spotřebuje 317 HTTP požadavků na 61 unikátních IP adres.
Pro každý jednotlivý objekt se musí přeložit jméno serveru pomocí DNS, naváže se spojení TCP, poté se naváže TLS a pomocí HTTP se stáhne obsah. Tento obsah typicky odkazuje na další objekty, což vyvolává další požadavky.
V tradiční architektuře putuje jméno webu do stub resolveru, poté do místního resolveru, případně k poskytovateli nebo na autoritativní servery. V 95 % případů je odpověď v některé keši, takže nemusíme vůbec na internet.
Poté klient otevře TCP spojení, stáhne stránku a získá třeba cookie. Toto se opakuje pro všechny stahované objekty. Poskytovatel připojení z DNS provozu vidí, na jaké weby daný uživatel přistupuje. Zároveň to ví web server a spousta dalších služeb, které se to dozví uvnitř HTTP. Třeba Google Analytics.
Z hlediska síťového provozu není obsah HTTPS vidět, protože je schován v TLS. Jméno webového serveru se stejně dozvíme, protože se posílá v TLS. Existuje návrh řešení, které se jmenuje ESNI. Pokud by byl standardizován, což není, a implementován, což není, pak by nám tento kanál zmizel.
Stále by tu ale zůstaly informace z DNS.
Kdybychom přešli se šifrovaným DNS do cloudu, pak náš poskytovatel do DNS nevidí a informaci nedostane. Informace nezmizela, jen se přesunula z rukou poskytovatele připojení do rukou poskytovatele cloudu.
Na místní síti pak zůstává viditelná jen informace o IP adrese, na kterou se klient připojuje. A uvidí hodně IP adres, protože se připojujeme k mnoha službám. Připomínám, že sledovací služby po HTTP stále uvidí stejné informace, to se nezměnilo.
Otázkou je, co je možné zjistit z IP adresy. Vědci z univerzity z Illionis se na tento problém podívali a zjistili, že u 95 % stránek se klient připojuje na sadu unikátních IP adres. Touhle metodou je možné deanonymizovat drtivou většinu webů, aniž bychom se dívali do obsahu.
Jde navíc o velmi jednoduchou statistiku, není potřeba žádné strojové učení ani jiná magie. Tím by se to dalo zřejmě ještě zpřesnit.
Řešením by mohla být VPN, přes kterou bychom poslali všechen provoz. Tím bychom to ale příliš nevylepšili. Poskytovatel sítě sice nemůže dělat analýzu provozu, ale prakticky se poskytovatel VPN dostává do stejné pozice, jakou měl předtím poskytovatel připojení.
VPN nesníží množství informací o uživateli, jen je přesune od jednoho poskytovatele k jinému. Můžete si vybrat, komu věříte víc.
Šifrování DNS samo o sobě soukromí nezlepšuje. Všechny informace dokáže útočník zjistit analýzou provozu. Přesun DNS do cloudu soukromí nezlepší, protože zdvojnásobíme počet stran, které vědí, které stránky uživatel navštěvuje.
DNS je jen velmi malou součástí problému, sledování po HTTP je dnes úplně všude. Měli bychom možná síly napnout jiným směrem.
Maciej Andziński: Pasivní analýza dostupnosti DNS serverů
Všechny autoritativní servery pro doménu .cz používají anycast a jsou ve 13 lokalitách v 10 zemích: Česko, Rakousko, Německo, Itálie, Švédsko, Británie, Japonsko, Kalifornie, Brazílie a Chile. Při umisťování serverů je potřeba se správně rozhodnout, jaké lokality jsou nejvýhodnější. Věříme, že na to dokážeme odpovědět, pokud víme, odkud k nám dotazy přicházejí a jak dlouho jim trvá cesta.
Na první část je snadné odpovědět, stačí k tomu znát IP adresy zdrojů. Pro DNS server je ale těžké zjistit, jak dlouho trvala dotazu cesta po síti.
Řešením by bylo použít aktivní měření, například pomocí pingu nebo s využitím sítě měřicích sond RIPE Atlas. My jsme ale zvolili jiný přístup a zachytáváme veškerý provoz na naše servery. Rozhodli jsme se získat informace o zpoždění z dat, která už máme.
Za první dva říjnové týdny bylo zachyceno 17 miliard dotazů, drtivá většina z nich (99,74 %) přišla pomocí UDP. Přestože z relativního pohledu bylo TCP zastoupeno velmi málo, stále šlo o 38 spojení každou sekundu.
Právě TCP handshake může být dobrým vodítkem, protože si při něm obě strany vyměňují větší množství paketů. Z časů mezi jednotlivými pakety je pak možné odhadovat průměrný RTT. Ke každé IP adrese je pak k dispozici informace o AS a zemi, takže je možné posuzovat dostupnost podle různých částí světa.
Z dat plyne, že nejlepších časů dosahují uživatelé z Evropy a Jižní Ameriky. Naopak nejhůř je na tom střední Afrika a odlehlé oblasti jako Papua-Nová Guinea. Tam časy přesahují 300 ms. Musíme brát v potaz také počty dotazů z daných zemí.
Nejvíce dotazů přichází pochopitelně z Česka, které také dosahuje nejlepších časů. Velmi dobře je na tom také zbytek Evropy, ze kterého přichází také poměrně hodně dotazů. Oblasti jako Polynésie a Mikronésie mají sice nejhorší časy, ale přichází z nich naprosté minimum dotazů.
Stejné měření proběhlo už v květnu a mezi tím byl nainstalován nový uzel v Itálii a překonfigurováno BGP. Podařilo se nám tím snížit RTT v některých odlehlých oblastech jako východní Asie nebo jižní Amerika.
Ukazuje se tedy, že záleží na geografické poloze a také na nastavení BGP a stavu peeringu v dané oblasti.
