Názory k článku Doména .CZ musí být stabilní, dostane nové servery a 100GE linky

Dobry den!
I timto jsme se zabyvali, ale implementace DNS protokolu v cele jeho siri na FPGA nam pripada nemozna nebo alespon nesmirne narocna. Spise premyslime o nejake parcialni HW akceleraci DNS serveru, ale ani to neni mozne udelat v nejakem kratkem case a vystavba konvencnich stacku (jako to delaji vsichni DNS operatori) se nam v soucasnosti jevi jako nelepsi reseni.

Velmi by me zajimalo, co je na tom (konkretne) tak narocneho. Samozrejme, neni to projekt na 3 mesice, spise na 1-2 roky, ale je skutecne moudre spolehat na mene vhodnou architekturu? Delate uz alespon na tech akceleratorech nebo se jeste nezacalo?

U rekursivniho DNS je komplexita zrejma, ovsem u autoritativniho bez nutnosti podpory transferu zon je to diametralne odlisne. Ve vedecke literature popisuje tym 4 lidi (Sadoun et al) jak to prototypovali za 18 mesicu. Zpusob jejich reseni je mozne jeste vyrazne zlepsit, ale i tak ukazali, ze je to realne a schudne. Proto by me zajimalo jak to vidi NIC, kdyz misto takovychto veci resi a financuje projekty nesouvisejici s DNS.

Jste-li zamestnancem CZ.NIC, tak to opravdu objasnuje mnohe...

Tak ono za tu dobu zivotnosti tohoto reseni (kolik let se planuje?) by se to jiste stihlo vyvinout i otestovat. Mohli by jste treba zverejnit (klidne soukrome, nebo osobne) kolik je to cca dat/zaznamu a jestli jde jen o vyhledavani konkretniho nazvu nebo jake vlastnosti ma takovy autoritativny server umet? Klidne bych se nad tim zamyslel vic do hloubky - jak dobry nebo spatny napad by to byl.

Výše zmíněný návrh, absence transferů, je opravdu geniální nápad, když se zóna aktualizuje v řádu desítek minut.
Zóna se aktualizuje tak často, jak se správce TLD rozhodne. CZ.NIC zrovna letos frekvenci aktualizace zóny snížil z původních pěti hodin na jednu hodinu. Každopádně absence transferů tomu vůbec nevadí, dostat zónový soubor na serveru je možné i jiným způsobem – a pro přenos souborů existují vhodnější protokoly, než DNS.

Obecně výměna zóny za běhu je zajímavá úloha.
Vskutku ano. Zkopíruje se nový zónový soubor a pak se serveru pošle signál, že má začít používat ten nový soubor.

DNSSEC dále vyžaduje hašování. Logika sestavování odpovědí s DNSSEC je kapitola sama pro sebe.
Pokud odpovědi podepisuje server online, nestačí jenom hashování, ale hlavně podepisování. Pokud se nepoužívají NSEC3 záznamy, server naopak nic hashovat ani podepisovat nemusí, jenom servíruje záznamy ze zónového souboru. (CZ.NIC používá NSEC3, aby nebylo možné obsah zóny .cz vylistovat.)

Pokud je řeč o doméně .cz, netuším, proč píšete o nějaké „běžné TLD“ a až desítkách milionů záznamů, když v .cz je registrováno 1,3 milionu domén. Když jsem psal o aktualizacích, psal jsem konkrétně o TLD .cz, to jste asi přehlédl.

pro jednu doménu je potřeba minimálně:
1x SOA
2x NS
2x A (pro ty NS)
1/3 domén má IPv6, tj. další minimálně 2x AAAA

no a už jsme na 10 milionech a to tam nemáme žádný DNSSEC.

V zóně cz je SOA záznam pro doménu cz, tedy jeden. Každá registrovaná doména, která je v zóně, musí mít alespoň 1 NS záznam. Tím to končí. Glue záznamy ( A/ AAAA) jsou tam pouze v případě, kdy je jmenný server ve stejné zóně.

