CSNOG je neformální sdružení provozovatelů sítí v Čechách a na Slovensku, které umožňuje setkávání, výměnu zkušenosti a jednou za rok pořádá v Brně dvoudenní odbornou konferenci. Protože to vyžaduje současná pandemická situace, letošní ročník byl přesunut do online prostoru.
Základem konference CSNOG je programový výbor, který vyhledává přednášející a volí přednášky do programu. Snažíme se vybírat tak, aby nešlo o marketingovou akci, kde si výrobci pochváli své výrobky,
řekl na začátku konference Ondřej Caletka. Programový výbor by se měl pravidelně obměňovat a kdokoliv má možnost se do něj nanominovat a po zvolení nahradit některého z členů v současném výboru.
Ondřej Caletka: rozvoj služby RIPE RIS
RIS je poměrně starý systém, který se snaží zachytit topologii současného internetu. Internet je postavený na protokolu BGP, který propojuje autonomní systémy mezi sebou. Ty si nabízejí IP prefixy a nabídky pak posílají dále.
Vznikají tak různé cesty mezi autonomními systémy. Pohled na internet pak závisí na tom, odkud se díváme. Pokud chceme mít ucelenější pohled, musíme se dívat z různých míst.
RIS se tedy tváří jako další síť na internetu, ale ve skutečnosti jen poslouchá, jaké prefixy se prostřednictvím jakých cest nabízí. Dělá to z různých míst a zároveň zachytává všechny zprávy a tím sleduje změny.
Sbíraná data se pak zpracovávají různými způsoby, tím nejzajímavějším je služba RIPEstat, která dovoluje v datech vyhledávat. Dále je možné data odebírat pomocí API nebo sledovat živě přes WebSockets ve službě RIS Live.
Ondřej Caletka, moderátor a přednášející
Sběr dat probíhá dvěma způsoby: kolektory v peeringových uzlech a multi-hop kolektory. V peeringových uzlech server komunikuje s ostatnímu účastníky a zjišťuje, jaké cesty mu posílají. Takto se dá pokrýt jen omezený počet uzlů, v současné době máme obsazeno 18 peeringových center.
Druhou variantou jsou multi-hop kolektory, které nemusí být síťové blízko k sítím a používají takzvané multi-hop BGP. Sbíráme data na velkou vzdálenost, což může znamenat, že spojení nemusí být stabilní a některé data se mohou ztrácet.
V současné době je toto řešení nasazeno na dvou místech: v Amsterodamu a v Uruguayi.
Klíčová otázka je, jestli má smysl přidávat další sběrače dat. Znamená víc dat automaticky lepší data?
Meziročně se podařilo nasbírat dvakrát více dat, takže jejich zpracování je dvakrát delší. Otázkou ale je, jestli má smysl jít po množství nebo se naopak pokusit zvýšit kvalitu dat. Je tedy třeba zajistit více diverzitních dat. K čemu by se dala využít?
Rozmístění kolektorů RIPE RIS
Je možné takto odhalit například únosy BGP, které se v současné chvíli ztratí. Když k němu dojde na uzlu, ke kterému nejsme přímo připojeni, nemůžeme dnes přesně určit, odkud útok přišel.
Vývojáři tak přemýšlejí nad tím, jak zlepšit svou peeringovou strategii, aby získávali co nejkvalitnější data. Nechceme, aby bylo dat jen víc, ale měla by být reprezentativnější. Nevíme, do jaké míry jsou naše data zaujatá a liší se od skutečného internetu.
Jan Žorž: stavíme „chytrý dům“ a chceme ho?
Když Jan Žorž stavěl dům, rozhodl se pro „chytrý“ dům plný IoT. Při tom měl dvě možnosti: pořídit za drahé peníze hotové řešení nebo jako technicky založený člověk si vše postavit. Rozhodl jsem se, že si všechno udělám sám. Je to větší legrace, ale uvědomte si, že vás to bude stát spoustu času.
Další otázkou bylo, jak naložit se soukromím. Můžete pořídit levné senzory a připojit je přes internet do cloudu. Nebo vše založíte na domácí bráně, která nebude používat cloud a budete data držet doma.
Z pochopitelných důvodů se rozhodl držet mimo cloud, ale přichází další otázka: je třeba si postavit vlastní server nebo využít nedokonalá hotová řešení. Odpověď je samozřejmě ne, chci mít prostředí plně pod kontrolou.
Nakonec se rozhodl nasadit linuxové řešení na DeskMini PC s procesorem i5, 32 GB paměti a jako distribuci využil Ubuntu.
Server je energeticky nenáročný a zároveň neprodukuje příliš mnoho tepla. Máme pasivní dům, takže by to byl velký problém. Ten dům není problém vytopit, je naopak problém ho chladit.
Tichý a nenáročný server
Jan poté nakoupil různé nekompatibilní senzory využívající různé protokoly a software. Všechna jsem nainstaloval a vyzkoušel. Až poté jsem zjistil, co vlastně potřebuji a jak to funguje.
Nakonec se rozhodoval mezi OpenHAB a Domoticz a zvolil druhé jmenované řešení, kvůli lepšímu software. Do něj lze přidat také Zigbee controller zvaný Zigate a Jan ještě připojil LoRaWAN. Mám k ní připojenou pastičku na myši, není to nic kritického.
IoT je podle Jana Žorže divokým západem, kde existuje velké množství dodavatelů vyrábějících zařízení různé kvality. Kdo vám řekne, co je co? Jak bezpečné to je? Ohrozí to vaše soukromí?
Pokud se nebudete zabývat bezpečností, někdo vám může systém nabourat a otevřít si hlavní dveře. Už se podařilo hacknout dodavatele zámků a odemknout naráz 6000 dveří po celém světě.
Poté, co takovou síť postavíte, musíte testovat a zase testovat. Číst si o tom vám žádné nové zkušenosti nepřinese. Musíte to skutečně používat.
Nutné je také sledovat skutečný život v domě a tomu pak přizpůsobovat chování celého řešení. Důležité je ale zachovat možnost klasického manuálního ovládání pomocí vypínačů na zdi. Představte si, že k vám přijede na víkend babička.
Tomáš Kubina: segment routing – teorie a použití
Princip source routingu spočívá v tom, že už zdrojový router určí cestu, kterou bude paket putovat. Tuto cestu zapíše do paketu v podobě segmentů, které pak routery po cestě respektují. Cílem je zjednodušit správu a škálování celé sítě.
Segment routing potřebuje jen IGP, není potřeba ani LDP ani RSVP. Novější verze SRv6 odstraňuje dokonce potřebu MPLS a používá jen IPv6 adresy.
Další výhodou je, že ve výchozím stavu podporuje ECMP a umožňuje snadno zajistit redundanci sítě.
Základním segmentem je takzvaný SID, tedy Semgent IDentifier. Těch existuje více typů: globální Prefix-SID identifikující router, lokální Adjacency-SID a Binding-SID umožňující nahradit SID seznamem jiných SIDů.
Příklad síťové topologie
První variantou nasazení je SR-MPLS, což je zároveň nejjednodušší způsob použití. Pro kódování SID se používá MPLS a pro distribuci se využívá IGP. Ve výchozím stavu se forwarduje podle IGP best path.
Odesílající router přidá do MPLS hlavičky ID cílového routeru, následující router v řadě provede label swap a pošle paket dále. Předposlední router pak hlavičku odstraní a předá ji do cíle. Dále je možné použít kombinace založené na SR-MPLS jako SR-TE nebo TI-LFA.
Ignas Bagdonas: BGP Telemetry
Telemetrie znamená čtení dat o nějakém nástroji a jejich předání dále. V telekomunikačním prostředí to není nijak nový koncept.
Protokol BGP funguje obvykle velmi dobře, ale někdy je dobré vidět dovnitř BGP operací, zejména v případě nějakých problémů. Máme k tomu řadu nástrojů: MRT, SNMP, CLI či různé proprietární logovací mechanismy. Další variantou je využít BGP pro monitoring sebe sama – jedná se o řešení typu „looking glass“.
Pokud potřebujeme něco lepšího, můžeme využít BMP – BGP Monitoring Protocol. Jde o samostatný protokol, ne o rozšíření BGP.
Zaměřuje se na nízké zatížení síťového prvku a nabízí model push, kdy zasílá data proaktivně bez nutnosti se na ně dotazovat. Pro korelaci jednotlivých událostí jsou tu časové značky.
Výsledkem je podrobný vhled do práce BGP.
BMP odesílá všechny informace do externího kolektoru a nezpracovává je lokálně přímo na síťovém prvku. Dovoluje provádět takzvaný mirroring, tedy přeposílání kopie celých BGP zpráv. To probíhá ještě před zpracováním BGP, takže budou předány i škodlivé či chybné zprávy. To se hodí při sledování chyb NLRI nebo hledání podvodných zpráv.
Dále může pracovat v režimu events, kdy předává informace o změně stavů sezení včetně například přetížení prvků či administrativních zásahů. Nejzajímavější a v praxi nejužitečnější je monitoring, který umožňuje sbírat data o prefixech, včetně stavu před a po aplikaci politiky. Informace přicházejí včetně všech atributů, což umožňuje jejich sledování.
Výhodou je, že tyto zprávy jsou kódovány od běžných BGP zpráv, takže jejich sběr nevyžaduje nijak rozsáhlou úpravu stávající infrastruktury.
BMP dovoluje také sbírat statistiky jako počítadla prefixů či počítadla výjimečných událostí – vadných či falešných oznámení, smyček v cestách a podobně. Můžete je dostávat pravidelně nebo při splnění předem stanovených podmínek.
Ze softwarového hlediska je nutné, aby generátory i kolektory uměly s BMP pracovat. Většina dodavatelů síťových prvků nabízí funkce BMP generátoru.
Na straně kolektorů existuje velmi silný ekosystém, jak otevřených tak uzavřených řešení. Odvětví se postupně učí používat BMP jako standardní způsob monitoringu BGP.
Alexander Zubkov: praktické poznámky k nasazení Bird
Alexander Zubkov pracuje pro společnost, která nabízí svým klientům ochranu proti DDoS útokům. Kvůli tomu provozují rozsáhlou filtrační síť postavenou na Linuxu či na zařízeních Arista a Mellanox. Děláme také BGP analytiku a na linuxových serverech používáme Bird.
K tomu používají různé technologie jako BFD, Large communities či FlowSpec. Milujeme Bird za jeho bohaté možnosti filtrování a práci s tabulkami. V budoucnu plánujeme nasadit na něm také RPKI.
Bird běží v jednom vlákně a dělá takzvaný IO cyklus, během kterého zpracovává různé události. Bird má i svá omezení, například pro každý protokol může existovat jen jedna tabulka v jádře a v routovacím démonovi. Dalším problémem je, že pokud by měl Bird poslouchat na neexistující adrese, odmítne se spustit. Vytvořili jsme proto vlastní patch, který tento problém obchází a dovoluje démonovi nastartovat. Pokud se adresa na rozhraní objeví později, připojí se k ní a začne na ní poslouchat.
Bird také nemůže pracovat souběžně s několika BGP spojeními, která mají stejnou adresu sousedů. I když budou mít jinou lokální adresu, bude vždy fungovat jen jedno spojení. Zatím jsme to nijak neřešili, protože nám to příliš nevadí.
Bird také umožňuje nastavit rekurzivní routu, ale podporuje jen jeden stupeň rekurze. Například interní BGP je multi-hop, proto všechny routy přes tento protokol budou rekurzivní.
Bohužel Bird nemá BGP agregace, ale můžeme je nějakým způsobem nahradit. Můžeme například připravit statickou rekurzivní routu a nasměrovat ji do adresy původní routy. Musíte ale tuto routu odfiltrovat, pokud bude nedostupná. My tenhle trik používáme.
Alexander Kozlov: měříme spolehlivost internetu
Společnost Qrator opakuje pravidelně svá měření spolehlivosti internetu jak na globální úrovni, tak i v jednotlivých státech. Na základě toho vzniká jakýsi rating. Vždycky korelujeme množství autonomních systémů z určitého státu s tím, kolik adres ten stát má. Poté vyhledáme největší autonomní systém.
S jeho výpadkem tak z globálního výpadku bude nedostupné určité množství zdrojů.
Rok 2020 je výjimečný z toho důvodů, že dlouholetý vedoucí žebříčku se přesunul na druhé místo. Původně bylo na prvním místě dlouho Německo, letos ho nahradila Brazílie.
Je to jediný stát, který by v případě největšího operátora měl výpadek méně než dvě procenta. Je tam vidět obrovský nárůst kvality infrastruktury.
20 zemí nejodolnější proti síťové chybě
Česko bylo dlouho na 20. pozici, ale některé jiné země rozvíjí infrastrukturu rychleji. Teď je na 21. místě, což ale vůbec není špatně. Do dvacítky se nám probojovaly čtyři další země.
Největší meziroční nárůst byl zaznamenán v Nizozemsku, Spojených státech, Singapuru a Hong Kongu.
V Česku je zajímavé to, že nejkritičtějšího operátora tu tvoří ISP Alliance (ASN 47232), což je volné sdružení operátorů. To je situace, kterou nepozorujeme jinde na světě.
Tento autonomní systém zahrnuje více než 6,5 % místních zdrojů.
Slovensko je až na 77. místě, kam přeskočilo ze 100. místa. V loňském roce by výpadek největšího poskytovatele Benestra znamenal výpadek 18,6 % zdrojů, letos je to 15,4 %.
Česko je na tom velmi dobře také z hlediska protokolu IPv6. Přestože Google uvádí 50% globální penetraci a v Česku jen asi 12%, v našem žebříčku se dostalo na osmé místo.
To je dobrá zpráva pro český trh i síťaře, kteří se novým protokolem zabývají.
Rudolf Vohnout: kvantová distribuce kryptografických klíčů
S nástupem kvantových počítačů a správné implementaci algoritmů bude dešifrování současných šifer trvat mnohem kratších dobu než při použití konvenčních počítačů. Symetrická kryptografie je obecně považována za bezpečnější než asymetrická. Problémem je ale přenos klíče.
Pokud bychom ale dokázali bezpečně přenést klíč, získali bychom velmi bezpečný komunikační kanál. To je právě to, co se snaží řešit kvantová distribuce klíčů.
Je založena na principu náhody, kdy se generují provázané páry fotonů, které pak putují k oběma stranám komunikace. Tento proces nám zajišťuje náhodnost.
Přehledně je to zobrazeno na videu popisujícím protokol BB84:
Výsledkem je bezpečně přenesený klíč, který je pak použit k šifrování samotného datového přenosu. Největší úskalí tohoto přenosu klíčů je klesající přenosová rychlost s rostoucí vzdáleností. Se vzdáleností téměř lineárně klesá množství správně doručených provázaných párů fotonů.
Zatímco na několik kilometrů dokážeme přenášet gigabit za den, z Prahy do Vídně už rychlost klesne na stovky bitů za den.
Nejbezpečnější šifrovací metodou je Vernamova šifra (One-time Pad), která ale vyžaduje pro šifrování jednoho bitu informace přidat právě jeden bit náhodného neopakujícího se klíče. Proto je velmi náročná na objem klíče samotného. Řešením je vygenerovat klíč pro klasickou symetrickou šifru, například AES. Takto můžete klíč používat opakovaně.
Na rozdíl od Vernamovy šifry je ale možné v budoucnu použít konvenční počítač a pokusit se zprávu dešifrovat. V tu dobu už ale nemusí být ta informace důležitá, takže nám to nemusí vadit.
Takovou službu může použít kdokoliv, kdo má nároky na vysoce bezpečný datový přenos. Už máme několik partnerů, kteří už projevili zájem. Patří mezi ně Státní pokladna, Ministerstvo obrany a Ministerstvo vnitra.
Sdružení CESNET je zapojeno do projektů jako OpenQKD, QUPITAL, Euro QCI. Získali jsme také projekt na testování QKD v České republice a na to navázané sestavování šifrovacích klíčů.
Radek Zajíc: existuje business case pro nasazení IPv6?
Pokud vysloveně nestavíte novou síť a nemáte jasný postup, jak zavést IPv6 jako primární protokol, nenajdete pravděpodobně způsob, jakým ospravedlnit obměnu všeho naráz. IPv6 ale není jen záležitostí síťařů, ale musíte ji řešit i v aplikacích, trénink zaměstnanců, monitoring a podobně.
Existuje něco, co dokáže ospravedlnit nasazení IPv6 do infrastruktury a aplikací?
Jeden z důvodů pro nasazení může být to, že vaše konkurence IPv6 nasazuje. Pokud se mu nebudete věnovat, může se vám stát, že vám zákazníci odejdou. Tomu rozumí každý manažer.
Skutečným příkladem je GitHub, který dodnes nepodporuje IPv6. Konkurenční GitLab ho ovšem podporuje a protože IPv4 adres je málo, je to pro ně konkurenční výhoda. Zákazník tak může zjistit, že se z prostředí bez IPv4 konektivity nedostane ke svým repozitářům.
Dalším důvodem může být to, že nový protokol používají vaši partneři. Čína má například ambiciózní plán, že budou mít plně nasazeno do roku 2025.
Během několika let se tak může stát, že Číňané začnou opouštět IPv4 a pokud nebudete připraveni, můžete se pro ně stát nedostupnými.
Dalším problémem je, že IPv4 adresy jsou čím dál dražší. Cena se v posledních letech stále zvyšuje, protože je jich málo.
Můžeme samozřejmě adresami šetřit, ale současné způsoby mají své limity a také svou cenu. Pokud nechcete neustále kupovat výkonnější zařízení pro překlad adres, dává smysl přelít velkou část provozu po IPv6.
Data ze zahraničí ukazují, že 30 až 50 % spojení je možné uskutečnit po IPv6.
Pokud poskytujete nějakou službu a chcete ji mít na trhu i za pět až deset let, dává smysl se zabývat nasazením IPv6. Abyste se nestali opozdilci, kteří budou nasazovat jako poslední, když už vám budou odcházet zákazníci.
Pro provozovatele přístupové sítě je zásadní mít zabezpečené přípojky koncových zákazníků. Pokud bude IPv6 ignorovat, může jakýkoliv útočník do sítě odeslat oznámení směrovače a provoz z celého segmentu poslat přes svůj počítač. Bezpečnost je něco, na co manažeři slyší.
V případě IPv6 neexistuje nic jako velký třesk, během kterého byste všechno zapnuli a bylo by hotovo. Lepší je jít pozvolna postupnými kroky. Když ale začnete dnes a uděláte z IPv6 pevnou část své infrastruktury, určitě se to neztratí.
Už dnes si tak můžete definovat požadavky na hardware a postupně pak můžete po svých dodavatelích chtít, aby vám dodávali zařízení se správnými vlastnostmi. Když začnete brzy, můžete se na vše jednoduše připravit.
Nemusíte pak investovat obrovské peníze do nákupu nového hardware jen kvůli IPv6.
Důležité je začít malými krůčky, seznamovat se s protokolem a jít dál a dál. Pokud nezačnete teď, za pět let pořád nebudete mít nic.
Postupně zjistíte, že vám IPv6 přijde jako úplná samozřejmost. Nemusí to být na začátku dokonalé, to je normální. Jde i o postupné učení a zkoušení. Když uděláte chybu, poučíte se z ní.
IPv6 vám přímo nepřinese žádné peníze navíc. Existují ale důvody, proč už byste nemuseli čekat. IPv6 sítě jsou už reálné a IPv6 služby jsou už doslova za rohem.
Většina problémů s IPv6 byla v posledních deseti letech vyřešena. Běžte a nasaďte IPv6!
Petr Špaček: škálování DNS resolverů pro UDP, TLS a HTTPS provoz
Klasický přístup k měření DNS resolverů je implementovaný v nástroji resperf, přičemž se hledá maximální počet dotazů, které resolver zvládne vyřídit. Postupně se zvyšuje zátěž, až dosáhne bodu, kdy se dotazy začnou ztrácet. To je vyhodnoceno jako maximální hodnota, kterou resolver zvládá.
Pracuje se tu s textovým seznamem dotazů, který je ale výrazně chudší než běžný síťový provoz.
Tradiční přístup ignoruje prodlevy mezi dotazy, neřeší správu spojení a nezaznamenává, který klient vyvolal které spojení. V neposlední řadě není realistické ani postupné zvyšování zátěže, které se v běžném provozu neděje.
Resperf se tak zaměřuje na QPS, výsledkem jeho práce je jedno číslo a úplně ignoruje kontext.
DNS resolver má nejméně práce v případě, že má informace v keši. V takové situaci odpoví v řádu milisekund a poté už může uvolnit všechny zdroje.
Pokud je potřeba některé informace získat odjinud, musí se vydat na internet. To zabere stovky milisekund a po celou dobu je potřeba držet všechny informace potřebné k vyřízení dotazu.
V laboratořích CZ.NIC vytvořili nový nástroj, který je pracovně nazýván DNS Shotgun. Už si jej můžete stáhnout, ale ještě nemá hotové uživatelské rozhraní, takže není úplně příjemný na používání.
Vývojáři se rozhodli nezaměřovat na QPS, ale na počet skutečných klientů. Jinak se chová IoT krabička, mobil, desktop nebo mail server, který chrlí dotazy nepřetržitě.
DNS Shotgun pracuje ve třech fázích. Nejprve analyzuje provoz reálného provozu v PCAP souborech. V druhém kroku simuluje chování klientů, kteří byli zaznamenáni v předchozím kroku. Simulovaní klienti se pak chovají co nejblíže realitě, což je důležité například pro cache hit rate.
Ve třetím kroku jsou srovnány výsledky více běhů programů. Na konec program řekne, kolik klientů je schopen resolver obsloužit.
Kromě měření klasického UDP nás zajímají i šifrované protokoly TLS a HTTPS. K tomu se nejprve musíme rozhodnout, jakou verzi protokolu TLS použijeme. Stejně tak musíme volit podepisovací algoritmus nebo parametry udržování TLS spojení. Různé algoritmy mají různou výpočetní náročnost. V případě RSA 2048 bychom potřebovali pětkrát více výkonu, u RSA 3K pak dokonce dvacetkrát.
Proti tomu algoritmy založené na eliptických křivkách vyžadují jen 3,4krát více výkonu než v případě UDP.
Dopad šifrování na výkon DNS
Ještě o řád složitější je měření HTTPS, což je o řád složitější vrstva než samotná TLS. Museli jsme se rozhodnout, jakou verzi budeme věřit, zvolit metodu posílání dotazu, zapnout či vypnout HTTP kompresi a podobně.
Daly by se vymyslet stovky různých kombinací konfigurace. My jsme se zaměřili na standardní situaci, kdy se klient nesnaží škodit.
Měření ukazují, že rozumně nastavený DoH vyžaduje zhruba čtyřikrát více výkonu než čisté UDP.
Absolutně zásadní je, jaké certifikáty se používají. Vyhněte se RSA, jeho výkon je mizerný.
Důležité také je, jak se chová klient. Pokud drží dostatečně dlouho otevřené spojení, stačí nám zhruba čtyřnásobek výkonu proti UDP. Pokud klient spojení nedrží, potřebujete minimálně desetinásobek. Pozor na zobecňování, výsledky silně závisí na hardware, softwarové konfiguraci a na charakteristice konkrétního provozu.
Petr Špaček: DNS Flag Day 2020
Standard DNS je extrémně složitý, tvoří ho více než 3000 stran textu. Vznikají pak různé potíže v implementacích, nedodržování standardů a to vede k nekompatibilitám.
V minulosti to resolvery řešily tak, že přidávaly úpravy zlepšující kompatibilitu. Myšlenka je to dobrá, ale ukázalo se, že rozbité implementace nejsou motivovány k opravě a zůstávají rozbité.
Takových úprav pak přibývá a způsobují potíže i implementacím, které standardy dodržují.
Proto se dospělo k tomu, že se zodpovědní tvůrci resolverů dohodnou, že k určitému datu tyto úpravy odstraní. To způsobuje tlak na nezodpovědné tvůrce, kteří musí svůj software upravit. Pokud standardy dodržujete, nemusíte nic měnit a všechno funguje dál.
První kolo proběhlo v roce 2019, kdy se vývojáři snažili odstranit resolvery ignorující rozšíření EDNS. V průběhu roku se podařilo jejich počet snížit na méně než desetinu původní hodnoty. To je úspěch, naprostá většina zajímavých domén byla opravena. Zbytek je v podstatě odpad, který negeneruje žádný legitimní provoz.
Připojily se i tak velké firmy jako Google a Cloudflare, ale ani z globálního hlediska nebyly zaznamenány žádné potíže. Děkuji, moc to pomohlo zdraví DNS.
V letošním roce chtějí provozovatelé zlepšit spolehlivost resolverů a jako bonus také snížit latenci pro uživatele a zlepšit bezpečnost. Těchto cílů chceme dosáhnout tím, že se vyhneme problémům s IP fragmentací.
Fragmenty na IP vlastně nefungují, takže pokud autoritativní server pošle velkou odpověď, ta nikdy nedorazí. Odpověď se po cestě fragmentují a fragmenty se zahodí. Resolver pak neví, co se stalo. Zda je autoritativní server nefunkční, nebo je odpověď příliš velká a odpověď byla po cestě zahozena.
Resolvery tak mají kód, který se snaží hádat maximální velikosti odpovědi, která ještě projde.
Proto bude od 1. října 2020 koordinovaně změněna maximální velikost UDP odpovědi, která bude požadována a na druhé straně odesílána. Pro velké odpovědi se přepne na TCP, ale mělo by jít jen o malý zlomek provozu.
Z hlediska implementaci dodržujících standardy se nic nemění, nejde o nic nového.
TCP má výhodu v tom, že nepotřebuje IP fragmentaci, komplikuje podvrhávání provozu a jde o nezbytný krok pro nasazení DNS-over-TLS nebo DNS-over-HTTPS. Posílání DNS odpovědí přes TCP je stará věc, je s námi od počátku existence DNS.
Pro podporu TCP na autoritativních serverech tak není potřeba dělat nic speciálního, jen je nutné ověřit, že resolver odpovídá na TCP portu 53. Dejte pozor na to, aby vám tento port neblokoval firewall.
V říjnu bude změněna výchozí hodnota velikosti odpovědi, kterou je autoritativní server ještě ochoten poslat přes UDP. Snížíme ji na 1232 bajtů.
U resolverů je situace podobná, opět je potřeba ověřit dostupnost TCP portu 53 a maximální hodnota odpovědi, kterou je resolver ochoten přes UDP přijmout bude také nastavena na stejnou hodnotu.
Nizozemský výzkum ukázal, že nižší hodnota je spolehlivější. Přestože by bylo možné v mnoha situacích použít vyšší hodnotu, resolver nezná okolní podmínky, proto bylo rozhodnuto o bezpečné hodnotě 1232 bajtů. Podobný test udělal v srpnu 2020 i Google a na reálných datech ukázal, že nedochází k žádnému významnému rozbití domén či změně v provozu. Na českých doménách jsme dělali vlastní test a zjišťovali jsme, které domény nepodporují TCP. Zjistili jsme, že jde o pouhých 782 domén.
Nedojde tedy k žádným významným problémům.
Pokud si chcete otestovat své servery či domény, můžete použít příkaz dig s parametrem +tcp. Tento test je implementován také na webu DNSFlagDay.net.
Libor Peltan: novinky v DNS – XDP a catalog zones
XDP je zkratka pro eXpress Data Path a je to technologie, která dovoluje obcházet síťový stack v jádře. Účelem je zrychlit síťové operace a původně nebyla vymyšlena pro DNS. Více než kde jinde se v DNS používají malé pakety, takže každá režie je tu velice znát.
Vývojáři zkusili implementovat XDP v autoritativním serveru a výsledek je překvapil: došlo ke zrychlení o 60 až 200 %. Důležité je to u různých útoků, které servery přetěžují. Nemůžeme s nimi dělat nic jiného než všechny dotazy zodpovědět.
XDP obchází rozhraní jádra
Důsledkem vynechání síťového stacku je mimo jiné to, že se obchází routovací tabulka. Naštěstí je to u DNS serveru obvykle jednoduché, protože většina provozu jsou odpovědi, takže odpovídáme na stejné rozhraní, ze kterého dotaz přišel.
Podobně se obchází také firewall, takže je potřeba počítat s tím, že se na provoz neaplikují firewallová pravidla.
Pro XDP je potřeba mít minimálně linuxové jádro 4.18, doporučována je ale řada 5. Aby se dosáhlo očekávaného zrychlení, je také potřeba mít kompatibilní síťovou kartu. My si hrajeme s kartami Intelu, ale jsou i jiné.
XDP je také poměrně velký zásah do linuxového prostředí, takže server musí mít dostatečná práva. Buď přímo práva roota nebo alespoň capability CAP_SYS_ADMIN. Ta je ale potřeba jen pro start, server se ji pak sám zbaví.
XDP je implementováno v nové verzi Knot DNS 3.0. Admini v CZ.NIC už ji zkusili nasadit na málo důležitém DNS serveru v internetu.
Stále je ale o čem přemýšlet, například o paketech přicházejících z privátních rozsahů, které v tomto režimu nejsou zahazovány firewallem. Vývojáři nechtějí reimplementovat firewall, ale uvažují nad implementací základního filtru zdrojových adres.
Provozovatelé DNS infrastruktur obvykle nemají jeden autoritativní server, který by odpovídal na všechny dotazy. Obvykle existuje skrytý master server, poté server starající se o podepisování a poté jsou podepsané zóny šířeny pomocí zónových transferů k veřejně dostupným serverům. Pokud ale někdo provozuje nasazení s mnoha zónami, běžně se stává, že nám některé zóny ubývají či přibývají. Každý server má v konfiguraci seznam zón, na které odpovídá. Pokud dojde ke změně, je potřeba provést úpravy na každém serveru zvlášť.
To může způsobovat provozní problémy.
Když už umíme jednoduše synchronizovat obsahy zón, bylo by vhodné mít nějakou metazónu, který by obsahovala seznam obsluhovaných zón. Přesně tohle jsou katalogové zóny, které nejsou součástí globálního DNS stromu. Obsahují především PTR záznamy, které obvykle slouží pro reverzní zóny. Zde jsou použity čistě ze syntaktických důvodů, protože každý tento záznam obsahuje jednu obsluhovanou zónu.
Vlastníkem může být kdokoliv, změnou se ale signalizuje vyčištění obsahu zóny.
Katalogová zóna se pak spravuje jen na jediném místě – v master serveru. Zóna se pak automaticky přenese na všechny servery, které se pak podle ní překonfigurují. Původní implementace vznikla už v roce 2016 pro server BIND9, ale od současné verze se lišila a byla velmi pomalá. V současné podobě katalogové zóny implementuje Knot DNS 3.0. Do budoucna uvažujeme nad tím, že bychom katalogovou zónu generovali podle konfigurace. To by mělo výhodu v tom, že by uživatel nemusel vůbec vědět, jak zóna vypadá. Nakonfiguroval by jeden server a ostatní by se jako zázrakem nakonfigurovaly stejně.
