Vlákno názorů k článku DNS stack už má i CESNET: zvládne miliony požadavků za sekundu od Danny - Umistenim ISP stacku c.ns.nic.cz zrovna do CESNETu se...

Umistenim ISP stacku c.ns.nic.cz zrovna do CESNETu se ale paradoxne z pohledu RTT pro nektere site chovani spise zhorsi. CESNET v ramci sveho NIX.CZ peeringu oznamuje i site spolupracujicich akademickych siti. Mezi nimi i sit vidensky ACOnet, kde je c.ns.nic.cz jiz hodne dlouhou dobu provozovan.

Pro ceske site byl tak uzel c.ns.nic.cz dostupny s velmi nizkymi latencemi, prave diky jeho zpristupneni skrze CESNET. Po zapnuti tohoto ISP stacku tato cesta pochopitelne - v dusledku preference prefixu 194.0.14.0/24 a 2001:678:11::/48 z ISP stacku uvnitr CESNETu a s tim spojenou nepropagaci ACOneti instance pochopitelne zmizela. Nejblizsi dalsi instance c.ns.nic.cz je v Londyne. Tedy namisto cca 10ms je od ceskeho uzivatele tato vzdalena priblizne 30ms.

V pripade IPv6 to v NIX.CZ "zachranuje" Hurricane Electric, ktery prozmenu historicky poskytuje i v ramci peeringu zdarma IPv6 tranzit mnoha sitim. Takze po IPv6 se na nejblizsi vidensky uzel pres NIX.CZ dostavame. U IPv4 je situace komplikovanejsi. Do blizsi Vidne dnes pada provoz jen z tech siti, ktere at jiz primo, nebo skrze svuj upstream maji peering ve VIX.AT a tedy peeruji s ACOnetem naprimo - a nebo alespon v SIX.SK se SANETem (ti propaguji ACOnet obdobne jako CESNET). Ti ostatni... maji smulu a nezbyva, nez posilat provoz "az" do Londyna.

Jiste, nejde o zadnou tragedii - tech par milisekund DNS urcite nezabije - ale samotny CZ.NIC se rad chlubi tim, jak se snazi RTT vseobecne resit a vhodnym umistovanim anycast instanci toto snizovat. V tomto pripade se to ale trosku nepovedlo... proto, ze sit CESNETu byla i z pohledu fungovani DNS anycastu tak trosku specificka, v porovnani s jinymi "beznymi" ISP.

K tomu mám jako reakci schovaný jeden e-mail:

q: why do we anycast dns?
a: for attack resistance, latency is a secondary effect

q: what are the majority of queries?
a: trash

q: where should we place instances?
a: near folk who need queries answered. bzzzt! no!
a: near the sources of the rubbish so it can be absorbed quickly

Reakce Randyho emaily v konfrontaci s prezentaci samotneho CZNIC, kde se uz na ctvrtem slide pise "What is the best location for our DNS servers?" a pokracuje to "Who sends queries to our servers and how log does it take for a query to reach our server?" je tak trosku mimo misu ... vzhledem k tomu, ze ta (jiz v prvnim prispevku) odkazana prezentace je vyrazne novejsiho data, nez ten tvuj uschovany email - rozdil asi ctyri roky, vsiml sis? :D

Cela ta odkazovana prezentace (a za ni skryta spousta prace, ktera taky neco stala) je o tom, ze se konkretni umisteni a v dusledku i RTT jindy resi - tedy nejen ze se tupe mnozi servery hrubou silou. A ja jen zminuju, ze v kontextu te odkazovane prace se umisteni c.ns.nic.cz v CESNETu proste uplne nepovedlo.

To je z diskuse o root serverech. Tam je podíl "nesmyslných" (tedy NXDOMAIN) dotazů dost velký - myslím hlavně díky tomu, že počet běžně používaných TLD je malý a RFC 8198 není tak moc nasazeno. U .cz a nejspíš i jiných TLD to tak není a drtivě převažují pozitivní odpovědi: https://stats.nic.cz/stats/dns_queries_by_rcode/

To je takový pohled sítaře, který z hlediska DNS nedává vůbec smysl. Aneb Danny, je sice pěkné, že sis vybudoval case, kde můžeš ukázat, jak je CZ.NIC špatný, ale vzhledem k tomu, že pro většinu českých sítí jsou dostupné ostatní nameservery, je tvoje argumentace naprosto lichá, a jestli c.ns.nic.cz se obsluhuje z Vídně nebo z Londýna je z hlediska RTT pro českou zónu z českých sítí naprosto irelevantní.