Můžu poprosit o odkaz na statistiku, že 1/3 jmenných serverů v TLD cz běží i na IPv6? Mimochodem, i ten váš chybný výpočet dává 7,4 milionu, takže ani s tou matematikou to není nijak slavné.

https://stats.nic.cz/stats/ipv6_domains/

https://www.root.cz/clanky/tretina-domen-cz-ma-ipv6-adresu-koncovych-uzivatelu-je-v-cesku-10/

Vzhledem k tomu, že ani jeden z nás nemá přesnější informace o obsahu TLD .cz, tak si o matematice můžeme myslet každý co chceme. Je to možný odhad.

Popletl jste počet adres s AAAA záznamy s počtem zón, jejichž DNS servery jsou dostupné přes IPv6. V tom druhém odkazovaném článku se píše, že těch druhých je přes 71 %.

Každopádně máme informace o tom, že v zóně cz nejsou SOA záznamy pro podřízené domény, stejně jako máme informace, že tam nejsou glue záznamy pro každou podřízenou doménu.

O matematice si každý můžeme myslet, co chceme, což nic nemění na tom, že (1+2+2+2×1/3) × 1,3 milionu není 10 milionů.

Z článku: Správce domény .CZ ve svých statistikách hlásí, že přibližně třetina domén má záznam typu AAAA, tedy je k nim přiřazena IPv6 adresa.

Filip má pravdu. Ta statistika se týká AAAA záznamů na autoritativních serverech pro jednotlivé zóny. Zóna .CZ. ale žádné A/AAAA záznamy neobsahuje, je to čistě delegační zóna, ve které jsou jen NS záznamy delegující obsluhování zóny na jiný nameserver.

Tak když mně vysvětlíte, jak se bez A záznamu pro daný NS dostane na dotyčný nameserver, tak vám to budu věřit :-)

Tj. jak se z

cvut.cz NS ns.cvut.cz

dostane se svým dotazem na nameserver ns.cvut.cz, který mu pak odpoví na www.cvut.cz A 147.32.3.202

(doména cvut.cz byla vybrána náhodně, abychom si to nekomplikovali NS záznamy z jiných domén, jako třeba u root.cz)

To je úkrok stranou. Debata se točí kolem toho, kolik nameserverů má IPv6. Ty jsi do toho namotal to, kolik domén má AAAA záznam. To první je v zóně .CZ (a ano, může tam být glue záznam, pokud je to potřeba), to druhé už ale neleží u CZ.NIC a je to v jednotlivých delegovaných serverech. O tom je odkazovaný článek na Rootu o počtu IPv6 v doménách. Ale nesouvisí to s tím, kolik je toho v zóně .CZ.

Diskuse je o implementaci root DNS v FPGA, tj. kolik záznamů musím narvat do hardware. Tj. všech SOA, A, AAAA, NS, atd.

Ano, ale argumentováno bylo článkem, který říká, kolik domén na sobě má AAAA záznam, což je irelevantní. Tahle data nejsou v zóně .CZ.

Jak nejsou? Jak se po IPv6 dostaneš k tomu dotyčnému nameserveru, na který se NS odkazuje, když nedostaneš z .cz AAAA odpověď?

Ale to já uznávám, ano, jsou tam A/AAAA glue záznamy pro nameservery. Ale nejsou tam koncové A/AAAA záznamy pro jednotlivé domény. Záznam pro www.root.cz tam prostě není a o něm je právě statistika odkazovaná v tom článku. Ten se nezabývá nameservery.

přibližně třetina domén má záznam typu AAAA, tedy je k nim přiřazena IPv6 adresa
Jenže tím se nemyslí to, že by měl IPv6 adresu přiřazen jmenný server, ale že uvnitř té domény jsou názvy s AAAA záznamy. Když si ten článek přečtete celý, dočtete se tam také tohle:

Zajímavý je také pohled na počet NS záznamů s IPv6. Ukazuje, kolik autoritativních DNS serverů je po šestce dostupných: je to více než 71 %. Je to dáno tím, že registrátoři a různé hostingy provozující pro své klienty DNS servery jsou na IPv6 velmi dobře připraveni.
A to je to číslo, které nás zajímá, tedy kolik jmenných serverů pro domény v TLD cz může mít potenciálně glue AAAA záznam. Nicméně z toho také plyne, že velký podíl na jmenných serverech dělají servery doménových registrátorů a webhosterů, ke kterým tedy v zóně cz není potřeba glue záznam.

To by platilo pouze v případě, že by každá doména měla vlastní GLUE záznamy. Pro většinu domén to ovšem neplatí. Stejně tak je v zóně pouze jedno SOA.

Ale i tak je pro každou delegovanou zónu:

0.5 x DS
2+ x NS
0.1+ GLUE (konzervativní odhad 5%)
0.5 NSEC3 (opt-out)

tj.

673 936 DS
2 614 170 NS
130 708 GLUE
673 936 NSEC3

tj. velmi konzervativně budeme na 4 mio, ale bude to spíše více (tak o jeden mio), vzhledem k tomu, jak se největší registrátoři chovají k NS záznamům.

Nicméně jestli je to 5 mio nebo 10 mio je jenom dvojnásobek... a stačí, aby se pár velkých registrátorů rozhodlo přidat jeden NS záznam navíc a vyletí to nahoru, takže stejně na těch 10+ mio musíte mít nachystanou infrastrukturu, protože nemůžete držitelům říct: "sorry, na to naše FPGA nemá paměť".

A teď na to koukám ještě před ranním kafem a koukám, že jsem úplně zapomněl na RRSIGy. Asi jsem těch kafí měl včera moc :).

GLUE a NS se nepodepisují, takže je to ještě navíc cca 673 936+673 936 RRSIGů pro DS a NSEC3, takže jsme řekněme na 5.5 mio.

@dns: co si predstavujete pod pojmem FPGA? Delal jste s tim nekdy?

@dns: mylite se v mnoha vecech, ale aspon uvadite konkretni problematicka mista.

Absence zonoveho transferu: naprosto irelevantni, DNS server nemusi nic takoveho podporovat pro treti stranu, a interne si to muze vyresit jak chce. Toto je elementarni znalost, ze ktere je patrne, ze o DNS vite prilis malo.

TCP: lze vzdy zajistit predsazenou FPGA deskou s prislusnym stackem a dalsi komunikaci po internim rozhrani, spolecnem s UDP.

TLS: totez co vyse plati i o TLS, do 10Gbps to FPGA dava daleko lepe jak standardni zelezo.

Skladani odpovedi a pamet: cast DNS otazky se kopiruje a doplnuje se neco, co lze dopredu predpripravit. Cim vice se predpripravi, tim to bude rychlejsi ale narostou pametove naroky. Do radu desitek GB to jde resit "levne", bud primo jednim chipem anebo rozkladem.

Bohuzel to vypada, ze praktici, kteri tvrdili, ze neni mozne postavit vlak jedouci vyssi rychlosti jak 20mil/h, protoze by podtlak proudiciho vzduchu vysal vzduch z vagonu, jeste nevymreli. Ted budou tvrdit, ze nejde neco postavit, protoze by to bylo prilis slozite a to se proste nemuze.

1) je to databaze klic-hodnota, s timto faktem nic neudelate, zbytek jsou jen technikalie

2) kompilaci zonoveho souboru muze delat ten, kdo pro FPGA pripravuje data a distribuuje je tam, tj. je to trivialni uloha na urovni LL(k) a upload do FPGA

3) NSEC3 lze predkompilovat stejne jako klasicke odpovedi, stoji to jen vic pameti (+doplnkovou kalkulaci), ale hlavni problem je ta pamet. takze tohle jde bud udelat rychle a zaplatite vic za HW s velkou pameti, anebo bude trvat vyvoj dele a najde se mene narocne reseni. Viz mnou odkazovany clanek na onen vedecky tym vyse.

4) neni mi uplne jasne, co byste mohl v DNS vubec programovat.