Vyse jsem napsal - a to pro tebe specielne zopakuji - protoze jsi to pravdepodobne pozorne necetl: Jiste, nejde o zadnou tragedii - tech par milisekund DNS urcite nezabije.

Ale i primo v clanku se primo pise, opet cituji: Vzhledem k principu anycastu snižuje sekundárně umístění ISP DNS stacku v síti ISP latenci a pomáhá zrychlení odezev DNS dotazů zákazníkům v síti ISP. Chces snad publiku sdelit, ze i Zdenkova argumentace podporujici nasazovani stacku k ISPckum je tedy vlastne licha, at se drzime tveho slovniku? :-) Pouze jsem napsal, ze se neco uplne v kontextu tech latenci, ktere se taky resi aktualne trosku nepovedlo - nic vic. A koukam, ze na nekoho to pusobi jako cervenej hadr :-) To, ze to dela CZ.NIC spatne sis tam buhviproc podsunul ty sam, nic takoveho jsem ja nikde nenapsal. Ano, pekne jsi se do me z pozice experta na DNS navezl - ale soucasne jsi uspesne (zbytecne) rozbil i jednu cast podpurne argumentace, ktera doprovazi samotnou propagaci ISP stacku v tomto clanku, gratuluji ;-) A to ja proti nim - abys mi treba zas neco kreativne nevsunul do ust - opravdu nic nemam a ani nemam v planu po tvem vzoru hlasat, kterak je tech par mikrosekund naprosto irelevantní.

Realne je tato debata spise o uskalich, ktere provozovani anycastu v obecne rovine doprovazi. Kdy zdanliva malickost zmenena na jednom miste muze - treba i necekane - ovlivnit neco uplne jineho. A presne to se stalo.

Danny, víš, co se píše v článku? Ještě jednou: "Do sítě CESNET se oznamuje DNS anycast C (194.0.14.1/24 + 2001:678:11::1/48). Tento anycast byl pro všechny ISP DNS stacky vybrán záměrně, protože není oznamován z žádného veřejného DNS stacku v České republice a je dostupný výhradně z vybraných zahraničních lokalit."

A víš, co to znamená? Že jsou tři způsoby, jak se k serveru C dostat:
1) Na server v zahraničí. Tam už z principu bude vždycky latence delší, než pro ostatní servery (veřejně propagovaný v ČR). Zvlášť, pokud ISP třeba peeruje v NIXu. Protože musí z BGP routeru do jinýho AS, který zajistí tranzit do zahraničí, pak do AS, ve kterým běží ten server a zpoždění na dlouhé lajně taky není zanedbatelný.
2) Na server v síti vlastního ISP. Tam už první router ví, kam to poslat a ani to neopustí AS, takže to bude (minimálně o dva routery) kratší cesta. Proto to ISP nasazuje.
3) C server není v síti ISP, takže router zkusí všechny připojený AS. Ty taky nemají (veřejný) C server, takže zkusí ostatní AS. No a takhle to pokračuje, dokud dotaz nechcípne na TTL, nedojde odpověď ze zahraničí, nebo se nenajde stroj v jiným AS, který vidí lokální C. Sice si ho pak routery dají do cache, ale protože je to v jiným AS (min. o 3-4 skoky dál), nebude to preferovaný stroj.

Takže jo, pro Frantu z vesnice se nic přidáním serveru do CESNETu nemění. Ani se nic nesní změnit. Furt je de v pořadí DNS vlastního ISP - veřejný DNS - zbytek světa. Adresu na C dostane jenom po prvním zapnutí stroje od root serveru, ale kvůli TTL a odezvě se nedostane do cache, tam spadne jiný stroj (třeba Bčko a jako rezerva Ačko). A pak už při požadavku na *.cz sahá po serveru z cache. Protože to nasadil CESNET a ne Lojzova WiFi s.r.o. Pokud Frantu trápí, že nemá defaultně DNS 194.0.14.1, ať zavolá wifinářovi a poprosí ho, aby nasadil IPv6 a na místo ušetřenýho CGNATu dal DNS server od CZ.NIC. Už vidím, jak takovou radu od platícího zákazníka (300Kč/m) wifinář nadšeně vyslyší.

Přínos serveru v síti CESNET je pro CESNET a jeho zákazníky - nemusí pro dotazy do jinýho AS (= zrychlení pro vlastní zákazníky + odlehčení linek ven) a v případě útoku na infrastrukturu může, minimálně částečně, fungovat autonomně.

Dekuji za prednasku k fungovani DNS anycastu a BGP routingu z kategorie noseni drivi do lesa - navic plne nepresnosti, ale to zanedbame :-)