5) proc to jeste nikdo nedela? Protoze to neni commodity hardware a vyzaduje to vyssi uroven znalosti, ktere nema kazdy druhy bouchac kodu. Jeden z mnoha to vsak delat muze, zvlast pokud ma potrebne znalosti a penize/cas.

Tomas3, 21:25: Tohle mne zajímá, zrovna nedávno jsem to řešil. Můžete popsat, jak konkrétně předem připravíte negativní NSEC3 odpovědi (tedy odpovědi na dotazy na jména, která v zóně nejsou), abyste je mohl dát do mapy (databáze klíč-hodnota)?

Tomas3, 21:25: Ještě upřesním, že mi samozřejmě nejde o to, jak záznamy do té mapy dostanete, ale jak je odsud vyzvednete – já to umím jedině s výpočtem hashe z požadovaného jména, a navíc tu databázi klíč-hodnota potřebuju mít podle hashů setříděnou, takže to úplně obecná databáze klíč-hodnota není.

Odpoved najdete v RFC7129. Baze klic-hodnota nijak neomezuje pocet tabulek ani pristupove metody, neni to jedina konstantni hash tabulka s jedinou get(x) funkci. Bezne dovoluje dotazy na nejblizsi polozky klice apod. Jinak ve Wikipedii si jiste dohledate, co patri do rodiny key-value bazi, pricemz pro tuhle ulohu staci samozrejme jen neco jednoducheho v podobe rozhodovaciho stromu nebo seznamu se skokem.

Re 1), a kam přesně do vaší K-V databáze spadají child-parent vztahy, empty non-terminaly?

Re 3) nelze, pro každou příchozí *miss* odpověď musíte ten hash spočítat. A nedej bože, že byste třeba chtěl NSEC minimal encloser odpovědi.

Re 4) A můžu se zeptat, na kolika DNS serverech jste za svůj život pracoval?

Re 5) Nebo se to prostě pro tento druh úloh nevyplatí. Formát DNS paketu taky není žádná hitparáda pro "drátování" do HW...

@ O. Sury

Predpokladam, ze stale probiha diskuze o ADNS, nikoliv o rekursivnim rezimu.

1) budte konkretnejsi jaky konkretni vztah reseny v ADNS potrebujete reprezentovat jako key-value

3) mylite se, pro ADNS se prislusna struktura muze predpripravit, viz jiz zminene RFC7129. Zrejme chapete key-value bazi napr. jako hashtabulku vyhradne s puvodnimi plain klici.

4) myslite instalace? Asi stovky. Pred zhruba 15 lety jsem to prestal pocitat. Myslite-li servery jako produkt, pak asi 5-7 v kategorii ADNS.

5) ten bastl vam prijde zahusteny v dotazu, coz se kopiruje, a vysledny produkt jde opet v dostatecnem rozsahu predpripravit mimo samotne FPGA, pokud by se s tim nekdo nechtel trapit primo na svabu

Zrejme chapete key-value bazi napr. jako hashtabulku vyhradne s puvodnimi plain klici.
Nemusí to být původní klíče v otevřeném tvaru, ale jinak obecně databáze klíč-hodnota je opravdu jen mapovací tabulka, která umí pro zadaný klíč najít odpovídající hodnotu, a nic jiného. A může být implementována třeba pomocí hash tabulky. Pokud máte na databázi nějaké další požadavky, nemůžete napsat, že na to stačí databáze klíč-hodnota, protože libovolná databáze klíč-hodnota na to nestačí.

1) Já jsem se Vás ptal, jak v key-value databázi vyřešíte empty non-terminaly.

3) Ne, nepochopil jste dotaz. Přečtěte si můj původní dotaz ještě jednou, a odpovězte na něj.

4) Myslím tím DNS server jako produkt podporující moderní DNS protokol. V kategorii autoritativních DNS ani 5-7 implementací není.

Ještě by mne zajímalo, do kterého FPGA nacpete alespoň 192+ GB RAM (ale spíš více), a kolik takové FPGA bude přibližně stát? A jaká bude jeho rozšiřitelnost?