Ze je Ccko v zahranici vyplyva uz z prvniho meho komentare. Je tam dokonce popsane realne pozorovatelne rozdilne chovani na IPv6 a IPv4. V kontextu argumentu Ondry Sureho je skutecny prinos z pohledu zrychleni odezev primo v CESNETu irelevantni a lichy - tech 10ms prece vubec zadnou roli pro DNS nehraje - doted to i v CESNETu meli dostupne primo z videnskeho ACOnetu a zpozdeni bylo maximalne o rychlosti svetla ;-) A z pohledu kapacit - spicove na celou CZ zonu pada maximalne 18k QPS, do celeho Ceska vime ze jde tak ctvrtina. Tak schvalne, kolik pasma takovy provoz zabere? Klidne rovnou odpovim, v tom desetigigabitu pujde o vcelku zanedbatelny sum - a to vcetne provozu, ktery z Rakouska k nam doposud CESNET ke vsem sitim pripojenym v NIXu transportoval ;-) Treba v sitich v me pusobnosti dela komplet cely (nejen .cz) DNS provoz sotva nejakych 0,2 % v celkovych objemech provozu... zrovna tady nikoho dnes kapacity linek fakt netrapi ;-) Explicitne ale podotykam, ze ISP stacky jako takove nerozporuji, svuj (jiny) smysl nekde maji - aby se toho zas nekdo nahodou nechytil... :-)

O cem presne ze ma byt ta pasaz o "wifinarich za 300"? Domaci Franta uzivatel se vysoce pravdepodobne primo zadneho root/tld DNS ani ptat nebude. Bude pouzivat nejaky resolver. Bud ten od sveho ISP, nebo nejaky z tech verejnych - Google, Cloudflare, Quad9.... nebo treba ODVR :-) A nebo ty DNS dotazy rovnou pobezi zabalene v DoH.

Realne ta slabsi mista .CZ anycastu se nachazi nekde jinde, daleko od nas a jsou verejne popsana. Staci umet cist a vyhodnotit publikovane ;-) Jak uz jsem opakovane psal, tech par milisekund navic - mysleno cesta paketu do Londyna namisto do Vidne DNS urcite nezabije. Ale i dle tech publikovanych dat dava vetsi smysl provoz na Ccko z Cech smerovat pokud mozno spise na tu Viden, pokud to je mozne nejak ovlivnit - on ten Londyn je tak nejak vic na rane - mysleno tak, ze je asi i vice vytizeny - a je to dano tak nejak i tim, co vse se sitove odjakziva sbiha v Londyne :-)

> Vzhledem k principu anycastu snižuje sekundárně umístění ISP DNS stacku v síti ISP latenci a pomáhá zrychlení odezev DNS dotazů zákazníkům v síti ISP.

Ano, to je stále pravda. Resolvery velmi záhy zkonvergují k nerychlejšímu serveru ze sady nameserverů, proto umístění serveru přímo u ISP má vždycky smysl, protože takový server bude mít (pravděpodobně) vždy nižší latenci než ostatní ze sady. A bude mít výrazně pozitivní dopad v případě, že je z nějakého důvodu zahlcená linka k ostatním nameserverů v sadě, které jsou mimo síť ISP.

> Realne je tato debata spise o uskalich, ktere provozovani anycastu v obecne rovine doprovazi.

Ale tohle přece není obecná debata o anycastu, tohle je článek o tom, jaké dopady to má na DNS. Začal jsi argumentovat tím, že umístěním C serveru k Cesnetu CZ.NIC zhoršil dostupnost, a ani nejsi ochotný přiznat, že jsi neměl pravdu:

> Umistenim ISP stacku c.ns.nic.cz zrovna do CESNETu se ale paradoxne z pohledu RTT pro nektere site chovani spise zhorsi.

Z hlediska DNS resolverů (a o ty tady jde] se chování prostě nezhorší, a v síti Cesnetu se zlepší. A zbytek už jenom mácháš rukama do vzduchu.