k čemu by mělo sloužit těch 192+ GB? Pokud bych měl v paměti 100 000 000 záznamů (potřebuju tak 10-20 Mzáznamů) po 1KB (toto bude asi taky menší číslo), tak je to 100 GB a to je minimálně dvacetkrát předimenzované.

Např. https://www.verisign.com/en_US/channel-resources/domain-registry-products/zone-file/index.xhtml

A to samozřejmě pomíjím fakt, že pro příchozí aktualizace zóny může spotřeba paměti vyrůst až 2-3x, ale budiž na FPGA to budete potřebovat jenom dvakrát pro atomické aktualizace dat.

To by byla poměrně hloupá implementace s přepínáním dvou pamětí. Vždycky je možné minimálně to, že dotyčnou závislou část (která patrně nebude moc velká) z paměti FPGA vymažu, FPGA přesune dotaz do software a mezitím se aktualizuje část FPGA paměti.

Jakože na serveru, který je zrovna plně vytížen nějakým útokem, budete přepínat tam a zpátky mezi FPGA a software implementací?

Přepínat do sw by se musely pouze ty položky, které by byly v FPGA zneplatněné. Takže by ten útok musel být koordinovný asi s tím tvůrcem změny v DNS, což není tak nějak příliš pravděpodobné.

Nepřipadá mi, že by někdo tvrdil, že DNS nad FPGA nelze postavit.

Trochu o DNS něco vím, a platí, že dnešní DNS protokol je mnohem komplexnější, než se nás všechny snažíte přesvědčit.

Dokud je a) prostor pro zrychlení na komoditním hardware[*], b) rychlost na komoditním hardware je dostatečná, tak pořád příliš nedává smysl vyvíjet něco pro drahé FPGA (a na levném to prostě nepostavíte). Někde je ten prostor pro vylepšení větší, jinde už např. dává smysl podpora pro DPDK, vlastní IP stack, atp.

* - existují PoC implementace na 12 mio odpovědí za sekundu, ale ty přesně neumí vůbec nic z moderního DNS.

@O. Sury:

Zkuste to popsat konkretne. Co je tim komplexnejsim mistem v protokolu DNS? Zejmena se zamerte na body, ktere jsou z pohledu ADNS "mandatory".

Tady se totiz porad argumentuje "komplexnim DNS protokolem" - snad neni tak narocne uvest nejaky konkretni aspekt toho "komplexniho" protokolu. Staci odkaz na odstavec v nejakem RFC, pokud se nechcete rozepisovat.

Ok, tady je pár věcí, které z toho dělají divočinu:

* Random subdomain NXDOMAIN attack (včetně NSEC3)
* DNS Cookies
* Variabilní EDNS0 Buffer Size
* DNS Komprese
* EDNS Padding
* RRL
* dnstap (aneb monitoring, kde chcete znát i interní stavy serveru)

Reseni ochrany proti napriklad odrazum je sice hezke, ale urcite ne "mandatory" a navic snadno resitelne, to uz bylo v FPGA udelano. Padding je zas podle RFC7830 zakazany pro nesifrovane dotazy, coz tedy nevim jak koreluje s realitou TLD CZ ADNS, ale problem je tam podle vas s cim?

Vybral jste si jednu konkrétní věc, a na zbytek jste neodpověděl.

DNS over TLS bude časem dospecifikováno a implementováno i pro komunikaci mezi rekurzivním a autoritativním serverem.

Jinak v RFC 7830 Security Considerations je v tomhle chyba. EDNS(0) Padding by byla pořád dobrá ochrana proti sběratelům metadat v případě:

a) transport je TCP (tj. nehrozí reflection útok)
b) dotaz přijde s validní DNS Cookie

Ale jak již psal kolega jinde, pokud je to podle Vás tak snadné, tak by neměl být problém na to vybrat peníze. Velké DNS operátory to určitě bude zajímat. Zvu Vás na další DNS-OARC - ten podzimní bude v Amsterdamu, to byste mohl dát i za svoje, pokud si za tím tak stojíte.