Nikoliv, jestli mam odpoved od lokalniho node za 200-300µs po lokalni siti, nebo za 500µs z velkeho stacku skrze NIX hraje roli fakt naprosto zanedbatelnou. Velke DNS stacky maji kazdy po 30 serverech, kazdy s 10G uplinkem. Jen do NIXu mas od kazdeho z nich 100 Gbps uplink. Zatimco ty ISP stacky jsou realne jeden stroj s jednim 10G uplinkem. Co se zahlti (pod utokem) driv je jasne. Samozrejme, ze to takto zahlcene jedno 10G v dusledku nadela jeste vetsi paseku, protoze zacnou treba i flapovat BGP a pak se ta cela konstrukce o vybranem serveru s odezvami o 200µm rychlejsimi borti jak domecek z karet. A ani se nemusi zahltit linka, je halda dalsich provoznich problemu na strane serveru, ktere v konecnem dusledku mohou vest i k rozpadani BGP a s tim spojenymi negativnimi dopady - v pripade CESNETu by se realne objevovala a opet mizela videnska instance v NIXu.
Zahlceni linek je to posledni, co je na poradu dne. Z celeho NICu do NIXu tece po 200G kapacite stezi gigabit provozu, a to vcetne provozu treba z mirroru. Dostupne kapacity na stackach je naopak tolik, ze se jeste nabizi jinym velkym TLD (disclaimer: a je to dobre, ze se takto zdroje sdili). A mas-li fakt strach o kapacity, muzes krome mirroru navrhnout omezeni treba tunelovaci sluzby, aneb dalsi provoz, co k zajisteni chodu DNS potreba neni, ale linky to samozrejme nejak vytezuje - a samozrejme to muze byt i vektor utoku :-) Ja osobne strach z problemu s kapacitou fakt nemam.

Tve (asi zdrojakove) teorie ja mam moznost porovnat s krutou praxi - tedy s tvrdymi netflow daty z realneho provozu. A z nich vychazi, ze resolvery velmi zahy k nejrychlejsimu serveru nikdy plne nezkonverguji. Na c.ns.nic.cz mi realne od ruznych resolveru trvale vyjadreno v paketech - tedy zjednodusene v dotazech - smeruje priblizne 14-16% provozu z celkoveho objemu k .cz TLD DNS. A to navzdory tomu, ze si ty resolvery na odpoved musi pockat celych 10-30ms namisto onech 500-600µs z ostatnich instanci fyzicky umistenych v Praze. Dokonce se treba celkem pravidelne u dual-stack stroju strida IPv4 s IPv6, tedy jednou to zkusi po 30ms ceste, podruhe po 10ms ;-)

Ano, umistenim c.ns.nic.cz se - jen po IPv4 - protahly ty odezvy z 10 na 30 ms. Takze k meritelnemu drobnemu zhorseni tam doslo. Samozrejme, abys me treba zas nechytal za slovo - z praktickeho pohledu bezneho uzivatele zadna zasadni tragedie. Jenom jak vidis jen nemacham rukama, mam i nejaka prakticka cislicka ze zivota ;-)

Teď jsem možná úplně mimo. Ale trochu lidštiny.

Je zřejmé, že TLD pro CZ je potřebné kvalitně prezentovat na celém světě. (doba odezvy)

Věřím, že většina uživatelských požadavků na dotazy pochází z ČR.

Domnívám se tedy, že response time pro většinu ČR sítí, by neměl být horší, než pro ostatní sítě venku.

Nedomnívám se, že CZ doména má globální postavení jako COM doména.

Geolokace prichozich dotazu je rovnez patrna ze zde jiz nekolikrat odkazovane prezentace, jen je potreba udaje z ni trosku poskladat. Na samotnou CR pripada cca 26% dotazu - tedy rekneme ctvrtina. Cca 4,8 % pripada na Irsko, procentuelne nekde nad tim je (5+%) jeste Nemecko. Cca 3% na Rusko, Nizozemi nebo Cinu, 2% na UK, Slovensko, Singapur nebo Francii. Specielni slide s procenty za severni Ameriku z nejakeho duvodu chybi, ale z "tecek" na slide 19 jde snadno odvodit, ze USA ma take tech cca 26% dotazu, stejne jako z CR. Kanada bude nekde na urovni Finska - tedy kolem 1,1%.

Samotna geolokace u IP muze byt ale osemetna zalezitost - byt se zpracovatele techto databazi o nejakou presnost vcelku hodne snazi, nejake chyby se tam muzou objevovat stale. Zvlaste u nadnarodnich operatoru/orga­nizaci ta zeme puvodu vyctena z geoip nemusi nutne korespondovat skutecnemu umisteni stroje (treba u Google i Maxmind hazi nektere evropske uzly do USA). Urcite bych ale na zaklade dnes dostupnych publikovanych dat i tak nevyslovoval zaver, ze vetsina pozadavku prichazi z CR :-) Response time v CR spatny nebyl a neni ani ted, pouze se z nekterych smeru meritelne malinko zhorsil oproti puvodnim stavu - ale jak uz jsem psal v uvodu, nejde o zadnou tragedii - jako uzivatel realne nemate sanci poznat rozdil.